Hacking job interviews

I looked at Cindy. "He's curious about everything," she said. "You can talk about a hobby, something technical, whatever you want. Just make sure that it's something you understand very well"...

I went to the whiteboard and furiously drew circles and squares and unleashed arrows like Legolas. I was nervous, but not very. Sergey bounced on a ball and asked questions that required me to make things up on the spot...

Later I found out that Sergey did this with everyone he interviewed. An hour wasted with an unqualified candidate wasn't a total loss if he gained insight into something new.

From "I'm Feeling Lucky: The Confessions of Google Employee Number 59" by Douglas Edwards, page 11

What I'm looking for in coders is passion. Ask people for their personal projects and let them talk about it! Ask for a Github account upfront and look at weather they commit fixes to other projects and show initiative, look at their personal toy projects, look at weather or not they're able to work with complete strangers and improve software just because they like doing it.

Some people might not have a Github account. But honestly, most of the people I like working with have one.

Github doesn't reflect the amount of time that somebody put into writing that code. It doesn't reflect how long it took for them to iron out bugs from a poor initial implementation.

My experience is that correctness AND speed both count when a person is developing software. I'm sure you guys have worked with people who are really sharp, can talk the talk, but just flail around helplessly in an IDE, constantly solicit help from their neighbors, and burn up milestones doing very little. I want to make sure that those people don't get hired.

I also want to know that these people are going to use idioms that aren't wasteful, that their naming conventions are sane, that they are being thoughtful and methodical about their implementation rather than grafting edge cases onto edge cases.

...where the following advice is given: "But your strategy while answering this question should not be directly this answer. Generally in the interview you should start with the worst answer and then improve upon it.

If you directly give this answer then the interviewer would know that you had done this question before and may not give credit to you for the answer."

Hmm....

Sound advice, but there's something morally off, IMO.

Do you hate the player or the game, I wonder? Or the online site that helps the player play the game?

As others have commented, interviewing is broken.

Q: What's your github id?

A: Tell you what, tell me yours and I'll criticize your project and language choices. I'm sure I can find multiple reasons to conclude you're incompetent. Oh, look at this, every language you've checked code in is a scripting language. Do you realize you're not even really a programmer?[0]

Google: "There are N houses in a row. Each house can be painted in either Red, Green or Blue color. The cost of coloring each house in each of the colors is different. Find the color of each house such that no two adjacent house have the same color and the total cost of coloring all the houses is minimum."[1]

Answer: "Explain to me the mechanism by which YB2C3O is superconducting, including the role that electron spin plays in the theory. Describe the meissner effect. Posit a theoretical superconducting compound that would exhibit a more consistent meissner effect.[2]

I'm sure its not obvious but the error that both these questions make is that they presume the interviewers worldview, or put another way, they are extremely narrow-minded. Neither of them actually tests whether you'd be good at the job, but instead tests whether your worldview is similar to the interviewers.

The first one presumes that open source is a sign of being a good programmer. This is a complete nonsequitor. While I'm working on an open source project right now, my github account is empty because in my 20 year career, all my contributions to open source projects were prior to github. There are programmers who actually write code at work and then spend their hobby time doing other things. For me it was building robots, and while I did write some interesting code for that, it wasn't really appropriate to open source (too specific to the hardware) and the very idea that I should have open sourced it is a bigoted one. You could just as easily claim that a very active github account is evidence that the employee was slacking off on the last job, working on projects unrelated to what the company was doing (assuming of course they weren't hired to do open source.)

The brain teaser is exactly the same thing. It isn't testing whether the candidate can solve problems, its testing whether the candidate is good at brain teasers. These are very different skills.

Two much better questions:

1. Tell me about something you've done that was difficult, challenging, or highly technical, outside of work, as a hobby or as a personal project.

2. [Google] As you know, Google is a search engine. We spider the web continuously. That produces a lot of data, of course. Give me a high level overview of how you'd architect one component of that process- any component will due, spiders, or analyzers, or the overall workflow.

In both of these cases there are many followup questions. For the first question, you ask them details about their side project, with an eye to learning as much about the project as you can yourself. What this teaches you is whether they can communicate ideas or technology well. And of course, with passion. For the second question you can drill down, using real world examples of issues a search engine has run into, to see how they would resolve them. You should (probably MUST) also give them some of the solutions that you've come up with as part of solving these problems, to get them thinking with enough context to discuss it. The main thing you're looking for here is the ability to generate ideas, even if they are stupid.

In both of these examples you're turning the interview from a confrontational situation where some half assed programmer sits in judgement of the candidate to one where both parties engage in a dialog. In both examples, you've got some opportunity to reveal info about the company, in the hopes of attracting the candidate to want to work there.

I've been on enough interviews that I recognized, in retrospect, were simply exercises in stroking the interviewers ego to know this happens far too often.[3] You may be interviewing for a job they wanted, for instance. Or their friend might also be interviewing. Or they may just be a jerk and insecure and looking for the ego boost.

Or maybe they are sincere but they simply don't know enough about the world to know that people's minds are organized differently... brain teasers are vastly easier for some people than for others, and there's no correlation with productivity as an engineer. Same thing with interest or activity in open source.

[0] I'm not actually bigoted against programers who use scripting languages, but the interest in github is founded on the prejudice that interest in open source means you're a good programmer.

[1] http://mycareerstack.com/accounts/login/?next=/question/323/

[2] anyone with a college degree should be able to answer this, as well as anybody under pressure tries to work out the colored houses question. I'd give them more context and clues than typically are given in these brainteaser situations.

[3] In fact, I'd say its the case the majority of the time. Though it varies widely by company. Generally, if one person who interviews you at a company is doing this, most of them will be as well, not sure why that is.