
On Interviewing Software Engineers - brown9-2
http://www.zdfs.com/code/2015/on-interviewing-software-engineers
======
brightball
Interviewing programmers is easy. Get them to talk about something they've
done that they were proud of and let them explain how they did it into the
deep details.

Good programmers really enjoy talking about the details of the technology and
how they solved challenging problems. You'll be able to see them geek out a
little bit and see that they really enjoyed getting to do it.

Outside of baseline, core competence, that is the litmus test for hiring good
programmers because it shows level of interest. Level of interest leads to
continuous learning, which is essential to this field. Unless you have some
ego-driven reason why you want to believe that YOUR stuff is too complicated
for them to learn of course...but that's usually more of a reflection on you
than them.

I realized this about 5 years ago and I've not made a single bad hire with the
approach since. 100% success rate at this time.

~~~
robbrit
I've tried this in the past when hiring for a startup in two different ways:
one with having the entire interview based around simply discussing past
projects and gauging the level of interest; the other combining this type of
discussion with a coding problems or two.

The result: the correlation between passion and competence is not 1.

Initially I wanted to give them the benefit of the doubt and hire primarily on
talk alone, however I found that some people are passionate and interested yet
can't code very well. After having to fire folks because of it, I decided to
actually make them write code during the interview. Sure enough, I discovered
a few candidates who could talk the talk, but when faced with an actual
problem* couldn't actually solve it.

* When I give interview problems I like to actually give problems that I have faced in my job.

~~~
eikenberry
Being able to talk about past projects is not passion, it is simple
professionalism. How can you work in a field for long without being able to
talk intelligently about it.

I also don't find testing for actual coding skills to be a problem as most
candidates don't make it to the interview if they don't have some sort of
portfolio of code samples.

~~~
robbrit
A portfolio of code samples is not always available. Juniors often don't have
code samples; neither do people who have only really worked on proprietary
projects. I don't like to discount potential good developers just because they
spend their free time doing things other than coding.

~~~
deedubaya
> spend their free time doing things other than coding

This is a valid point. A good work/life balance is critical. But to counter
it, don't you want to look at candidates who _want_ to get hired, so they've
spent a little extra time writing something for potential employers to look
at?

A developer who gives up at "I don't have code samples" isn't someone I would
want to hire.

~~~
robbrit
If they didn't want to get hired, they wouldn't have applied for the job.
Assuming that "I don't have code samples" is equivalent to "I don't care" is a
silly assumption, and one that I've found is completely false in reality. Some
of the developers I've hired have years of experience but no code samples, and
after hiring them I discovered I had made the right choice. They just have
other priorities on the side (children are often a big one).

------
luckydude
Old fart here. My favorite interview question is this:

Tell me about a project, any project large or small, that was 100% you. You
thought of it, you coded it, you wrote the tests, you documented it. The only
other requirement is that the project has to have at least 10 users who
installed, used, and continue to use the project without any help from you.

Lots of people don't have an answer. Some you need to coax a little, because a
small project is fine. For example one that I did close to 30 years ago was
move/copy utilities that used regexp. You could do

move =.fortran =.f

and it did what you wanted (first = is .* and second is $1 and they could
repeat).

Anyone with basic C skills could have done this (or perl, I think someone else
did a perl version and that won). So people would think a project like that
doesn't count, but it does. Small is fine, you just had to do the whole thing
and people needed to be able to use it without asking for help.

This covers a lot of ground and my experience is if you get lucky enough to
find someone who has done projects like this, and there is at least some
overlap with what we are doing, yeah, we got lucky.

~~~
collyw
So would a web app I put on Heroku count? No one else is likely to install it.
I could probably show it to ten of my friends and get them to try it.

------
xamuel
I find these whiteboard problems a breath of fresh air. Coming from an
academic background, I've seen the downsides with the alternatives.

* Talking about something you've done? You're selecting for marketing, not programming.

* Letters of recommendation? You're selecting for ability to network, not programming.

* Academic qualifications? You're selecting for persistence, not programming.

* Offline tests? OK right now because they're a minority, but I guarantee if they became the standard, you'd get an astounding amount of cheating.

I'm not a marketer and I really resent how in academia to have any chance you
have to "sell sell sell". I appreciate anyone who gives me a chance to just
objectively demonstrate my abilities, whether I do well or whether I do
poorly.

~~~
brightball
"Talking about something you've done?"

EXPLAINING something you've done.

