Bullshit Interviewers | Hacker News Reader

Bullshit Interviewers

coderwall.com

19 pointsjonthepirate37 comments

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.

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.

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

How do you know?

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.

> 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?

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.

If I was giving that interview, I wouldn't give a shit if you found the optimal solution or not. But if you could spend a high-energy hour with me iterating over possible solutions, then that signals to me that you're smart, have fortitude, and think outside the box. All qualities I would never hire a candidate without.

At the end of the day, companies aren't looking for just PHP programmers or UI designers. They're looking for problem solvers first. I've said this before in other threads, but the fact that you cannot solve a given "puzzle" does not mean that you're definitely a bad candidate, but the fact that you can sure as hell signals that you might be a good one. And any company that's in-demand can afford a few false negatives here and there.

A PHP programmer's ability to handle saving a company after being hit with a SQL injection attack is surely going to be correlated with PHP coding tenure and expertise. But that being held constant, it's absolutely going to be much more heavily correlated with general problem solving ability, which - as much as it sucks - tends to be correlated with ability to solve "bullshit interview questions"...

But if you could spend a high-energy hour with me iterating over possible solutions, then that signals to me that you're smart, have fortitude, and think outside the box. All qualities I would never hire a candidate without.

Maybe that's the problem? If I'm in that situation, I get more annoyed than excited about playing find-50-ways-to-solve-pedantic-imaginary-crap-from-memory.

For me, it's instant deer in headlights because I'm uncomfortable making a lot of dumb false starts that don't go anywhere then being judged negatively based on the false starts you wouldn't see in a real world scenario anyway. (Some interviewers understand draft-then-improve processes, others expect perfection (and fast perfection) out the gate.)

