Comment by robbrit

11 years ago

I'd like to present HN with a challenge. Come up with an interview process that matches _all_ of these requirements:

Objective - the process avoids human bias (this guy was in my frat, therefore is awesome).

Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview.

Risk Averse - Avoids false positives.

Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume).

Scales - this will be used for tens of thousands of interviews.

Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.

It's easy to poke fun at what is perceived to be a flawed process. It's much harder to propose a solution that satisfies the above requirements. Google has done extensive research on this topic and has done remarkably well with it compared to other companies of similar size.

Xoogler here. I can't meet your challenge. IMO the very premise of a company-wide unified interview process for all software engineers is wrongheaded.

How can you make the interview relevant without knowing what the position is? I was asked the typical CS-type questions in my interview, but the team I ended up on required no theory.

How do you define false positives before you know what the candidate will work on? A superstar in one team will be a dud in others.

And let me add another bullet point to your process wish-list: gives the candidate a sense of whether they want the job. This is impossible when the interviewer is a random engineer from an unrelated team, unable to speak to what the candidate's work life will be like. A Google style process gives candidate very little information.

I would instead propose something very old-fashioned: teams hire for themselves. The usual reply is that this results in an "inconsistent hiring bar", but so what? Teams have different requirements and need engineers with different skills, so why shouldn't the hiring process reflect that? We are not fungible engineering units.

Create an online game/project/test that people must solve in order to get an onsite interview. The game can be customized for individual teams to have more appropriate domain challenges. Spend the onsite interview walking through the code the people wrote for that game. Devil is in the details, but that's the broad strokes of what you are asking for.

It may be hard to find a solution to the full interview problem. I still do not prefer whiteboard interviews; would be happy to code using my own laptop, projecting the session for everyone else in the room to see.