These types of tests do little more than reinforce stale ideas and turn away unconventional well-rounded candidates. Used to play the game, now I win because I don't play.
These types of tests do little more than reinforce stale ideas and turn away unconventional well-rounded candidates. Used to play the game, now I win because I don't play.
As an employer, do you really want to find out AFTER hiring that the candidate is incapable of understanding a problem based on an oral or written description; incapable of capturing requirements, asking the right questions, and forming an attack plan without thinking about it overnight?
Testing someone's ability to follow along and contribute in real-time is part of the test, IMO. It does penalize "deep thinkers" and still waters, though.
I've had candidates email me a supremely perfect solution the next day, and that's a positive data point too.
Interview questions should hinge on, like, the experience and competence that I already have from having worked a substantial period of time as a professional computer programmer. Not on how cleverly I do on BS.
And I actually generally do very well on this crap but I still hate being impelled to take part in this kind of circus. In fact, it's annoying that I jump to being a top candidate based on this stuff and only then does an employer come up with some mundane requirement that should have been the initial qualifier/disqualifier.
Take 20 developers. If you give them a test with 200 difficult problems they would all score about the same. Instead, give them 4 difficult problems in a limited time frame. Now some of them will look much smarter than others. Only hire these candidates. Now you can believe you are part of a very selective group.
That being said, I think these whiteboard problems can be useful when you think of them as "trying out what it feels like to brainstorm with the candidate about how to solve a problem." That's how I think of them. There are plenty of people I just can't get on the same page with when trying to whiteboard together (different communication styles/speeds/whatever), and it's helpful to know that ahead of time.
When no one knows the answer and the object of the meeting is to find it, it might really be a brainstorm. When the interviewer knows the answer and expects the candidate to get it, where a real discussion isn't possible because suggesting things that aren't The Answer (or asking stupid questions) could significantly hurt your chances, it's a test.
Other questions have layers, like an onion. Those are the good questions. They should divide the candidates into STRATA. I think the stock question is one of those.
Strata 1: Everyone should be able to produce a brute-force, inefficient solution, and avoid the obvious+wrong solution. If not, they should have been weeded earlier by your phone screening.
Strata 2: Better candidates should be able to produce a more efficient and readable solution, sometimes with prodding. Some candidates never get here, even with prodding ("Have you considered x,y,z?")
Strata 3: Candidate skips straight to the correct solution, sometimes provides more than was required ("You shouldn't store data as keys; you probably want to return the time and buy/sell prices, not just the profit".) Interviewer needs to prod and ask questions here ("what's wrong with solution x? why did you do y? What if I want a list of possible trades?") to make sure it's not a memorized answer.
You shouldn't expect that, in ten minutes, your candidate can come up with the optimal solution that took you three hours. But they should be able to understand and recognize that solution if you lead them to it.
Anyone using these questions as pass/fail is doing it wrong, but that's not the question's fault.
But I agree an array would be a more efficient data structure for this :)
I'll never forget my former Bell Labs-theoretical statistican advisor (American. Stat Association decorated!) telling me about accidentally helping his high school-age daughter fail on a take-home probability problem for school.
I think I'd fit in with a company far enough along to have built its MVP (so they're not always in that perpetual crunch mode), but which has fewer than 10 engineers. I really value work-life balance, so I don't want to work insane amounts of overtime all the time, but I could totally live on a below market salary if the other aspects of the job were right.
I'm considering working with a recruiter. Anyone know any technical recruiters in the Bay Area who are worth working with?
Oh, and as always, my email is in my profile if anyone wants to take this discussion offline.