
Technical and non-technical tips for rocking your coding interview - duck
https://github.com/yangshun/tech-interview-handbook?utm_campaign=explore-email&utm_medium=email&utm_source=newsletter&utm_term=weekly
======
kafkaesq
_2\. What happens between you typing a URL into your browser address bar,
hitting enter and seeing a web page?_

"What happens when I'm asked a question like X? I spout a mutated form of some
canned response I cribbed from a list I found on HN a while back. Because I
hear that's how you're supposed to 'rock your coding interview', these days."

 _3\. What are the things you should consider if you were writing your own
database server?_

"Look, you know as well as I that this job has nothing -- as in, _nothing
whatsoever_ \-- to do with actually building production-grade database
servers. Or anything even remotely analogous to it. Debugging that tangled
mess of poorly conceived, never-reviewed JSON APIs left behind by the other
developer (while you were pestering them about 'disruption' and 'just needing
to get this thing to market') is more like it."

"But hey, since you're playing that game, I can play too: here's a bunch of
catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear
that's the killer answer to give to questions like these. And BTW, if you
really think that people Michael Widenius or Salvatore Sanfilippo would be
interviewing for this job, then your problems are way bigger than I could ever
hope to help you with."

~~~
ptero
I think many technical interviews are simply trying to assess whether the
candidate has his head screwed on straight and the ability to do basic
engineering. As such, the specific topics are practically irrelevant.

At least that's what I try to do when I end up interviewing someone. For
example, can he suggest what sensors would be good for a Lego robot that would
knock a tennis ball off the ping pong table without itself falling off? Can he
describe the logic? How would he test this? How long, on average, would it
take? What position of robot and ball would give the worst case performance
(success or time)? His job will not involve Lego robots, but IME the person
who can give sane answers on those would do a lot better than a coder who
knows one toolkit well and nothing else.

~~~
kafkaesq
_For example, can he suggest what sensors would be good for a Lego robot that
would knock a tennis ball off the ping pong table without itself falling off?_

Right off the bat, this is very muddled question to ask.

For one, "sensors"? I think you meant to say "actuators". Because a sensor by
itself can't knock anything off a table.

More fundamentally, "Legos", for those of a certain age, were entirely _non-
mechanical_ components in their day. So (even though yes, we've also vaguely
seen and heard about, and rolled our eyes at, the newer kind), this just
sounds like asking them to (seriously) consider the question of how to build a
logical circuit out of tinker toys. Yes, it can be done - but on the face of
it, that kind of a question comes off as an invitation to join a mental
masturbation session. Not the kind of question you'd ask of someone you
respect, and whose time you know to be as invaluably precious as you own.

 _The person who can give sane answers on those would do a lot better than a
coder who knows one toolkit well and nothing else._

This is of course a false dichotomy. Especially given that it was -- not sure
how else to put this -- a silly question to ask in the first place.

~~~
chrismcb
Doesn't seem like a very middle question to enjoy. The question basically sats
you have "Lego robot that can knock A tennis ball off the long long table." So
you already have a robot that can knock this off the table, it really isn't
important that if it's made of Legos or not. Now what sort of sensor would you
add so it won't fall off the table as well. It specifically asks about the
sensors. Don't make questions harder than they are

~~~
kafkaesq
_Don 't make questions harder than they are._

There's no need to make it any "harder" \- the point is that just wasn't well-
articulated to begin with. (Noting again that "well-articulated" is _very_
different from fuzzy / ambiguous, in the engineering sense).

And given that the people you want to hire, by definition, are generally very
busy (and have many, many important things to do with their time) -- even when
they aren't currently working (despite the urban legend that "they always have
jobs") -- as such, it just isn't a good use of their time.

------
Waterluvian
What I'd love tips for, is how to politely and professionally protest certain
interview styles. I want to know how to say, "sure here's how to implement
_foo_ but I also want to express that a focus on this coding trivia is
distracting from the skills I feel make me an asset..."

Maybe what I'm asking is tips on how to steer an interview. One of the reasons
I wouldn't even consider a tech giant interview is that I feel like I'm just
one of many cattle being processed through a long gauntlet of nonsense that
distils me down to quantifiable traits rather than who I am.

~~~
thesmallestcat
A warning: If you take this approach, you'd better be a programming god,
because you're going to be the guy who was too good to knock out a simple
coding problem. Every off-by-one error you commit on the job will raise an
eyebrow. People will wonder, does this guy want to be an engineer or something
else? Why couldn't he rip through that problem and teach _us_ a thing or two
on the way? Another thing is you're basically coming in and saying "your
interview process is _wrong_ ". If you're being interviewed as a manager or a
lead, you can afford that risk. If not, be careful, because many people,
myself included, don't want to work with somebody who cannot focus on the task
at hand and feels the need to question things that have clearly been thought
out ahead of time.

~~~
Karunamon
> _...and feels the need to question things that have clearly been thought out
> ahead of time._

I only take issue with this. Many things in organizations that have been
through explosive growth (and sometimes others) are that way because for no
reason in particular and amount to bandaids upon bandaids because nobody's
ever had a chance to actually look at the process. It very well might suck.
Questioning it is the first step in making it not suck.

That said, as an interviewee is probably not the right time to do so. You're
an outsider, you have very little rapport or relatability compared to the
people that already work there. Even if you can point to something and
unambiguously prove that They're Doing It Wrong, your advice isn't in a
position to be heeded.

~~~
thesmallestcat
Thank you, your second paragraph is exactly my point, and I didn't appreciate
everybody else dressing it down in isolation. Of course I don't want to work
with a bunch of robots. But there's a time and place, and please don't throw a
wrench in the interview process to prove how smart you are: I want to work
with people who pursue their initiatives _tactfully_.

~~~
majormajor
I think you'd find more tact with a less combative-sounding opener than "If
you take this approach, you'd better be a programming god, because you're
going to be the guy who was too good to knock out a simple coding problem."

Moving the bit about the scope of the role (jr vs sr vs lead) up to preface
the rest of the comment would've toned it down a bit, but even there I
disagree with the "taking a risk" part - a senior candidate shouldn't feel
like it's risky to offer alternative perspectives. If I got the impression
that the hiring manager thought asking questions would likely be a sign of
"cannot focus on the task at hand," that's going to set off my own flags a
bit.

If you're married to your interview process I'm worried you'd be even more
married to your day-to-day process, and I haven't met a perfect company yet,
so I consider being overly adherent to process instead of results a warning
sign.

~~~
thesmallestcat
Correct me if I'm wrong, but a reasonable approach would be to give the
interviewer the benefit of the doubt and to at least engage the programming
challenge, and to also voice your concern with the process. It's no different
from voicing your concerns first and grudgingly engaging the problem, but the
two make wildly different impressions.

Also, as an interviewee, you stand to learn a lot more from that interaction
than by rejecting it. Hell, I welcome coding challenges as an opportunity to
size up the interviewer's chops!

If the challenge is conducted in a reasonable way, it should feel like any
other design/pair programming session you've had at the office, and it can be
quite revealing of the tendencies of your potential colleagues.

~~~
rimliu

      > Also, as an interviewee, you stand to learn a lot more
      > from that interaction than by rejecting it.
    

If you already learned this is not the company you want to work for there is
no need to waste your time playing stupid games just to win stupid prizes.

~~~
Karunamon
The chances of you learning that information via interview are minimal. Some
of the best teams I've worked in have had the most dysfunctional interview
processes - often for the reason I mentioned in my post - lots of growth,
little time.

------
pfarnsworth
The only answer is: memorize all the leetcode answers perfectly, and pretend
you don't know the answer but that you're "working through it".

At places like Facebook, I heard that you're given several interviews with 2
coding questions to answer perfectly in 45 mins. It's basically luck of the
draw whether or not you know the answer, and the best way to game it is by
memorizing as many answers as possible. I know this is possible because I have
friends that have gotten offers from Facebook and Google by doing exactly
this.

All this does, of course, is create an arms race where interviewers ask harder
and harder questions. It's frankly ridiculous unless we start taking the
algorithmic portion away from the interview.

~~~
ubernostrum
The arms race doesn't proceed all that quickly. Memorize a couple
implementations of breadth-first and depth-first search, an implementation of
longest common subsequence, and big O of some data structures, and you'll get
surprisingly far in most big-tech-co interviews.

------
neilwilson
In a world where there is a massive shortage of developers you are the talent
and the firms come to you to negotiate. Particularly in a world where anybody
can look at your GitHub feed and see what you can do.

So these increasingly ridiculous interview techniques have a more sinister
purpose. They are an extension of the frat tests to become part of an
'exclusive club'. It's just another brand trick to try and get you to invest
so much time and energy into an application that if you actually get picked
_you will work for less money and worse conditions_.

You might be the only applicant, but by suckering you in and getting you to
jump through hoops you are less likely to walk away when you finally find out
they want God on a stick for two pennies for 70 hours a week.

Look up psychological loss aversion and sunk cost. Humans hate to write things
off and walk away.

If I'm hiring a developer I can look at their Github resume and see what style
they are and how they work. Then really I need a chat with them to see if
their personality fits with the existing team personality (ideally you
interview them with the team. The team need to work out if the new prospect
fits with their group personality, e.g do they think chickens with lips are
funny). You pick one based upon that process and set them on a side job to see
how they perform in practice. If they don't perform during probation you let
them go and try again.

That is a far less costly process to go through than rigging up seven round
interviews with everybody.

In some respect if you do set up a seven round interview process and invite
applications you actually want to talk to those who declined the process.
Particularly if they told the selector that it makes no business sense to have
such an expensive and time consuming process and therefore there must be
another reason for it.

Because those are then the ones who can look at the system from the
perspective of the other guy, work out what is actually happening rather than
what people think is happening and then determine it isn't efficient and can
be improved. Which is usually what you are after.

------
deathanatos
> _Tailor your answers to the interviewer’s age._

> _Generation Y interviewers (between 20 and 30): Bring along visual samples
> of your work and highlight your ability to multitask._

> _Generation X interviewers (between 30 and 50): Emphasize your creativity
> and mention how work /life balance contributes to your success._

> _Baby Boomer interviewers (between 50 and 70): Show that you work hard and
> demonstrate respect for what they 've achieved._

This strikes me as an incredibly ageist thing to do. Even looking at the
"suggestion" for my supposed group — what? No; answer the question as
correctly as you can; if you can't, try to reason though it as much as you
can, and try to convince me that you know _something_.

Some of this is good, but that part in particular … just no.

------
partycoder
I think that competitive programming, the kind of programming done at IEEE /
ACM competitions as well as interviews, is very different from actual day to
day programming.

It tells you the person understands data structures and some aspects of
programming, but translating that to productivity/success is questionable.

In addition to competitive programming you've got "collaborative programming".
Programming for maintainability, growth, construction for verification, good
practices, etc.

A good programmer has a balanced combination of both.

~~~
MartinCron
I like to make the distinction between being a good "programmer" and being a
good "professional software developer". Lots of good programmers aren't
necessarily good professional software developers.

I usually make it a policy not to bad-mouth my fellow coders, but I once
worked with a BRILLIANT developer, knew all the trivia, rocked his interview,
impressed the hell out of all of us.

He then spent _two solid weeks_ building an email address validation micro-
service. It was perhaps the most exquisite and technically correct email
address validation micro-service ever built, but was that really what the
business needed?

~~~
partycoder
This happens when there's not a very clear expectation on what the deliverable
is.

Some people have a better intuition than others when it's moment to capture
those requirements. Maybe it's better to spend a few more minutes doing the
requirement analysis to set those expectations clear.

Now, sometimes people tend to underestimate some things. URLs for instance,
similar to e-mail addresses, can seem trivial to deal with at first but
they're actually more complex than people intuitively think. Incorrect
handling of URLs is a significant attack vector.

~~~
AlexCoventry
I think what the GP is implying is that even a 95%-accurate email address
validator would suffice, because any email address you care about is going to
get further validation when you validate the address as functional. So it's
wasted effort, and suggests poor business sense and a need for close
supervision.

~~~
MartinCron
Yes, that is exactly what I was implying :)

