I'm a CS student and most students I know dislike whiteboarding too (and by extension many, if not most, YC startup employees do too). But I'm pretty okay at them now, having had lots of practice. The key advantage for students I think is the ability to have sustained practice over the course of a month (e.g. > 4 onsites over the course of a month), which most students can afford since their schedules are flexible. Also, I've recently had interviews at a few YC companies you've heard of, and they had me code on my laptop. I didn't whiteboard at all except for system design questions.
Reply to below: Most companies have me do at least one non-technical system design and/or talk-about-a-project interview.
IF they have you write code, think twice about taking the job. That's an indicator of a junior engineer conducting an interview in a company that didn't care enough to work out a good process.
Seriously. I've been working for startups and starting companies for 26 years, and for half that time I've been building teams. I stopped asking people to code a long time ago. If they can't code it will be obvious by their answers to your questions (And I'm not talking about coding brain teasers either.)
Ask them about a project they worked on and to explain to you how it worked. That's sufficient.
I'm not trying to be pretentious here. But all big companies (Google etc.) I've interviewed so far asked me to code, what should I make of your advice?
I have worked at companies that don't expect candidates to code during interviews, and I have worked at companies that do. I was personally acquainted with programmers who couldn't write working code at the former, and I have never heard of a programmer who couldn't write working code at the latter. I'm sure this perfect correlation anecdote fails to generalize to all workplaces, but I would not accept a job at a company that hires by bs-session again.
Sorry, I think google is incompetently run. That they whiteboard, and want prestigious degrees, and all that other BS is just a smell of their incompetence. (Their performance in key technical areas is the proof... but I understand to most readers here they are probably starry eyed about google, while I've competed with them and kicked their ass in the market.)
I counter this. I am not disputing your observation.
When I interview people, I start by asking the interviewee to tell me his/her background, then start conversation about things they just told me. If they mention Ansible I expect them to be able to answer a few technical questions regarding Ansible. If the mention they have Python experience, I expect them to be able to read some code and tell me if they spot a bug or if they knew a solution to the problem. I expect some side conversation like "actually there is a bunch thunder methods in Python, etc" (which is actually related to the question). If you just answer the question, that's boring. There is a skill in interview. You need to make the person enjoy talking to you at work. We are not robot.
I don't care if the person can implement heap or not. If you use a tool enough, you need to go beyond syntax. If you can't show me how you would debug the code, the interview would end there. print, dir with print, pdb, interpreter, whatever. Coding question can help eliminate candidates who are strong in communication but with weak technical skill.
Some candidates think they can code, but they cannot structure the code to make the code usable, and that's a red flag. For the position we want, we are not looking for scripting monkey.
If I am hiring a senior position for the team, I expect to have system design conversation. The last thing I ask is whether the interviewee has done any side projects. I don't penalize people for not having a github/bitbucket account, but would be a huge plus during the evaluation.
Anyway, mileage is different for different position.
Coding as part of the interview process is a reasonable request to ask from the applicant and I'm having hard time to understand your objection to this step.
Not really you don't get to see surgeons operate when applying to a position. There is a lack of trust why this whiteboard stuff happens to be honest I pass about 60% of the white interviews that i did.
They have other checks surgeons can operate. Basically an apprentice system where the expert watches the student and doesn't pass them till competent. You don't get to do it by bs'ing in an interview.
Seriously, there's a large number of applicants who apply for programming jobs, have had programming jobs in the past, can talk about their programming work, but are actually unable to write code.
Fizzbuzz is an absolutely necessary filter, or you will accidentally hire these people.
I think you have to be careful about what you do, versus what is common in the industry. It is pretty common to get asked coding questions in the Bay Area, regardless.
Most of the better interviewers work to understand how the candidate thinks and their aptitude to learn new things. Those can tell you a lot about how successful they will be in a job. And folks have shown that take home projects can show you what they can get done.
I found it interesting to compare the company's interviewer training at Google and at IBM. IBM is focused on finding highly qualified people compatible with their values, Google was more interested in finding people who were not intimidated by "impossible" questions. Both have their strengths.
I've had people nail general CS and SE questions and then completely flop the simplest of coding exercises. I didn't hire these people, and I'm guessing you would have.
Anyway, I disagree with you. Though I'm not saying your process is bad.
Are you in a position to name company names? Most everybody I interview with does this (at a minimum). I'd love to interview at a company that has a smarter system in place.
While it may be possible to tell competance easily this way, one thing I found difficult to tell without live coding is someone's ability for architecting components. One recent hire at work is competant at coding, but for a senior engineer, weak on designing API for a UI service to generate components, as well as weak on unit testing (which in this instance, turns out to be somewhat linked).
If they don't make you write any code, do not work there: you might end up working with people who can't write code---because the application process doesn't filter those bozos out.
(Doesn't have to be `write code on a whiteboard'. Whiteboarding is actually pretty artificial. Just make sure they do make you write code at all.)
Reply to below: Most companies have me do at least one non-technical system design and/or talk-about-a-project interview.