~~~
xamuel
It's still marketing. "Something you've done" could be the 'is-negative' repo
that was briefly on the frontpage today [1], and the candidate could launch
into a heart-rending speech on the virtues of modular programming. It doesn't
say anything about whether they can actually program. Or "something you've
done" could be an incredibly sophisticated engine and the candidate isn't good
at marketing and comes off worse than the first guy, despite being a top-rate
programmer.

[1] [https://github.com/kevva/is-negative](https://github.com/kevva/is-
negative)

~~~
brightball
You're looking for an edge case to break a hard rule.

In an actual interview, when they are talking about something they've done and
explaining it, the interviewer will be able to ask more questions and
hopefully (as an interviewer) have enough of a technical background to
separate the BS from the skills.

If two chemists are talking to each other about chemistry, one's not going to
be able to easily just make stuff up that the other blindly accepts.

~~~
xamuel
Well, I guess you might be right with the chemist example, if it's an aquihire
type of situation. With something like Google though, I have a feeling these
kind of talks wouldn't scale well (in general any time you say the word
"hopefully", that's a sign you might be relying too much on luck). Maybe
whiteboards for entry level positions, and a combination of whiteboards and
fireside chats for senior positions?

------
kzhahou
Let's talk about BRAIN FREEZE. And I mean the total, complete, 300-baud mush
when some question --for whatever reason-- kills your ability to think.

I've had it happen twice, and man it ain't fun. The second was like an out-of-
body experience. I forgot the question, I forgot my train of thought, I knew I
wasn't responding, I knew that I knew that the interview knew that I was just
sitting there, saying "ummmmmmmmmm" for about 147 seconds now. Yikes! Yet in
day to day, these would have been easy questions. And TBH I didn't even want
to job at that point.

It's critical that you as an interviewee learn to monitor and CONTROL your
physiological response to stress. And I've learned that as an interviewer, I
try to pay close attention to physical stress responses from the candidate --
flushed cheeks, signs of sweat, sudden lock-up -- when I see these signs, I
back off and let them come back to normal first.

------
edoceo
Interviewing is actually very easy. Every job I post gets 100s of applicants -
so finding them is not a problem. I've got a piece of software that lets me
A/B these candidates resumes & profiles side-by-side so I rank-sort them
quickly. And all "interviews" are small-boxed projects that I ACTUALLY PAY FOR
THE WORK.

See, most interviews are along the lines of: Q: Are you smart and good
looking? A: Yes!

This is why I don't really intervew all. When I take the "best" ranked
applicants I give them actual work; small slices from our actual code base. I
provide them a complete, functional dev environment with one restrciton:
cannot commit to git. I can see their work directly, I work with them directly
and get real-time data on what it's like to work with them, how they handle a
project, how they communicate blockages, how they figure out our existing
systems.

In four to eight hours of work I know who is the right fit for our team. My
cost to find and filter is very very low and rather than waste 2-4 hours per
interview for 10 candidates I pay for 16-24 hours of work for 2 or 3
candidates. The hard costs are the same, it consumes less of my (or my
engineers) time and the candidate fit is very good.

~~~
madcaptenor

      See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes!
    

In my current company we hire a lot of developers through contracting
companies. These people often have very difficult-to-read resumes - mostly
because they are trying to get through filters that work based on searching
for keywords, but they're rarely well-written documents even within this
constraint. Fine, we're not looking to hire a writer.

But a lot of these have "Communication Skills: 9/10" on them. Whether this is
added by the candidate or the contracting company, I don't know.

------
rilita
I've seen a lot of writeups about interviewing here on hacker news. Things I
liked in this particular one:

\- Admission that arbitrary coding challenges that are unrealistic to the
applied job are ridiculous

\- Recognition that you need to understand the engineer and approach things
from their point of view, not from your own selfish view as the interviewer

\- Urging that being polite and humble is important. Even if you don't like
the candidate, there is no need to attack or diminish them.

One question I have: What is wrong with copying and pasting solutions to
issues that have been solved before by others? I tend to do this all the time
myself ( albeit I often end up rewriting the solutions to tailor them more to
the problem )

Overall decent suggestions for interviewing.

------
jmcgough
This is the biggest thing I struggle with - people confuse interview anxiety
on my part with lack of knowledge or experience. You immediately look like a
junior engineer if your mind keeps going blank on technical questions (that
you know the answer to) or if you downplay your own accomplishments.
Interviewing feels like a crap shoot at times, because it's entirely dependent
on me being able to force myself to be extroverted and confident.