------
westurner
This is also a great resource, if you're into studying yourself:

"Coding Interview University" [https://github.com/jwasham/coding-interview-
university](https://github.com/jwasham/coding-interview-university)

------
danblick
"Doing what you do to seek for what you desire is like climbing a tree to seek
for fish." \- Mencius

Coding interviews test for skills that aren't really the same skills you need
to do well as a software engineer. I'm surprised the industry hasn't found any
better way to evaluate job candidates yet, given how much is at stake.

------
macjohnmcc
I have a request. When someone takes the time to travel to come interview with
you at least do them the courtesy of providing useful feedback if you decide
not to hire them.

~~~
autarch
Sadly, most companies will not let interviewers do this for fear of lawsuits.

~~~
bk8335
I have an idea to run mock interviews online with real HR people moonlighting,
so that you can receive their honest feedback, and as a result, be better for
the real thing.

~~~
billhathaway
Have you looked at interviewing.io

------
10-6
For those of you who like solving coding challenges online either for fun,
practice, or to prepare for interviews, here's a list of popular sites:

[https://medium.freecodecamp.org/the-10-most-popular-
coding-c...](https://medium.freecodecamp.org/the-10-most-popular-coding-
challenge-websites-of-2016-fb8a5672d22f)

I also recently put this list of resources together about Algorithms practice
which I think can help out anyone who's preparing for an interview soon:

[https://medium.com/coderbyte/how-to-get-good-at-
algorithms-d...](https://medium.com/coderbyte/how-to-get-good-at-algorithms-
data-structures-d33d5163353f)

------
jv22222
I had an idea for a startup that I think could be a much better solution than
code interviews.

It hinges on the fact you can get a much better sense of a developer after
you've worked with her for a few weeks.

So, here's the startup idea:

Hire a group of developers to to work with you on a small project for a few
weeks. They come in as a (virtual or real world) team and build something
you've been meaning to do, but it's on your low priority stack.

All of the developers in that group are actually looking for a full time job.
As you work with them during those 2 weeks you can see which dev you gel with
best and offer them a job.

In the mean time, all the devs get paid for doing useful work for you for a
short period of time, even if they don't get hired.

So... the startup is a central agency that engages developers looking for a
full time job and then hires them out as a group to help clients do a small
project, with a view to picking one or more of the developers for full time
work.

This is a win for the agency because they have to do less work to convince a
client about a candidate. It's a win for developers because they get paid to
be on job interviews. And it's a win for the client because they get to try
before they buy and as a result will make much higher quality hires.

Possible brand name: TeamHire

Edit: If you like this please feel free to take it and run with it :)

