« Immobile Apps | Main | Wireframing and the Reformed Cowboy Coder »

Thursday, January 05, 2012

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

I'm going to disagree somewhat. While I don't really want an interviewee to write large swaths of code on the whiteboard, I'd really like to see someone draw up a database schema for a blog. Or show a high-level architecture diagram for a monitoring/subscription/altering subsystem. I want developers to be able to express their ideas in writing so they can be sold to higher-ups and what-not. But code is highly unnecessary.

I'm going to disagree with your disagreement. It's lazy and it misses a lot of people who like to think about problems before diving in.

For someone right out of college, okay, I can see there aren't a lot good ways to evaluate them. But for someone who's been around longer, it's dumb. It's also rather demeaning.


It also sets the interviewer up to look for a particular solution. I once had a valid whiteboard solution rejected, and thus lost the job offer. When I found out that was the reason, I coded it up and it worked perfectly.

Also had an interviewer ask me to define https status codes for them. "Um, I can google that for you if you want"

Nick - I'm curious how you handle the situation where someone doesn't have publicly available work for you to investigate.

I suspect this might be more common in large corporate hiring situations than in smaller companies. Lots of internal projects, or things you can't really talk about.

I don't think the whiteboard is necessarily the problem. While I will also look at the developer's past experience, the white board is one more tool in the belt, for evaluating someone. The problem you experienced was that the prospective employer thought it was the only tool. I use the white board to see how someone thinks on their feet. I'm not always looking for a correct answer, but it is handy to get someone to start thinking about a problem and how to solve it. Even if they are way off of what I thought the solution might be, I can sometimes see sparks of genius in how they approach the problem. And if I throw someone a problem on the whiteboard and they freeze, I tend to give them some suggestions of where to start just in case the nerves get to them or they may not be used to white boarding a problem.

If you think it's demeaning, then maybe they didn't properly explain to you what they were evaluating, or maybe you have a developer ego to get over. I don't care if you are fresh out of school or 30 years experience, I know a lot of "experienced" developers I wouldn't hire, so years in the field, don't preclude you from the hiring process.

Where I work we use white boards regularly to brainstorm and work through dev problems. Again it's just one of many tools.

If an employer judges you solely by how you perform on a whiteboard problem, then you probably didn't want to work for them anyways.

I totally agree with you Nick, these kind of tests penalise certain personality types without being a reliable indication of skill. Basically you are just testing whether someone can think out loud, not whether what they come up with is any good.

In answer to Mike's point above, 30 years in the field should get you a different hiring process. The idiotic little gotcha questions (hint: try XOR) are more suitable for the recent college grad. I find them absurd in other situations.

Okay, if you can truly not think of any other way to evaluate someone's skills, then fine. In my experience, engineers will jump first to the stupid tests rather than actually looking up someone's public projects or reading their resume.

Now for me, the situation is different. I'm a consultant with a pretty deep well of experience. When I encounter this sort of thing it's because someone isn't paying attention. I'll halt the process, remind them of why they're talking to me, and then gently nudge them into explaining what it is they wanted me to do in the first place. Not everyone has this luxury.

The real reason I hate these sorts of tests is that I've had former employees get tripped up by them. I've seen other, less competent former employees sail through. Usually because they're the sort of novelty loving idiots who test really well.

So, not impressed. Love to see this trend die a well deserved death.

I don't mind that sort of problem, as long as you're not expecting compilable code, and you're more interested in seeing how they approach the problem than the solution they come up with.
In one of my interviews, I was asked a question where the "right" answer involved recursion. I came up with an iterative solution that used less space. Luckily the interviewer was smart enough to understand my answer. (I got the one he was looking for on my second try.)
I try to ask open ended questions that have more than one "right" answer, and see how many they get. Occasionally, I get one that I haven't thought of. That's a good thing.

I had one web developer interview where the interviewer wanted me to solve story problems [having nothing whatsoever to do with programming] so he could see how well I employ raw logic. While I admit to being an adject failure all my life in solving story problems, I had come to the interview completely prepared to defend my developer credentials and never got the chance.

On other occassions I have been asked to create ERD models and the required CRUD stored procedures on a white board. Upon completion of these exercises I always left suspecting that the employer was "idea shopping" for free.

I am against it because I have been in interview situations where I felt like they were just trying to get other points of view on an issue they had and no real intention of hiring. My suspicion became reality when I was told they "decided not to fill the position." I bring a portfolio for design and code samples that I can easily walk the interviewer through to prove I know the code.

Oh, and I drop Nick Bradbury's name. ;)

The comments to this entry are closed.