
Coding Interview Tips - gameguy43
http://www.interviewcake.com/article/tips-and-tricks
======
goo
I have observed a general frustration that good developers (who are in high
demand) still need to do well in an interview setting. Frustrating as it may
be, I think that embracing the reality is the best path forward.

A good developer would be smart to realize that this is a part of the project
of finding a great new job, and would apply themselves fully to the subtask of
preparing for and succeeding at an interview.

I think that, in the same way it is a necessary frustration to make sure the
site performs well on IE8, a good developer recognizes the task as essential,
and does what is necessary despite the perceived lack of significance.

Of course there is a limit to this lack of significance -- I am not advocating
that people become professional interview-ees. But embracing the frustrations
of a profession can give you a huge edge over those who don't.

If I were to be seeking employment right now, my first step would absolutely
be to sign up for resources like this one, and dedicate a couple hours a day
to honing my interview skills. It would be fun, and would develop a skill that
opens a lot of doors.

~~~
PopeOfNope
_I have observed a general frustration that good developers (who are in high
demand) still need to do well in an interview setting._

I'm not sure it's frustrating so much as it is humiliating. Programmers
(especially good ones) have egos that are somewhere between healthy and
oversized. Interviewers assume you know nothing and make you qualify yourself
at each and every interview, as if you were a fresh college graduate who
hadn't already made his bones[0] at a dozen other jobs[1].

 _A good developer would be smart to realize that this is a part of the
project of finding a great new job, and would apply themselves fully to the
subtask of preparing for and succeeding at an interview._

Sadly enough, I couldn't agree more. Complaining on the internet is not a
sufficient strategy for changing the face of tech hiring, so if you want to
work, you have to deal with things as they are. Then again, the best way to
find new jobs is through aggressive networking, not being able to reverse a
binary tree on a whiteboard. So a good developer should probably focus on that
instead.

[0]: yes, that's a very entitled attitude. On the other hand, if we had gone
into an apprenticed trade, like woodworking or plumbing, it's expected that
you already know your job by the time you hang your own shingle. It's a sad
day when _plumbers_ get more respect than programmers.

[1]: Just to nip this one in the bud: Yes, people lie on resumes. A short
conversation about their work history where you ask for specifics should be
enough to verify whether they actually did what they said they did. If they're
good enough to bullshit their way through an interview, they're good enough to
bullshit their way through a whiteboard programming session. If, for some
bizarre reason you make a bad hire despite all the other filters you have set
up, _fire them_ and chalk it up to a mistake. If you do it over and over and
over, re-evaluate how you do interviews.

~~~
sokoloff
> If they're good enough to bullshit their way through an interview, they're
> good enough to bullshit their way through a whiteboard programming session.

That's not been my experience. I've met a fair number of ace bullshitters who
fell to pieces when it came time to write any code. I'm not talking missing a
semi-colon here or there; I'm talking closer to "an observer who walked in
afterwards might not be able to tell what problem I asked them to code."

------
metral
I consider myself to be a generalist and pretty personable, the latter of
which I don't think many folks remember to demonstrate during interviews, so I
wholeheartedly agree with the points about chitchatting & showcasing your
collaboration abilities. However, on the topic of working through a coding
problem, I find myself struggling not so much with the asks per se, but
rather, I focus too much on the fact that I'm thrown out of my usual
dev/coding environments and working through a problem in a Word doc or some
other non-text editor platform and it becomes a bit of a mental block.
Compound that with the fact that my style of coding includes referring to
existing code of my own or looking things up in mediums such as Google and
StackOverflow to jump start me, and it becomes more of a crutch that does not
aid me in these sorts of situations.

~~~
mikerichards
You're exactly right. If you get some dork that wants you to code during an
interview then walk out immediately.

That's not how the real world works.

That said, as a senior software engineer, you should be able to get on a
whiteboard and brainstorm and defend some architectural designs.

Even then, it's so much more important that you're all on the "same page" and
can collaborate on problem solving, rather than they hoping your freaking
Richard Feynman and will solve cold fusion for them

~~~
tezzer
I disagree completely. Every once in a while someone will slip through phone
screens, etc. who does not have the foundational knowledge I want in someone
who works for me. Asking them to write code to traverse a tree or implement
strcpy in the language of their choice shows me if they lack the basic skills
to continue taking up my time. Then we can work our way up the stack to
debugging, design, architecture, and domain-specific knowledge.

------
x0x0
The last tip is the most important: practice.