However, I have a lot of respect for companies that do interviewing well
(testing skill and experience in a less contrived and awkward manner), and the
ones that have made the process as painless as possible tend to be well-run
companies.

You can learn a lot from the process with each company, especially at an on-
site. Dick-swinging contests definitely happen, which to me means that the
company values rock star coders over programmers who are skilled, pleasant to
work with and good at communication (and moves to the "won't accept offer"
pile).

~~~
hasenj
> people confuse interview anxiety on my part with lack of knowledge or
> experience

Sounds like a bad excuse to me.

If you get nervous on simple coding questions, how will you perform on your
daily work?

Unless you're applying for a very junior position, chances are your work will
involve plenty of technical discussions.

~~~
jogjayr
Because you don't have to write code on a whiteboard with someone staring at
you in your daily work. You're free to sit alone, make a stupid off-by-one
error, misspell a var without feeling like you'll be fired for it.

Technical discussions at work aren't so high-stakes as ones in an interview.
If you do badly in an interview, you've wasted an entire day for nothing. If
you fail to speak in a technical discussion at work, best case no one notices,
worst case they think "Hm. Looks like Brian didn't get much sleep last night".
Just the knowledge of these stakes can affect your performance.

------
krschultz
The single best thing I've done when interviewing is ask people to bring a
laptop with some of their code on it. I don't care the language o the
framework. I don't care if it was school, side project, or even their current
job _.

It puts people on their home turf, where they are most confident and
comfortable. They can show me what they are proud of. I can ask lots of
questions about it and see their thinking without having to be a total dick
asking for an esoteric algorithm on a white board. There's also a lot to be
said for how well someone know show to use their tools. Are they navigating
proficiently, or are they poking around the IDE like they just started out.

This sounds like a softball interview, but you would be amazed the number of
people it weeds out. You probably need something more rigorous beyond that,
but don't start with the hard problems when an easy filter can really give you
a lot of insight.

_(Note that generally you can't share your current job's code, but people are
fairly comfortable opening their own laptop and poking around in the code. I
never ask for people to send me that kind of code).

------
sombremesa
I work at what can only be defined as a megacorporation. The interview process
is a machine, and more often than not interviewers are not personally invested
in the process as much as they could be - the candidate is destined to be on
someone else's team.

This is of course a double edged sword - on the one hand you only have a
generic sense of what you are looking for and on the other you have no
vendetta for hiring someone who is sub-par to fill your urgent needs.

------
matthewcanty
When did grey text become so fashionable? I can hardly read it on my phone.

On desktop found this app to adjust contrast per-website:

[https://chrome.google.com/webstore/detail/high-
contrast/djcf...](https://chrome.google.com/webstore/detail/high-
contrast/djcfdncoelnlbldjfhinnjlhdjlikmph/related?hl=en)

------
siegecraft
"All existing interview techniques are bad because they're just about proving
the interviewer is smarter than the interviewee. Now let me tell you why my
interview technique is so much better and I am so much smarter than those
people."

~~~
kamac
I think it's your personal impression, because I didn't feel like the author
was bragging about how great his method is.

~~~
siegecraft
Eh, maybe bragging is too strong of a word, but it did feel rather
hypocritical that he propped up the straw man that interviewing was all about
making the interviewer feel smarter than the interviewee. Then proceeded to
tell an anecdote about how he was smarter/better than all the other people
interviewing a particular candidate.

~~~
luckydude
I didn't get that from his writing. Yes, you can look at it that way but it's
perhaps cynical. I thought he was genuinely trying to say here is a better
way.

You should read it again. He's talking about kindness and giving people space
to come out their shell (amongst other things). That's not him bragging,
that's him helping the interview go well (if it can).

Shrug. I thought it was a good article.

------
UncleChis
One thing I find annoying is that interviewers expect you to think out loud
"continuously". If I stop talking for 30s or 1 minute, I am in trouble. That
is not applicable to everyone. I myself feel more confident to think in silent
(may be 5-10 minutes at least) before I can tell interviewers my whole train
of thought. Speak out loud what I'm thinking could easily interrupt it!!!
Everyone is different!

~~~
kelukelugames
You have to 1) think out loud and 2) finish as fast as you can. Those are
often in conflict.

------
edw519
8\. Have them code.

For me, nothing else comes close to evaluating talent.

I prefer making my candidate comfortable and writing something simple. 15
minutes, privacy, a drink, and pencil & paper. I hate white boards for this.

