What not to do when giving technical interviews (2014)(seldo.com)

What not to do when giving technical interviews (2014)

http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews

176 comments

gjm117년 전

There is at least one serious misconception in this article.

> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"

Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done.

(If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.)

Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like.

It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.

seer7년 전

You are correct, you do get the "can this person actually write _any_ code" info. More than that I think you get the "is this person good at writing trivial code". I'm not sure the groups of people that "write good production quality code" and "write trivial interview code" intersect all that well.

Worse it would push for people that _excel_ at writing trivial interview code, which in my experience is inversely proportional to how much they are going to contribute to the success of the company. Though this is admittedly anecdotal.

Worse still you're going to be sending a signal to the interviewee that you are a kind of company that values trivial code. It's an interview both ways, the company gets evaluated too. The better the dev, the more offers they have so they might just not pick you based on stuff like this. They'll just get a _gut feeling_ that it's not a place they're going to like - that kind of thing.

As an interviewer, I personally don't think it's worth that bit of information, both in a game theory best outcome sense and just as a basic human decency.

gizmo6867년 전

How can you be good at writing production quality code, but bad at trivial code?

No one is looking for people who can write fizzbuzz the fastest, or optimal in any way. They are looking for you to clear a low bar filter.

vinay_ys7년 전

Let's say you are an awesome C/C++ systems engineer. Interviewer can pose a programming problem expecting an answer using recursion. But as you are C/C++ systems programmer, you know recursion is inefficient and you have never used it in production code. So, it will not naturally occur to you to use recursion. You will go down the path of coming with a clever iterative solution with complex hand-crafted data structures etc. If the interviewer isn't well-versed in these low-level techniques then they may end up judging incorrectly. And usually such a low-level solution won't be easy to complete in a short 20-minute interview setting. whereas a recursive solve would be doable. which would lead to the interviewer feeling justified in judging negatively. That's how you can be good at production code and bad at trivial code :)

seer7년 전

Well writing trivial code is still a skill, you could have been coding for 10 years and in your day to day work have managed to remove little annoyances and quirks, allowing you to express business logic concisely. I mean we usually don’t go about implementing linked lists and bubble sorts and such.

And this skill gets pushed down, forgotten.

It’s perfectly possible to write excellent battle tested and performant production code for years without encountering any of the stuff you see in the interviews.

And then they go to an interview and someone demands they wiggle out that piece of info from their long _long_ memory, in an unfamiliar env / os / periphery. With a huge time pressure...

Some people are good at that sort of thing, some people are good developers. Doesn’t mean they’re the same people.

acjohnson557년 전

In my experience, this just isn't a real problem. If someone has any sort of track record in the industry, I've been able to correctly conclude that they can code. The only time I've found sample code useful is for people who are brand new.

tjpnz7년 전

I actually interviewed a candidate once who regularly spoke at tech conferences. This person certainly had an industry track record, yet they failed spectacularly with FizzBuzz and did even worse on the questions about simple data structures. It's possible they were having a bad day, but it's equally plausible that we had encountered someone who could just talk really convincingly about things in very general terms.

bitL7년 전

If you skipped FizzBuzz and went with another programming exercise, e.g. giving some simple dynamic programming or reordering lists etc., would FizzBuzz actually be useful at all? From my point of view FizzBuzz is about asserting dominance right from the start ("oh, you want a job you lowly peasant? here's what you need to do!") and not about actually interviewing anyone. It's a complete waste of time and filters out all candidates that respect themselves that walk away/decline offer, you ending up only with desperate ones.