The industry loves tree questions, which is stupid -- the vast majority of us
will never and definitely should never implement a tree. Red black trees are
notoriously fidgety to get right; just use the free, tested, implementations
that someone has already beat on for you. But we love asking that shit in
interviews. I actually got in an argument with a former engineering manager
who loved tree questions; I demanded to see where in our 10m line codebase we
implemented a tree. Nowhere. But if you wanted to work for him, you had to
know how to implement trees on whiteboards.

So practice so you're refreshed on trees and all the other trick questions we
ask and not mentally refreshing yourself in the interview, and practice
specifically coding on a whiteboard. That will help you remember to leave
space to add more code and to write small and...

the whole thing is fucking stupid, but sometimes life makes you jump through
hoops.

Also, and I think I read this on here, that stupid question about detecting
loops in lists (hare and turtle) was an open research problem for quite a
while, and wasn't published until 1969. Knuth, naturally. So either everyone
in computing before then was stupid, or it's not obvious, and definitely not
so obvious that thinking of it in 10 minutes at a whiteboard is reasonable. So
really this is just asking if you studied, rather than if you're good at
algorithms.

edit: I thought I'd read on here that someone was awarded a phd for figuring
out the list cycle detection, but maybe I'm wrong? I don't have my notes file
handy. Either way, it's not an obvious algorithm until you've seen it, and
then it looks trivial.

~~~
teraflop
At the risk of focusing on your specific example, rather than your larger
point which is a good one:

If you're talking about _balanced_ trees, I sort of agree with you. That's the
kind of algorithm where it makes sense to write it once, test it thoroughly,
stick it in a library and never worry about it again. But there are plenty of
other uses for tree-like things. Think filesystems, or the HTML DOM, or JSON
documents, or (generalizing a bit) dependency graphs, and so on...

I actually like tree problems. You can take something with practical
significance (laying out a web page, or syncing two directories, or
simplifying a boolean expression) and strip away the details of the situation
to get to a core algorithm that depends only on the tree's structure. In my
experience, the biggest factor in how well interviewees cope with kind of
question is their ability to reason clearly about what their code is doing,
instead of just pattern-matching from their previous experience.

~~~
x0x0
Right, but for most tree problems, you don't need to write your own tree.
People should know how to _use_ trees, and when one would use them (a map with
ordered traversals.) For graph problems you will often have to write your own
graph for the peculiarities of your problem, but the area I work in doesn't
really have many graph problems.

------
jpollock
I look for test data. Up front. Particularly from developers with 3+ years of
experience.

It demonstrates you understand the problem and are thinking about the cases
that you will have to solve. It also acts as a good safety net for your
implementation.

If you've got test data that will catch a bug, I won't count it against you in
your implementation. However, if you've got a buggy implementation and you
haven't provided test data for it, then it's broken.

~~~
collyw
I didn't do a lot of tests in my last work, but had a pretty good system. It
was in house, so didn't matter so much if the odd bug slipped past.

I just changed job, and the system I have inherited doesn't seem to have much
in the way of automated testing at all, but it works, and it runs. The logging
is really thorough which helps a lot. The bugs I have encountered far wouldn't
be caught by tests.

------
BigChiefSmokem
Hiring Manager: "Wow thanks for including a link to your github in your
resume."

Me: "Yes I have to tell recruiters not to remove it. They think it's contact
info."

Me: "As you can see I can implement search algos, web services, and even have
some samples on how to insert your own frames into a web cam feed"

Manager: "Fantastic! Can we send you a coding quiz?" Me: Ugh. "Sure."

I get an email asking me to implement FizzBuzz.

Give me a break.

~~~
jfountain2015
Blindly hitting candidates with a test is rude. There was definitely a trend a
few years ago where bigger name companies wouldn't even look at resumes. They
would just send a test out to every candidate who applied.

------
dismal2
>Sometimes you'll get stuck. Relax. It doesn't mean you've failed.

Actually, in my experience you might as well walk out the door then and stop
wasting everyones time. Has anyone ever experienced something different?

~~~
chmullig
I don't know about entirely stuck, but I've definitely spent a long time in
the weeds on questions, writing code on the whiteboard that was clearly sub-
suboptimal. I've still gotten offers. It's all about managing the interview,
communicating, asking for a hint or two. Not guaranteed, but definitely
possible.

~~~
dismal2
I just feel like I've been on a lot of unicorn hunt interviews recently
(casually looking at interesting opportunities, currently pretty happily
employed)

------
nlawalker
"Understand what kind of problem it is" could be reworded to "Find out what
the interviewer wants from you, and don't make unstated assumptions", and
could be the subject of its own post.

The biggest problem in technical interviews is when the candidate doesn't know
what the interviewer wants from them. Maybe they want unit tests, maybe a
rough functional spec... maybe what they really want to see is how you'd
explain your algorithm to a junior developer.