The big problem with this approach (focusing on what a candidate's done before) is that there's a surprising number of people out there with great CVs who can't actually code. I've interviewed a number of people who looked amazing on paper, and passed a phone screen¹. 7-10 years of experience. Positions of responsibility. They knew how the internet works. They knew their OOP. They could talk about how to troubleshoot performance problems. They could explain MVC to a non-technical colleague.

But when it came to an in-person interview, they struggled with FizzBuzz. They couldn't write the add() method for a linked list. Please understand: I want a candidate to thrive in an interview. I don't say "Please write the add() method for a linked list on the whiteboard," then sit back in silence with a stony look. No: I ask them if they've heard of a linked list, then (regardless of the answer) give them a refresher. I talk about what it is, and draw diagrams of the data structure, and code an example of how it's used & a Node struct they can use, and write a class skeleton for it. If they jump in then, great. If not, I'll suggest they start with the empty list case, and keep trying to be a friendly guide through the exercise. Even then, some candidates can't do it. At all.

This isn't quite a bullshit brainteaser, but it's definitely not a real-world problem. Nobody who got hired would be implementing their own collections. But that's not what the question's about: it's about understanding how two simple pieces of data interrelate, and being able to manipulate them. If a candidate can't grasp that, then I'm not going to hire them no matter what their CV says.

I don't think this is the best way of hiring people. I like the short term contractor approach – candidates get a real-world project to complete that should take 2-3 evenings, and their solutions are code reviewed & discussed. But that's not always feasible for the business or the candidate. So I don't think we'll see the death of this kind of interviewing for a while.

(¹ As a result of these experiences, my standard phone screen now contains some basic programming.)

My experience at DeveloperAuction shows that some companies actually view it as a point of pride that they reject 19 out of 20 Engineers they interview and that it's near-impossible to pass their rigours technical screening. It seems almost seems like they are trying to "trick" people into failing by asking obscure questions that have little relevance to the job at hand.

Of course, what they fail to account for, is the incredibly cost of hundreds of hours spent talking to candidates & administering these silly challenges or the fact that Google's interview data proves that such such logic questions have little predictive value on future on-the-job performance.

I was actually really impressed recently by Stripe's technical interview process - outlined on Quora: http://www.quora.com/Stripe-company/What-is-the-engineering-...

The worst bullshit interview I experienced was one where I was asked all sorts of questions about OO- design principles and concepts. I got the job, and was very surprised that the system, written in an OO language, was in fact, almost entirely procedural with large amounts of code duplication. I wrote a few code generation templates to speed things up for myself, updated my résumé and left after a few months.

Ironically, someone else who I knew, happened to interview for the same job, and didn't know OO jargon as well as me, but was vastly more experienced and very intelligent (he had math, not CS background). He would also have been a great fit culturally and technically for the team, but was rejected.

I still haven't figured out if it was vanity, self-delusion or plain dishonesty that led to those interview questions. But whatever led to that interview format, it failed to choose the right candidate for the job.

The article author comes across as bitter. He's clearly talented and productive, but likely is not strong at the kind of skills you need to solve puzzles in an interview setting.

A good interviewer will be able to spot that and evaluate his skills based on his real experiences and previous successes.

That said, I don't think these kind of puzzles are that bad at evaluating what it will be like to work with someone. If a problem comes up will they throw up their hands and say I never thought I'd have to solve a problem like this?

Because "Email us your answer to ZW5naW5lZXJpbmdAcm9ja3RoZXBvc3QuY29t" with no context as to what that means - on a SQL problem - isn't bullshit?

It's an engineering perception test, like those math problems on billboards that are actually pre-screening interview questions.

I've been around that sort of text long enough to know exactly what I'm seeing and respond accordingly. They might be looking at it like that.

I got it on my first guess, but it's still completely unrelated to the problem at hand.

The "25 horses" question is much less useful, but gives you an idea of how the candidate approaches a problem. Getting the right answer is great, but seeing that someone understands the concept of combinatorics or some kind of process of elimination is much more valuable.

You really want a technical question so that you can see someone CODE the solution, or better yet, give them some task to do that's apropos - that part of the argument is fair. In past companies we've done all three, weeding out terrible candidates with the coding questions, weeding out mediocre candidates with thought-process questions, and selecting only the best with a programming simulation.

(echo 'ZW5naW5lZXJpbmdAcm9ja3RoZXBvc3QuY29t' | base64 -D if you're curious, and the answer to the horse problem is 7 IIRC)

Nope 6, 5 races aka 1 for each horse with photo finish + 1 with the winners of each race to calibrate the first five races.. ;)

Here's the answer if you're curious: http://www.programmerinterview.com/index.php/puzzles/25-hors...

Consider the case where the three fastest horses are raced together initially. My lowest is 7.

Then they would be closer to the fastest horse in there race than any of the horses in the 6th race. Think of it as a calibration step so you can find the positions of every horse by comparing how close they where to the finish line with how close the winner was to the finish line in the final race. (adjusting for a fractionally shorter race as in you don't know it took an minute or an hour but with 98% of the time they got to x so if they had been in the 6th race they would have ended up at y.)

PS: I am treating this as a real world trick question, if your talking about a virtual world where the only information is a horses rank then yea you would need a 7th race with 5 horses assuming no ties.

I'd be surprised if a quality candidate were confused by base64 encoding.

And "all horses run at constant pace"? People are reading too far along skipping this thing - I mean, what's the point in finding the fastest one when they all run at the same pace?

For context, here's the actual wording from the article:

  There are 25 horses and a single race track. The
   track has 5 lanes. Your job is to find the fastest 3 
   horses assuming you don't have a stopwatch and all 
   horses always run at a constant pace. What’s the 
   way to find the fastest 3 in the fewest uses of the 
   track.

That doesn't mean that all the horses run at the same speed - it just means that an individual horse doesn't speed up or slow down while running - if its average speed is 17.2 MPH, it runs at 17.2 MPH for the whole course.

Yeah, I thought of that - but do people look at average speed when timing a race? I was reading the whole sentence in "... you don't have a stopwatch and all horses run at a constant pace." :-)

There's always a choice. Give feedback that you feel this is not the right way to start off and that you hoped to work on solving a real problem. If this is not going to happen, you feel it is a waste of both of your times to blindly follow business theatrics that have been repeatedly proven to hold no value.

The other point is group dynamics do need some outlet for hazing to keep things fun.

>There are 25 horses and a single race track. The track has 5 lanes. Your job is to find the fastest 3 horses assuming you don't have a stopwatch and all horses always run at a constant pace. What’s the way to find the fastest 3 in the fewest uses of the track.

It's not specified that one lane = one horse, so... release all horses at once, pick the top 3 :)

Wait to see which 3 finish the race first.

Pretty easy puzzle, if they were looking to hire a puzzle solver instead of say a PHP programmer. Some people hang their intellectual self esteem hat on simple trick logic puzzles, a skill which doesn't require a great deal of intelligence, so much as time and willingness to practice puzzles.

That question is equivalent to "describe an optimum ordering algorithm". What's so wrong with it?

It's not an optimum ordering algorithm, it's a top-k problem. The overall order is not requisite, nor is the order of the top-k elements. The problem is that it provides no useful insight into whether the candidate will be a capable PHP programmer. The most productive, capable PHP developers I've worked with would not likely fair well on this kind of question, while some of the most useless, hapless programmers I've known live for this kind of question. I agree with the sentiment that these kinds of questions are largely asked to make the interviewer feel smart.

Heh, I was asked the same horse question for a linux driver development position.

Reply on news.ycombinator.com