

Hacking the coding interview - wpnx
http://www.restlessprogrammer.com/2013/09/hacking-coding-interview.html

======
jwilliams
My tips reflect my attitude more than general advice, but here goes:

\- Decide what _you_ want out of the interview. How do you decide to work for
this company? An interview is a two-way street. Engage with the interviewer,
connect with the culture. Push back (a little) on their ideas, see what
happens.

\- I hate puzzles. I think they're junk and have never found them to be good
predictors (for either party). I usually (1) parlay it into some relevant
experience "I encountered something like that when I..." or (2) describe how
I'd solve a problem rather than dig into it [1].

\- Demonstrate your common sense, flexibility, good social skills. Talk about
how you work in a team. Talk about what you do when you encounter a problem
you can't solve yourself. Talk about any self-lead learning you do. You need
to fit in and you need the company to demonstrate they want you to help. Even
if the interviewers aren't aware of it, more often these form the lasting
impression from an interview.

[1] Long, long time ago I was asked to produce a "sort" implementation. So I
drew a bubble-sort. When one of the interviewers was somewhat outraged by
this, my reply was "I didn't have any constraints, so I optimized for
maintainability." A bit cheeky perhaps, but worked in the context.

------
DigitalSea
I am completely against written tests or questions that ask abstract questions
and ask you to write algorithms. Unless you're going for a position that
requires a PhD in computer science and your job will be writing algorithms and
solving overly complex problems, the pen and whiteboard approach just doesn't
work in 2013.

Hiring a developer shouldn't be as complicated as some companies make it out
to be. Maybe for the likes of Google it has to be a lot more complex than
others because they have an image and large workforce that depends on people
being excellent self-managers and workers that require minimal management.

For smaller companies you are wasting your time and my time asking me
questions that test my ability to remember things more-so than they do to
search and find answers. Lets face it, most developers these days are hackers.
I've never met a developer who knows the answer to everything, I've seen the
best of the best using Stackoverflow to find an answer to their question.

The difference between a good developer and a great developer is knowing a
little and for the stuff you don't know, knowing exactly what to Google when
you encounter a problem you can't solve off of the top of your head. As Albert
Einstein famously said, "Never Memorize What You Can Look Up in a Book" — that
doesn't mean don't learn anything, but get the basics down and eventually
you'll know what to Google when you don't know something.

The real test of any developer is if they're a good fit for your team, have
good work ethic and can get the job done. You can find the smartest developer
in the world but they might not be a good fit for your team. Culture matters
as does a good work environment with compatible people.

The best way to test a developer anywhere in the world is to give them access
to a computer, an IDE and their environment of choice. Then ask them to build
you something. Don't ask them to write binary search code if they're being
interviewed for a front-end position, ask them to build something.

Welcome to your interview; build us a blog, build us a todo app, write a
simple Wordpress plugin, write a jQuery plugin or what my current employer
did: they brought me in for a trial for a couple of days (paid) and asked me
to get my hands dirty on a real project they were currently working on. Just
threw me in the deep end and after two days they had a good idea how I worked
and if I was a fit.

~~~
thedufer
> they brought me in for a trial for a couple of days (paid)

How does this work? Did you not have a job at the time? If you did, there are
more often than not legal issues involved, depending on the terms of your
current employment. This comes up a lot, but I don't understand how it works
from a legal standpoint.

The other issue, of course, is that a good developer doesn't have to put up
with that, so why would they? I did it once, looking for a job out of college,
but never again. If the "interview" is going to cost me more than a couple of
hours, then I will work somewhere that knows how to make a decision.

~~~
DigitalSea
I never had a job at the time when I took the trial. I had just finished a
contract position with a media company and was looking for a permanent
position with a smaller studio.

------
AznHisoka
"So you're interviewing at Google and lunch time comes around. Food is free so
you eat way too much, especially carbs. Your post-lunch interview is a
disaster since you have trouble focusing due to lethargy. True story."

