Comment by jedberg | Hacker News Reader

Comment by jedberg | Hacker News Reader

Parent Full thread

I've been interviewing SRE candidates for a long time. In theory, being able to make technical decisions under high pressure is integral to the job.

But interview stress is very different than work stress. It doesn't seem to translate well. Some people do fine during the interview and then crack under real pressure, and some people it's the exact opposite.

I've changed my interviewing to involve very little coding. I might do FizzBuzz on the phone screen just to weed out the folks who really can't code anything on the fly, but that's about it.

After that, most of my interview is me explaining some real works tasks that they would have to perform, and then asking them how they would try finding the solution and if they have ever solved a similar problem in the past, and if so, how. I also ask them about difficult problems they've solved, how they solved it, how they found the problem, etc.

My goal is twofold -- try to figure out how they research problems they don't know the answer to, how they investigate issues; and give them lots of examples of what will be expected so that they can bow themselves out of the process if they don't think it's a good fit for them.

This obviously works much better with people who already have a job, and are more likely to take themselves out of the process, but so far it's worked pretty well.

This is what I do too. I try to engage the candidate in what they have worked on. Then I try to adapt problems to their environment and have them explain to me how they solved them. Or if were to encounter that problem in their environment, how would they solve them.

Granted, you need to be able to program. But being able to recall and implement particular algorithms from memory isn't particularly valuable to the job. I want problem solvers. People who have dealt with complicated problems and found solutions. Or at least know how to find them.

I've observed that candidates hamstring themselves in ways that seem to me bizarre. Indeed the interview is an unfamiliar situation, so why would you do something like use a language other than one you know well, or code in an environment you don't feel comfortable in? I have had those happen in interviews I conduct so many times! This is for the "front-door" interview, not the on site.

Somewhere around halfway through, when the candidate is floundering and failing on an objectively quite simple problem (I promise it really is that simple), they'll say something like "sorry, I would usually have no trouble doing this in Scala". At the outset I give the option to use their own setup or Coderpad, either one works; they'll choose Coderpad and then halfway through say something about wishing they had such-and-such from their preferred IDE.

I think there is some psychology at play here, where candidates think if they do it on hard mode, it's extra points or something. I really just need them to solve a simple problem so we can be sure they know how to code. The ability to code with both arms tied behind your back is not a signal we're interested in measuring.

Yeah I got that too. I would tell them, "do this in your favorite language" and sometimes when they get stuck they say, "I don't really know Python that well". Then why did you choose it?!

Although my favorite was, "I don't know how to write a loop, my IDE usually does it for me".

Reply on news.ycombinator.com