| I learned CS fundamentals after graduating with a non-CS degree. It was hard, but I enrolled in a few classes through Harvard Extension School which provides access to Harvard classes to anyone and self-study. CS fundamentals have a big impact on the kinds of programs that individuals can write. Asking questions to show that a candidate can write a DFS, leverage multiple data-structures, or do X helps ensure that the individual is capable in this regard. Even for experienced candidates with lengthy portfolios you may find that someone drifted into an operational, management, or product role and has forgotten how to effectively program. However, the format of the whiteboard interview is awful and if one doesn't practice for it it won't turn out well. I'd love for there to be an alternative, but the other options all have their own cons. 1. Take home tests/projects - Requires the candidate to invest time which they may not have.
- At scale this process is easily gamed.
2. Github projects/portfolio review - Many candidates don't have time to work on open source
- The median github project has a low code standard, and is usually made for the purpose of learning something new.
3. Pair coding - Many candidates hate pair coding, personally if a company mentions that they do this in day to day work I will not work for them.
- Difficult to calibrate.
The only alternative I've seen is a "functional interview". Where the candidate is given sample code reviews for standard applications or a broken program to debug. |
Sadly, there seems to be very little correlation though. I've known programmers who graduated from a top CS school with extremely strong CS knowledge, who still write barely comprehensible code. And vice versa, people who have never been taught big-O, but who write the most maintainable, well-reasoned code I've seen. Most programmers aren't building e.g. databases, but writing software that provides business value.
Take home tests can be ok, as long as they are limited in time (<2h). I was adverse to pair coding, but found it to be not as bad as I thought, unless it's 100% pairing all the time. Well, whatever the solution, I think anything that's closer to what day-to-day work at a company looks like is going to give richer feedback/signals than whiteboarding.