Ha... I might have chosen the wrong cafeteria, but to me the food was a
disappointment during my Google interview. The veggies were way too hard, I
didn't like tacos, some of the meat looked indecipherable, and I was fumbling
as I wondered whether there was a line, or whether I was looking stupid. I
kinda wished there was NO free lunch.

~~~
aegiso
I honestly can't tell whether the last sentence was intended to be a punchline
or not. But if so, good job!

------
justinsteele
The idea of using "B-list" companies makes me a bit disgusted honestly. Have
we put ourselves on such pedestals that we use other people's valuable time as
unknowing practice runs? I would never interview somewhere I was not
interested in working.

~~~
jjoonathan
I can think of three reasons for interviewing at a "B-list" company that have
nothing to do with putting oneself on a pedestal.

1) You might actually like the work/environment/personal growth
opportunities/company health at the "B-list" company once you see it in
person. Admit it: your initial classification involved a healthy amount of
guesswork and is probably not fantastically accurate.

2) A stupid mistake in your A-list interview hurts both you and the A-list
company, potentially dramatically so. You help both them and yourself by
practicing.

3) Your increased bargaining power decreases the chance the A-list company
lowballs your salary, shooting both you and themselves in the foot (hiring
your replacement is expensive, lost productivity due to dissatisfaction is
expensive, envy-poisoned work relationships are expensive).

~~~
RougeFemme
I understand how a mistake in an A-list interview hurts you, but how does it
hurt the A-list company?

~~~
jjoonathan
Because it artificially reduces the talent pool they're drawing from. They
might wind up hiring someone less competent who was better at signalling or
making concessions to someone who wasn't as far ahead of the pack as they
thought based on interview performance. Time and opportunity cost also factor
in, of course.

------
yanilkr
The talk about tech interviews reminds me of this clip.
[http://www.youtube.com/watch?v=OXRi28W-ENY](http://www.youtube.com/watch?v=OXRi28W-ENY)

~~~
WalterGR
The above link is to the first minute and a half of the interview sequence in
the original _Men in Black_ movie.

------
mountaineer
There are some good tips and links here, but I don't understand the "hacking"
metaphor. There are no big secrets. It all comes down to the "always be
coding" idea that was presented a few months ago [1]. It just takes discipline
and time-management. Succeed at that and many offers will come your way.

[1] [https://medium.com/tech-talk/d5f8051afce2](https://medium.com/tech-
talk/d5f8051afce2)

~~~
rtfeldman
The article's thesis is basically the exact opposite of this.

It states in no uncertain terms that "always be coding" is wrong. That you
should instead spend your time practicing techniques you never use when
creating actual software, and that you should also maximize your interview
count for salary leverage.

"A lot of what I'm suggesting to do is pretty extreme. A lot of the skills
here are not something you learn by doing a standard software engineering job
(or get coming out of college). It's especially hard for more senior engineers
to do technical interviews since most have limited time due to familial
obligations and haven't taken CS 101 for quite some time."

------
johnnymonster
I really appreciate this article! So many people go to interviews and are
obviously unprepared. The simple fact that a person is unprepared for the
given task is an obvious show on their personality. This goes for just about
anything, not just interviewing. Would you just walk into a test without going
to class first? Would you try to fly a plane full of people without first
being taught how? So why would you go to an interview without knowing whats
expected.

\- Know that an interview is a 2 way street. Have questions to ask the
interviewers, if they ask you silly algorithm questions, have them explain to
you how they use those algorithms in the workplace.

\- Make sure the job your interviewing is a place you can fit into, not just
the other way around.

\- If you don't know something they are asking, just be upfront and say you
don't know it, then ask them what it is and how its used at their company.
Take note of this for future interviews.

\- Don't let the interviewer lead the interview the entire time.

\- For those of you haters that don't like the B-list idea, you could ask your
peers that work at other places to interview you. (Interesting idea for a
startup? Mock interview company? :)

~~~
hatu
I don't think this analogy makes sense. I HAVE flown professionally for 6
years and now I'm jumping through cargo-cult like hoops to show that to a new
airline.

------
mcv
I've never actually interviewed at a company that interviewed like this. Is
this the usual way in the US?

~~~
scottschulthess
Yep it's pretty common

