Comment by zainny | Hacker News Reader

Comment by zainny | Hacker News Reader

Just as with all the other such articles, there are probably going to be comments on this one talking about how interviews like this are the exception. That you just got crappy interviewers and as the article itself notes, you probably didn't want to work there anywhere.

If you are the kind of person who would write this comment, stop now. The truth is the vast majority of technical interviews for developer positions are conducted in this bullshit manner today. The only way to solve this is to do what this article is doing and continue to draw attention to the fact that the way people are hired for software developer positions is completely and utterly broken. We need to make shitty technical interviews the exception, not the norm.

I've been in interviews in the past where I've just wanted to scream at the interviewer - Why, why aren't you asking about my portfolio? Look I've built amazing things that people love. With my own hands. To a high quality. On time. You can see and touch them. And it's exactly what you want me to do here in this role. JUST LOOK.

Nope. Hey it would be great if you could please while standing on your head, design a spice rack for a blind person (I've seriously been asked this), with one hand touching your nose. Oh and can you wear this red clown nose. This shit's important.

> Why, why aren't you asking about my portfolio?

Awhile back I brought in two candidates for an interview. One candidate's resume had experience going back to the early 90s, programming games on the original Game Boy in assembly, and pretty much every platform after that. Lots of senior developer titles, lots of products to his name.

The other candidate had graduated a couple of years ago from a game programming school, and worked on a couple of miserable movie tie in games.

I was looking forward to the first candidate for weeks, I thought about not even calling in the second candidate, but opted to anyway "because why not".

So I get to the interviewing part of things. "Heya, we are doing embedded development here, so we have to do a lot of basic things like data structures on our own. Here is a binary search tree, can you give me the code to walk it in order?"

15 minutes later, not a line of code. OK, so, instead, walk a link list. Nope, the rest of the hour went by and he wrote a sum total of 1 IF statement, and it was wrong.

Candidate B? Holy shit. So the walking a BST took less than 5 minutes, he did Find First Cousin in a tree in another 5 or so, he then spent 15 minutes implementing a bit packed RLE system, and another 15 minutes doing some other random crazy crap I asked him to do.

He blew through all my interview questions in under an hour.

Unless I have some assurances that a candidate actually wrote the code on the projects on his or her resume, I am going to demand that the candidate write some bloody code on a board.

Not being able to walk a linked list sounds pretty dire. Is it possible that candidate A hadn't written tree-walking code recently? Did he have access to reference materials?

I aced my CS degree, but a few years later, after endless CRUD, I was given a task at work which involved constructing and analyzing hierarchical data. After realizing that it would be modelled with a tree, and a few minutes with my textbook and it all came back to me. If I had been given the same task in an interview, I may well have flunked it.

I personally allow candidates access to Google and whatever else they need on programming tests. That's how they'd solve problems in real life, so why make them relive their final college exams in an interview?

Hopefully the recent news articles about Google's data-driven analysis of these techniques will start moving things in the right direction... there is ZERO predictive value to many of these questions, and they bring with them a tremendous - and unaccounted for - cost around interviewing & rejecting qualified people.

That's not quite what the analysis of their hiring practices says. All it says is that among those that pass, it does not predict their future success with the company. It may however be a good predictor of negative success--those that don't pass would not have gone on to do well at Google. Of course their data cannot determine that.

In defense of scripted interviews, if your doing a lot of highering it's useful to get a less biased view of the candidates. It's really easy to rank outgoing personable people you like far higher than they deserve, but if they completely fail FuzzBuzz your going to dig a little deeper.

That's not to say you sould only asked scripted questions, but there are plenty of good developers the question is often are there weaknesses a good fit vs there strengths.

dig a little deeper.

I think that's a key point. If a candidate seems mostly okay, but then something goes wrong, dig deeper and don't just immediately send the form letter rejection.

Now, if you dig deeper and discover they are actually not good enough for you, then send the form letter rejection, but don't hallucinate their incompetence out of only a few chats while completely ignoring their entire portfolio and/or work history.

> The truth is the vast majority of technical interviews for developer positions are conducted in this bullshit manner today.

How do you know?

Would you say all data structures and complexity questions are bullshit? Mrainteaser / estimation questions? Is all coding bullshit, or only on whiteboards? Only coding algorithms from college? Is asking someone to code 'fizz buzz' bullshit? I'm interested to hear where you consider the boundaries to lie.

Or have I misread your post, and you mean something else?

It depends on who you want to hire.

1. Do you want a team member who can plan, investigate and research unforeseen problems, brainstorm and contribute to the code? Then the one on whiteboards is bullshit UNLESS it is a brainstorming question - with a laptop next to it - and you are both working on the problem together - and ideally neither of you know the answer.

2. Or does you company have a clear knowledge of what lines of code are needed to be written for the next 5 years. Then sure, go ahead and do the whiteboard interview. Or just train a monkey, at least they are cute and cheap.

A whiteboard interview typically just tests memory recall under a stressed situation. It might be what you need if you require a hacker for a Die Hard sequel where there is only 90seconds to figure out how to line up the encrypted polycube nano-algorithm before nuclear meltdown is initiated. Or if you require a monkey.

I think there's a very simple rule anyone can and should follow to not fuck up interviews: Don't ask people to do things in the interview you wouldn't expect them to do in the job.

Examples:

(1) Do people in this job regularly write code on the whiteboard? Lack access to a search engine? No. Then don't do it in the interview.

(2) Do people in the job design spice racks for blind people? No. Then don't ask them to do this in the interview.

(3) Do people in the job regularly find themselves coding something on the level of fizz buzz? Yes? Go ahead and ask!

(4) Do people in the job regularly find themselves writing code to traverse linked lists? Find loops in graphs? Yes? Go ahead and ask.

Verify people have the skills they need to do the job you're hiring for. It really really is as simple as that.

Reply on news.ycombinator.com