If, as a candidate, you think you've been given an egotistical interviewer
that really just wants to see if you can read his mind, mentally reframe it as
a test of your ability to not make unstated assumptions. I've had interviews
when I've tried to clarify whether I need to do things a certain way or
provide something like unit tests, and met with the response "I don't know -
do _you_ think that's the kind of thing you should do?" If you get this as a
candidate, the best solution is to talk a briefly about what you'd do in a
real-world scenario (where you have context, tools, connectivity, time and
teammates). If that doesn't reveal anything, explicitly state an assumption
and why you're making it and move on.

If you give technical interviews, I implore you: when the candidate asks what
you want from them, don't be coy or sneaky about it with the justification
that figuring it out is part of the interview. _Tell the candidate what you
want._ If what you want them to do is role-play a scenario where they extract
requirements from you, tell them so. If you just want the damn FizzBuzz code
so you can move on, tell them so.

~~~
__derek__
> If you give technical interviews, I implore you: when the candidate asks
> what you want from them, don't be coy or sneaky about it with the
> justification that figuring it out is part of the interview. Tell the
> candidate what you want.

Man, this is so true. I've had great conversations in interviews where it was
stated up-front that the goal was to cooperatively dig into ambiguous
specifications. This is (often) an actual part of working as an developer.
Speaking with someone who's being deliberately vague about what they want is
not, unless that's what you think of people "on the business side," in which
case you've got a bizarre understanding of how this industry works that would
be a big red-flag for me as a potential colleague.

------
santaclaus
How uniform are tech interview questions, in others' experience? I've had
questions all over the place, often entirely unrelated to the position at
hand. A while back, interviewing for a gig at Microsoft on a server related
position, I was asked questions about triangle rasterization algorithms and
z-buffers, by an entirely unrelated group. What is the point of these off the
wall questions, and how or should one even prepare for these sorts of things?

~~~
ghrifter
As a junior CS student - I haven't heard about these before... Kind of scared
- Should I know about these kind of advanced things before I get out of
school? I'm not attending a particularly 'rigorous' university for CS

~~~
troels
It seems rather ridiculous to ask graphics-programming questions of someone
interviewing for a server side position. I don't think any kind of preparation
would help you with that kind of questions.

~~~
santaclaus
I asked the recruiter I had been working with about it, and her response was
along the lines of: 'We only hire engineers who are capable of tackling any
problem faced by the company.' ...

~~~
ghrifter
So in other words they want that mystical 10x engineer

------
mikerichards
Do senior software engineers actually have to write code in interviews these
days?

I have no problem brainstorming on a whiteboard with their CTO or senior
architect, but I would consider it silly to do puzzle programs or write java
with some middle-manager lurking over me

~~~
collyw
Unfortunately so. A ten minute chat with the HR drones who are able to answer
virtually nothing about the role followed by a three hour hacker rank
challenge or something similar. I even wrote a small application an stuck it n
Heroku as an example of my work.

I used to be good at those kind of tests 15 years ago. Now I am orders of
magnitude more competent at designing implementing and deploying systems I
have way more knowledge in all of those areas, but I get tested on that
nonsense. I hardly ever write algorithms (occasionally), as I will look for an
appropraite library first.

------
bcassedy
Some great advice in this article. In general I'm a huge fan of the content on
Interview Cake. Lots of good problems to work through with increasingly
valuable hints to step you through if you get stuck.

------
tiredwired
My impression from interviews is that interviewers only care about Big O
Notation and number puzzles. Nothing else matters. 30 seconds to come up with
the optimum solution or else they tell you you're not a good fit. Hours of
whiteboard coding goes fine and they say if you don't do the little puzzle
then you don't know anything about algorithms. Thanks Facebook.

------
henrik_w
Previous submission:
[https://news.ycombinator.com/item?id=6559404](https://news.ycombinator.com/item?id=6559404)

------
soham
Practice is the key. Without practice, even communication isn't easy when
you're being judged.

For core or senior engineering roles at big Internet companies, you're
generally competing with candidates who have practiced for months. So unless
you happen to have an astronomical IQ or you happen to get lucky, it pays to
practice.

Parker is awesome and I love InterviewCake. If you want to come do more
bootcamp-style intense practice, feel free to reach out to us:
[http://InterviewKickstart.com](http://InterviewKickstart.com) :-)

------
bahmutov
I like asking a refactoring / functional programming question in JavaScript
like this one [http://glebbahmutov.com/blog/functional-js-interview-
questio...](http://glebbahmutov.com/blog/functional-js-interview-question/)
trying to make the candidate work through several small steps. At each step
(step itself is pretty simple) I am looking for clarity and the candidate
being able to explain the logic and the solution.