~~~
gwbas1c
This already (somewhat) exists with contracting firms. My team is mostly
people hired this way.

The problem is that the contracting firms still want to stuff your office full
of their workers, so we still need to run diligent interviews. (This means
making sure that they don't coach the candidates through the interview,
because once the candidates are coached, we can't really evaluate them.)

The good news, though, is that we get much better results working with a firm
like this. Most of the people we interview we hire, unlike in the past, where
most of the people we interviewed were straight up morons.

~~~
jv22222
I think, with the right platform (ie like hired.com), you could automate much
of that initial process of deciding who you wanted to be part of your team.

------
gameguy43
A piece focused on non-technical tips: [https://www.interviewcake.com/coding-
interview-tips](https://www.interviewcake.com/coding-interview-tips) (Full
disclosure: I wrote it)

~~~
irl_zebra
I'm not related to this in any way. I'll just say I paid the money recently
and went through interview cake and it was really helpful. Learned a bunch and
added a bunch of tools to my toolbox. Really liked the walkthroughs of
problems bringing it from a brute force answer to optimal. I ended up making
it to onsite final interviews with five companies in SF, which I will be going
to in the coming weeks. Totally worth it.

Only gripe, the online ide you use sucks balls. Half the time I'm debugging
whether I used tabs or spaces, and dealing with errors. No matter how careful
I tried to be, it seemed to default to whatever I wasn't using and threw
errors. Please get a new ide and add in some test cases that maybe tell me how
I'm doing in those tests.

Otherwise seriously awesome site.

~~~
gameguy43
Thanks! New IDE is coming! And test cases after that, hopefully.

------
BeetleB
What I would really like is the ability to ask my interviewers (or better, the
team I'd work with) a lot of questions - both technical and otherwise.

After all, the interview is supposed to be a two-way process. But they usually
give the candidate a lot less time to ask questions.

They want to ask me all the difficult questions to see if I'm good enough for
them. And I likewise want to ask questions (fairly basic ones) to see if
they're good enough for me. Few things suck more than the company demanding a
lot from their candidates, and then sticking you in a team with people who
don't seem to know the basics.

------
aith
This has a bit of a web front end slant. Check out
[https://www.acefrontend.com](https://www.acefrontend.com) for another good
source of practical front end challenges

------
smnscu
While this is imho in a much nicer format, I also maintain a somewhat
opinionated list of technical interview resources:
[https://github.com/andreis/interview](https://github.com/andreis/interview)

------
rickthegeek
We wrote a post around this too if anyone is interested -
[https://geektastic.com/blog/five-killer-interview-
questions-...](https://geektastic.com/blog/five-killer-interview-questions-
for-developers)

------
Clubber
So I wonder. If someone memorized all that trivia, do you think they can code?

~~~
SmirkingRevenge
If its just memorized without understanding, probably not.

But I've been doing a bit of the leetcode/hackerrank challenges lately, and
believe it or not, I actually think it has made me a bit better, by refreshing
bits of knowledge that were getting stale, and really forcing me to think
about performance (many test cases in the challenges will fail without the
fastest implementations).

And they are kind of fun.

------
_pmf_
So this is what we're going to do today.

