I would have ended the interview right there, as well.
I would have ended the interview right there, as well.
Any company that does whiteboard interviews for coders should also have incoming salespeople sell hotdogs in front of the building as a test. Incoming managers can use Barbie dolls to demonstrate how to run a team. Fair is fair.
The reason that people do fizz-buzz style tests in interviews isn't to insult you with easy questions. It's because far too many "professionals with years of experience" are incapable of solving the simplest problems. These people will cost your company hundreds of thousands of dollars in combined expenses and opportunity cost, if you let them.
It's possible to implement it poorly, sure, but the principle is sound.
For instance, I interviewed people who froze up simply by being on an interview, putting them in front of a whiteboard would have been torture.
Why does everyone seem to feel they're far too important to do their jobs?
How about a chef, a surgeon, a car mechanic, an architect? Are any of these put to the test and asked to practice their craft right on the spot during the interview? If so, my knowledge of the job market is sorely out of whack. If not, why do IT companies consider themselves so important that they have the right to make potential hires run the gauntlet?
Writing code on a white board is not anyone's job. That's the point. It's so different from anyone's job that you're not testing whether they're actually good at coding.
Instead of whiteboard interviews, completing some actual code while sitting in the office at a real laptop would be a much better way to determine if someone actually knows how to code.
Why do you think it's 'humiliating' to be asked to demonstrate your ability?
Doing a whiteboard test is not only a waste of time, it's nothing like actual coding. It's both too simple (in terms of skills) and too hard (in terms of environment).
Let's take fizzbuzz just as an example. As others have said in these comments, they know great coders who failed fizzbuzz. Fizzbuzz tells you exactly zero about how someone would be at writing code that's readable, testable, and maintainable, which are the most important technical skills. Those are hard skills to master, and they can be tested by interviewers by using a real-world problem. Let the candidate sit by herself for a few hours and work on it.
The whiteboard interview also puts someone who is potentially desperate for a job and terrified of being embarrassed in a high-pressure situation, where failure instantly means she's "incompetent" or "stupid". Who can't do fizzbuzz, right? Well I'll tell you: people who aren't super calm in artificial, high-pressure testing situations sometimes can't do fizzbuzz.
Stop thinking so highly of yourself. There is nothing humiliating about them. If you get feeling of humiliation from someone watching you work, then you are going to have a bad time working in a team.
But, for others like an introvert, the whole process is like dancing in a circus in front of the people (with each one of them asking you do something at the sametime).
But maybe my saving grace here is that I don't fear pressure in that kind of situation...
This is 100% in your head and about your attitude. Your ego is the problem, nothing else. I'm introverted as fuck, but I realize that this is part of interview process and if you act like a self centered cunt, who isn't willing to do a simple task like writing little code on a board, you aren't worth the effort for most projects.
Some people just can't deal with the pressure of interviewing.
White board interviews are humiliating? Why? Because your sense of pride says that you're better than that? Is your sense of pride going to decide it's humiliating if I ask you to work on a crappy little side project for a month?
And, you're used to building entire systems? Great. In our interview process, we've got maybe half an hour for this kind of problem. Are you going to build an entire real system for us in half an hour? If so, I definitely want to hire you. But if not (as I suspect), then toy problems are kind of all we've got to see how you interact with a problem.
> The problem here is a mismatch in expectations.
Very much so. You expect the interview to be at the level that you work at, and we don't have time to lay the shared foundation to see how you really operate at that level. If we tried, the interview would be a week, not two hours. We don't have time for that, even if you do.
A less humiliating but still valuable interview (IMHO) is a systems design question. It should still be a whiteboard exercise, but it's a better test of problem solving and engineering skills. I don't seriously begin any system work without first doing the very same thing on a whiteboard myself. It's a useful on the job skill and a useful way to test skills of communication and collaboration in describing the solution.
With respect, if you're putting your employees to work on "crapy little side project's" for a month, either the projects are not crappy and have potentially large impact on the firm, or, you're wasting valuable resources.
As an employee, if the manager is not a skilled communicator, it's not the sort of place I want to work for. As a manager, if the employee is cannot understand business priorities, it's not the sort of employee that I want.
I spend a fair amount of my day job drawing up technical solutions on whiteboards - either helping to analyse a problem, or talking people (often people I've never met before) through my thought process.
For some roles, this kind of skill is absolutely vital. And if that's the role that someone is going for, then you're going to want to know how good they are with it.
It also allows you to see the person's thought process - how do they go about understanding the problem? How do they approach defining the solution? I could be wrong, but I doubt that they'd be looking out for syntax errors on the board - it's far more likely to be communication and structure of thought that they are looking for.
My wife is a teacher. When she goes for jobs, she often has to teach a lesson to a bunch of kids that she's never met before, hasn't got a clue what level they are or what they've already been taught, and with a bunch of observers standing at the back taking notes.
That's not a realistic scenario for the day to day job as a teacher, and doesn't test a fair amount of the other skills that they need. But it allows them to assess whether the candidate can structure a present an engaging lesson.
That doesn't seem entirely unreasonable, and nor does asking someone to talk through a solution on a whiteboard.
Are you talking about this specific case or in general? I've sat in on several interviews where someone's been asked to write something up on a board, and we were definitely not looking for 100% correctness.
>Also when you do whiteboard u look for view of audience and in interview it is not the case
Why not? An interview isn't an exam. It's a chance for both parties to find out if they could, and would want to, work together. I expect them to be two way conversations.
I were being interviewed I'd quite happily say things like "At this point, I'd be looking to put caching in. I've used X for this in the past, but does your company have a prefered solution for it?". When I'm sitting in on interviews it's a positive if someone asks me that kind of question.
>Why would interviewers not ask if the candidate is comfortable with whiteboard or a simple paper based or even a oral?
If you're looking for someone who is good at talking other people through their solution, then you want to see them doing it. I've no idea on what this company was actually looking for, but I wouldn't want a technical lead who couldn't grab a pen and draw up their thinking.
> An interview isn't an exam
That's not everyone's experience. Some interviewers do look for correctness, and an interview can be far more stressful than an exam, especially for people who are desperate for employment or just introverted.
The point is that whatever the whiteboard tests, it's definitely not someone's ability to sit on a computer and write good code all day.
It's more that a lot of companies are looking for much more than someone's ability to simply churn code out these days, and if this place was one of those then it simply sounds like this guy wasn't suitable for that role.
If, on the other hand, the company was actually looking for a coder to be able to write 100% perfect code on a whiteboard, and was planning on marking them down for syntax errors, then he's probably better finding out what sort of company they are during the interview than after accepting a job.
One is entitled to think it's stupid, and get a bad impression of the company, and refuse an offer if one gets made, but you don't go and tell that is "unfair" and just refuse to answer, that is totally and utterly inappropriate.
I would have understood if he/she said to prefer a test on a computer, if there was the possibility of doing that. But not just refusing to answer.
And the WORST traits that a candidate can show don't lie in technical expertise, but in attitude and character. So this was totally deserving of getting booted out of the door without a second of hesitation.
Who wants to hire someone that thinks they know everything, including the proper way to hire?
There's a thing called tact and it goes a long way. If you can't play nicely in the sandbox then go play by yourself.
If you are going to disagree then be professional about it and show you can still be a team player and have an honest, candid conversation.
I remember interviewing somewhere, a Windows shop turned out, and while I had one COM project on my resume, I knew I didn't want to work there the minute I walked in the door. During the first interview I was asked if I wanted to work in Windows, I said no, they were surprised at my candor (b/c the obvious answer to get the job would have been "yes"). We used the rest of the interview to talk about general industry stuff and parted ways happily (needless to say, I never got a job offer there).
I completely disagree with you on this. If a whiteboard test is such a strong turnoff to a candidate that they won't want to work at the company because of it, and they're willing to make the highly unusual move of refusing the test, then telling the interviewer about it and ending the interview early is the polite thing to do. As an interviewer I don't want to waste my time - and my team's time - by interviewing someone who certainly won't work out.
Candidates should feel comfortable saying no to anything at any point in the hiring process - of course with the potential consequence that the hiring process stops right then and there. But they shouldn't be expected to do things that make them uncomfortable or violates their personal beliefs. Should a candidate who doesn't drink alcohol be expected to have a beer if their interviewer proposes it? Should a candidate with strong religious beliefs be expected to violate them in an interview setting? What's the reasoning behind thinking that a candidate should always agree to a whiteboard test no matter how strongly they oppose them?
Look, the author of the post - the guy who refused the whiteboard test - does come across as cranky and difficult. He certainly should not have been surprised that the interview ended. And, for the record, I think feeling _that_ strongly about whiteboard tests is a little extreme. I just think that if something is a deal breaker for you as a candidate the polite thing to do is to let everyone know up front - ideally before an on-site so you can end things earlier rather than later and save everyone time.
I think we all agree that if either party has made a decision before the interview then nobody's time should be wasted.
At a former job, our office was amazing inside as it used to be an old brewery. In fact it won several design & architecture awards. Anyway, we had a candidate simply drive by and then call saying that it looked too low end for him so he cancelled the interview without even walking inside. We thought that was ridiculous of course but were happy we didn't waste our time with him.
But expecting someone to write compilable code on a whiteboard says more about the interviewer and not the interviewee.