I come back & see what they've done. It doesn't have to be perfect. It doesn't
even have to be right. I am less concerned about their code than our
discussion about their code...

    
    
      How did you approach the problem?
      Why did you name your variables like this?
      What is that supposed to be doing?
      What happens if...?
      What would you change if I added <x> to the problem?
      How else could you have done this part?
      Why did you choose your way?
    

15 minutes of coding followed by 15 minutes of Q & A about their code tells me
alot. Not everything, but alot. And no programmer, no matter how nervous or
introverted, should have a problem with this. As a matter of fact, most of the
best programmers I've interviewed have embraced and enjoyed this.

Fizzbuzz is a great problem for this. I'm still amazed by how many
"experienced" programmers can't do this.

~~~
Tenhundfeld
> I'm still amazed by how many "experienced" programmers can't do this.

... can't do this in your incredibly artificial, unrealistic context.

I hate live coding in an interview, especially on paper or whiteboard. I know
you say you don't care about syntax and little stuff, but that's not what
happens in my brain. I suddenly forget the most basic things. "Wait, do I use
semicolons at the end of lines in Ruby? Aaaah, I've been using Ruby for 5
years. How can I not know this. I'm going to bomb this interview. I should
just leave now."

I know it sounds ridiculous to you, but something very similar actually
happened to me. Give me a block of time and a sample problem to work on at a
computer, fine. Ask me to refactor code that already exists, whatevs. I'll
happily write and discuss code. Just don't give me that blank piece of paper.
My brain goes crazy.

And the funny part is that I've been told one of my best qualities as a
developer is my calm, thoughtful performance under pressure. When somebody
accidentally drops that table in production or both load balancers go down,
I'm your guy. I'll get it fixed quickly, without a lot of panic and fussing
about. Just don't give me that piece of paper in an interview.

I can't explain it, but it's true, for me. Maybe it's just that I deal with
real crises often enough to have developed a mental muscle for it, but I
interview so rarely that I don't have the patterns yet. Either way, I think
you're missing out on great candidates with this approach.

~~~
smikhanov

        ... can't do this in your incredibly artificial, unrealistic context
    

Oh, then you're a non-hire (rightfully so). If you can't adjust to such a
simple context, there's no way I can be sure you can handle an occasional
tight deadline, urgent and critical failure in production, rewrite of stinky
and hairy piece of code left by a less competent colleague, external system
that mystically fails for no reason and writes no logs whatsoever, etc, ad
infinium.

Programming profession is hard and full of rough edges, unfortunately.

~~~
krisdol
How does your team manage to accomplish all these tight deadlines while having
to use paper and whiteboards to rewrite stinky code? Do your production
servers run A4 or legal? What's your cardstock uptime? I've had trouble
switching to glossy for all but the most specialized of tasks, I'd be really
curious to hear about your paper stack.

------
klenwell
I got excited when I saw the cover of Thinking Fast and Slow. But he failed to
mention what I found to be one of the most insightful parts of that book:
interviewing.

He kinda touched on it at the end with #1: "Know what you're looking for".

Kahneman is more explicit in Thinking Fast and Slow: come up with a simple
rubric of 5 or 6 traits you're looking for in your new hire and ask questions
that allow you to score each candidate on a scale of 1 to 5 for each. When
you're done, choose the candidate with the highest score.

Maybe the technical ability score gets double-weighted for developers. But it
seems like a lot of the interview process (and discussion of it) fixates on
this. Well this and, of course, vague impressions of the candidate's
personality. In my experience, this misses other key things that make up a
competent programmer and worthwhile employee.

In the spirit of Thinking Fast and Slow, here's a question. As an interviewer,
what are the 5 most important traits or qualities you look for in a candidate?

~~~
zdfs
I'm still working my way through the book, but glad to know he touches on
this.

------
buckbova
If every job seeker was 100% honest about their skills and experience we
wouldn't have to go through this nonsense.

~~~
Tenhundfeld
100% honest AND 100% correct. Many of the best developers I've worked with
underestimated their abilities, and many of the worst overestimated.

Experience can be similar too. Many of the best see themselves "merely" as an
important contributor to a team effort and remember the mistakes they made,
etc. Many of the worst honestly believe they did a great job, led the effort,
etc.

~~~
rogerbinns
> Many of the best developers I've worked with underestimated their abilities,
> and many of the worst overestimated.

