DHH anti-whiteboard movement(twitter.com) |
DHH anti-whiteboard movement(twitter.com) |
Just as a minor aside, for anyone interviewing out there, don't fret about syntax that much. If you forget, tell your interviewer "i forgot the exact syntax, but let's assume it takes in x,y,z".
The key thing I'm look for is an understanding of what a function does and how you're going leverage that to solve the larger problem at hand. I'd hope other interviewers are the same way.
There are people who managed to get a CS (or similar) degree but can't program or problem solve, but manage to get hired at enough places to appear to have experience, but still can't program or problem solve. That's why I interview with a programming programming problem that I hope is at least a little bit interesting.
I once had an interviewer give me a somewhat interesting puzzle to work through on the whiteboard, but then he got all stammery and flustered when I asked a few simple follow-up questions about it. I think there are people out there who just can't handle humans and have to use the whiteboard as a shield.
Not because algorithms are unimportant, but because being able to code a heapsort from memory is, from a skills perspective, effectively useless.
As the creator of Homebrew put it: "90% of our engineers use the software you wrote, but you can’t invert a binary tree on a whiteboard so fuck off."
To me, it is enough to know what algorithms you could bring to bear on a given problem, and have a rough knowledge of their complexity.
The things I care more about are: Can you tackle a messy-real world problem, one that doesn't have a clear solution? Do you collaborate effectively as a member of a team? What about your software engineering skills -- is your code well-tested and readable? That sort of thing.
That latter point is important. The best engineer in the world is a business liability if nobody else can maintain their code.
I agree.
We did a few interviews last year, and we had a few whiteboard-ish (people could do it in their heads if they preferred) questions.
However, the whole purpose of these questions (and this was made explicit to the candidate) was to serve as an anchor for a technical discussion, and as a tool to observe them reason about a problem. And as a way to observe them asking questions, because we were intentionally incomplete (and candidates knew).
I felt it worked very well for us.
Also, sometimes such an interview would just be plain fun for all involved. We took it as a strong signal if that happened.
Real-world problem solving is often very different than the very clean-cut computer-science exercises that companies tend to throw at candidates, which nominally have a set of solutions, only one of which is "correct" (in terms of computational complexity).
Personally, I'm a big fan of one of two styles of interviewing.
Pair interviews are great, because they are the closest thing to a real-world test-drive that you can get. During a pair interview, you work on real production code, with a member of the team that you will be working with, and at the end, it's pretty easy to tell whether or not the Thunderbirds are "go".
For non-pairing teams, I usually go with a simple (think "fizzbuzz") programming exercise, followed by a combination of collaborative problem-solving sessions with members of the team, exploring the candidate's background (what problems have they solved in the past?), and also a check to make sure that there's a fit in terms of engineering culture (somebody that hates TDD will hate working with me, for instance).