Hacker News Reader

Comment by gruseom | Hacker News Reader

Clearly, many of us agree that this process is broken; not specifically at Google, but broken more or less everywhere. So fine, what would you do differently? I hate everything about job interviews, on both sides of the transaction: I don't want to ever job-interview or be job-interviewed again. So let's hear some radical ideas about how else to approach the problem. The crazier the better.

View on HN

I've long felt the key is to get the interviewee to do some real work for a day. Pair programming seems like it might work well.

You'd have to come up with some suitable toy problems that you could make significant progress on in a day.

I think ITA's job screening process is quite nice: Post an interesting puzzle and ask anyone to submit answers. Spend as much time on it as you wish.

Their puzzle archive: http://www.itasoftware.com/careers/puzzle_archive.html?catid...

Google used to do that - if you remember their "Great people needed" campaign from 2002-2005, they did fun stuff like putting coding problems on billboards that solved to the phone number you had to call to submit to apply, or the "Google Labs Aptitude Test" that was basically a parody of standardized testing.

I think the reason they don't anymore is that they're a household name. They get tons of applications without any clever tricks. In some ways, I think this is too bad, because it attracts applicants who (in JWZ's words) "want to work for a successful company instead of working to make a company successful." But there's really no way to turn back the clock and make Google hip & unknown anymore.

My personal favourite questions from that quiz were:

* How many ways are there of painting the sides of a cube using four different colors?

* Which colors would you choose?

I really wish we had a culture of portfolios like other professions do. Of course, it's hard to do this because of the nature of our work; the code we create every day is not only company property that is generally kept secret, but is very hard to judge the quality of by means of a quick review with no sense of context. Furthermore, if you choose to merely judge the products the person has coded, assuming they've coded the lion's share of it, it's hard to tell what is going on behind the scenes and any judgment would be based on hypotheses, which would generate tons of false positives and negatives.

Still, something like portfolios are a very practical way of evaluating candidates because you're looking at real, concrete things the person has actually created. A modern coder interview is more like kicking the tires on a used car and then immediately deciding if you want to buy it or not.

This is exactly why a candidate with an active GitHub account will always get fast-tracked through the screening process any time I'm involved in the hiring process. It doesn't matter if the projects there are 40-line utility scripts or heavy-duty middleware; the important thing is how they indicate willingness to write and share your code.

(Of course, if the code on a candidate's GitHub page or blog is terrible, that tells you something too...)

I've mentioned in an earlier thread that I'd try to hire anyone who showed up for an interview with a working robot they'd designed and built by themselves because it's directly related to the kind of software we do.

Another option is having an application (desktop or web) you've written that we could then discuss during the interview: why do you have that feature? how did you implement it, let's look at the code, etc.

I have never had an applicant show up with code examples or anything to demonstrate what he had done (though I did prescreen someone who managed his own OSS project. He was hired) and really it would have a big impact in the hiring decision for a number of reasons. It doesn't have to be OSS or protected company work. If you've ever done a side project for fun you're already ahead of most applicants I see.

Do a much less intensive interview process that just acts to ensures the applicant is competent.

Hire him to work for 1 week at a decent hourly wage.

If he's good, he's good.

That wouldn't work at any company I've worked for, at all. It can often take a couple of days to get completely physically set up (desk, workstation, chair, laptop, etc), and up to 2 to 4 weeks to really get your environment completely set up so you're ready for real work (including figuring out how stuff works, and reading code and stuff).

I don't think 1 week is really enough to do anything important. For a good candidate, anyway. I'm sure a bad candidate can find lots of stuff to screw up in 1 week, especially if they're trying to "impress".

Two things about the latency period you mention. First, it can be mitigated, and second, it's going to happen regardless.

I think that physical essentials such as desk, workstation, etc, should be taken care of already. A smart company would have these items available in the chance that an amazing candidate could start immediately. It's a relatively small overhead cost on things that are going to eventually be required. With exception to the computer, the value of the items won't degrade with time so you might as well purchase them sooner than later.

I do agree that it may take some time for even a good candidate to become productive member. However, this period of time is going to happen no matter what. By having the candidate on as a consultant at first, you at least retain the option of not hiring him fulltime... which would be much a cleaner than hiring him, then firing him shortly after or dealing with a dud employee.

It's basically a "try before you buy" type of deal. No matter what car you're going to buy, it's going to take you some time to get used to it. Does that mean you shouldn't test drive them? As it stands now, the "test drive" is supposedly the interview. To me, it makes more sense to have a longer "risk free" test drive period, especially when you're going to be investing a lot into something.

"However, this period of time is going to happen no matter what."

Huh? Does your company hire pretty much everyone they interview?

No, but if somebody gets hired there is going to be a ramp-up period anyway.

Reply on news.ycombinator.com