That would be the Dunning-Kruger effect in action
[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

------
angersock
I think the comic sums up pretty well how stupid and broken large parts of our
industry are--99% of the time we're fighting dumb things like bad CSS or
sudden design changes or something else.

It really makes me wonder if our tools are broken, if we're all trying to
solve the wrong problems, or if we simply are hiring too many people for
whatever the project is.

------
geebee
I really liked the cartoon. Clever, and insightful - we go through very
difficult and interesting problems that are often unrelated to the job.

I disagree a bit with the center pane, though (with the dog typing loops and
the caption "I have no idea what I'm doing"). It is, in my opinion, very
impressive to be able to find the largest sum of all square matrices in an NxN
matrix at a whiteboard in 45 minutes. It's impressive enough (especially not
knowing the exact question in advance) to be a positive indicator of the
ability to do what is in pane 3, especially considering how many variables and
logical basket weaving is often involved in moving some text a few pixels to
the right. As long as you are willing to tolerate a very high false negative
rate, this could be a good way to go.

Unfortunately, it does mean that most developers looking for jobs will need to
intensely study data structures and algorithms, and walk around with them
loaded in "exam ready" memory" in a way that few people would need to simply
to do their jobs. Personally, I'd say most people would retain this mental
state anywhere from 1-3 weeks after a college algorithms course, provided they
were a good student who understood the material. And it also means that lots
of developers who could absolutely do this if they were willing to drop
everything to study 50 or so hours and train at a white board will not be
hired because they were more interested in just doing their jobs (which,
ironically, is what they'd be doing at the new job). So we are going through a
very inefficient re-taking of exams every time we interview. So I'm not
surprised that some people have decided to stop interviewing, or just give up
on finding a job that requires this sort of interview.

It's up to a company to decide if they want to give up on hiring these
developers, or to tolerate this kind of false negative rate. However I have
close to zero interest in hearing about how hard it is to hire good developers
if this is their approach, since it suggests to me that the aren't going to
make any effort to find a way to avoid these false negatives.

------
iblaine
Interesting post. This author lives in Santa Barbara. Hiring in SB is vastly
different than it is in SF. Due to the small pool of companies and talent,
everyone knows everyone. So there's not much mystery to it.

------
drincruz
I've noticed that there is a great number of interviewers that do not take the
initiative to just be nice. I suppose they just forget that the interview
process is a two-way street.

------
kelukelugames
I feel like Notch because I know I will never create something as popular as
my first comic. I put so much more creativity and effort into writing this
post but only a few hundred people read it.

[http://kelukelu.me/interview/powerpose.html](http://kelukelu.me/interview/powerpose.html)

Also, I'm embarrassed by how bad my art is. I was learning to use a brand new
tablet.

------
victorhn
> Or write a function that takes an integer and returns that integer's index
> on the Fibonacci sequence. That last example: they wanted me to do this with
> pen and paper over the phone.

I fail to see what is the difficulty on that, looks like very straightforward
and easy question to do, even over the phone.

~~~
rilita
I think the focus was on the fact that it is arbitrary. The person you are
interviewing may not even know nor want to care what a Fibonacci sequence is.
He is saying the goal is to understand the candidate and the way they think,
not to trivia them about random stuff ( since it will put them down if they
don't know it )

------
panamafrank
So if interviewing is about finding the good hires, what's a bad hire?

------
zdfs
Thank you to everyone for reading (whether you agree or not).

------
dmansen
In every challenging software development job, you'll be solving problems
you've never encountered before. That's the nature of software. Once you
understand the problem, you move on to something else.

So, why is it such a stretch to ask people to solve Fibonacci? I don't
understand this mentality. Reminds me of "why should I learn calculus? I'll
never use it in real life!" from college. You're supposed to be a professional
software developer, and should be able to handle an unfamiliar problem.

If you're a professional musician auditioning to play Mozart, you wouldn't
complain that your audition piece is Beethoven.

~~~
vonmoltke
> In every challenging software development job, you'll be solving problems
> you've never encountered before.

The problem is, the vast majority of software development jobs are _not_ this.
That was the point of the comic in the post. There is a whole lot of
maintenance, API gluing, and spec work that needs doing. Even at the "elite"
companies like Google.

The current trend in hiring seems to be at least partially born of Google's
ill-advised[1] strategy of hiring generic software engineers that could
theoretically be slotted into any role at the company. Hire for a position. If
that position involves challenging, novel problems then throw things like that
at the candidates in the interview. If it doesn't, don't.

[1] After they reached a certain point as a company

