So I refused a white board technical test and was asked to leave(thegearpage.net)
thegearpage.net
So I refused a white board technical test and was asked to leave
http://www.thegearpage.net/board/index.php?threads/so-i-refused-a-white-board-technical-test-and-was-asked-to-leave.1717025/
159 comments
Apparently, he was expecting a constructive dialogue which was never planned to take place.
When a professional comes in, he expects to be treated like one. Most people learned to solve basic coding problems when they were at the university like 15 or 20 years ago. Today, 20 years later you should be discussing other things. Otherwise, you're basically starting a dialogue implying the guy slacked off for 20 years inviting him to prove otherwise. It's just no way for two grown-up professionals to approach things.
On a side note, try this: make a appointment with a highly reputable dentist (like weeks or months in advance) then go and try asking him some basic questions implying he might not know his stuff. You'll be shown the door in about two minutes, and possibly you'll get a lifetime ban in that establishment.
Why should software developers accept to be treated differently? And yes, there are lots of incompetent dentists and doctors of all kinds. Why do they have more respect for themselves than software specialists?
When a professional comes in, he expects to be treated like one. Most people learned to solve basic coding problems when they were at the university like 15 or 20 years ago. Today, 20 years later you should be discussing other things. Otherwise, you're basically starting a dialogue implying the guy slacked off for 20 years inviting him to prove otherwise. It's just no way for two grown-up professionals to approach things.
On a side note, try this: make a appointment with a highly reputable dentist (like weeks or months in advance) then go and try asking him some basic questions implying he might not know his stuff. You'll be shown the door in about two minutes, and possibly you'll get a lifetime ban in that establishment.
Why should software developers accept to be treated differently? And yes, there are lots of incompetent dentists and doctors of all kinds. Why do they have more respect for themselves than software specialists?
I don't know about your analogy... I ask my dentist questions all the time -- and I'm sure my questions are "basic" to them. It's mostly due to my own curiosity and ignorance. I learn a lot in the process, and they seem to enjoy demonstrating their knowledge. (I really like my dentist!)
There are different ways of asking questions.
You may be asking about things because you genuinely need to learn/understand something, in which case doctors are often eager to explain their stuff.
Or you may be asking questions trying to figure out if they know their craft, have run into difficult cases or complications to assess their level of expertise. That's a different story.
I once made a mistake of doing the latter, though I did it because I was facing an op and was quite disconcerted perhaps even frightened. At some moment the doctor looked at me with a special look and told me to go consider what I learned today and decide if I was ready for the whole thing. Then I knew I asked too much and all the wrong questions. Given that he was a very experienced specialist, was the chief doctor of that establishment and overall well recommended, the mistake was mine.
But in the end it all worked out rather nicely with no grudge-holding.
You may be asking about things because you genuinely need to learn/understand something, in which case doctors are often eager to explain their stuff.
Or you may be asking questions trying to figure out if they know their craft, have run into difficult cases or complications to assess their level of expertise. That's a different story.
I once made a mistake of doing the latter, though I did it because I was facing an op and was quite disconcerted perhaps even frightened. At some moment the doctor looked at me with a special look and told me to go consider what I learned today and decide if I was ready for the whole thing. Then I knew I asked too much and all the wrong questions. Given that he was a very experienced specialist, was the chief doctor of that establishment and overall well recommended, the mistake was mine.
But in the end it all worked out rather nicely with no grudge-holding.
There is probably quite a difference in asking questions out of genuine curiosity versus asking questions to imply the candidate didn't know what he was talking about.
> make a appointment with a highly reputable dentist (like weeks or months in advance) then go and try asking him some basic questions implying he might not know his stuff
I think that is ridiculous. Last time I had a mild dental surgery I asked my dentist how many such operations she had performed and how many she had botched up. She not only very patiently and willingly answered by questions but also told me that she had a failure rate of 12% which was industry standard.
If dentists, car mechanics and your local gun dealer refuses to answer question there is the good chance they really dont know their own shit.
I think that is ridiculous. Last time I had a mild dental surgery I asked my dentist how many such operations she had performed and how many she had botched up. She not only very patiently and willingly answered by questions but also told me that she had a failure rate of 12% which was industry standard.
If dentists, car mechanics and your local gun dealer refuses to answer question there is the good chance they really dont know their own shit.
12% ? Oh wow... I will never visit a dentist again :(
That is for a specific type of dental surgery. Also the failure does not mean the patient dies. It means allergic reactions, second operation requires, fractured tooth etc. To give you an example in some cases the bone is so weak that they have to use a Cow's bone marrow to fill it. In some people the body rejects this and hence another surgery is required where a person's hip bone marrow is used.
That's for dental surgery, not for filling a cavity.
But yes, if I were considering dental surgery, I'd certainly want to know that number...
But yes, if I were considering dental surgery, I'd certainly want to know that number...
> When a professional comes in, he expects to be treated like one
How do I know if the person I'm talking to is one of your "professionals," without asking these questions? I need to weed out the pretend professionals.
How do I know if the person I'm talking to is one of your "professionals," without asking these questions? I need to weed out the pretend professionals.
I have been in this business for 20 years and hired a lot of good developers over the years and only one bad one. The bad one was a personality defect and not an ability defect.
If you need a whiteboard or tests, to tell they are a professional then you may be doing something wrong. I can talk to a person and within 10 minutes tell you if they are a good developer or not. Perhaps it's a gift, but I suspect not, what I suspect is people focus on the wrong parts of what makes a developer a good developer.
People focus on the mechanics of development. Do they know syntax? Do they know the API?
In my time I have forgotten more syntax and API's than I know, I used to be a top notch Pascal developer and could be again in 2 weeks same with Delphi, but today I would be hard pressed to write a line of it. But people get hung up on this, they think a whiteboard, disconnected from information, somehow simulates reality; meanwhile we all use Google, before that it was the development library at your company, Barns and Noble and a host of other printed material. The reality is memorizing little used portions of a languages API is a waste of time (the platform is going to change). For 80% of applications built you are going to use the same simple patterns in whatever platform is being used.
The key is to focus on what you are realistically going to have them do. If you are hiring a CRUD developer they should have a good handle on Data access, Relational or NoSQL theory and web/mobile technologies. Don't ask them to write an algorithm that factors prime on the whiteboard when no one is ever going to write that and even if they are, they are certainly not going to do it in a disconnected environment.
I look for three things, intuition, an inquisitive nature and motivation. Those are the three things that cannot be taught. It has yet to fail me other than the above mentioned anomaly.
If you need a whiteboard or tests, to tell they are a professional then you may be doing something wrong. I can talk to a person and within 10 minutes tell you if they are a good developer or not. Perhaps it's a gift, but I suspect not, what I suspect is people focus on the wrong parts of what makes a developer a good developer.
People focus on the mechanics of development. Do they know syntax? Do they know the API?
In my time I have forgotten more syntax and API's than I know, I used to be a top notch Pascal developer and could be again in 2 weeks same with Delphi, but today I would be hard pressed to write a line of it. But people get hung up on this, they think a whiteboard, disconnected from information, somehow simulates reality; meanwhile we all use Google, before that it was the development library at your company, Barns and Noble and a host of other printed material. The reality is memorizing little used portions of a languages API is a waste of time (the platform is going to change). For 80% of applications built you are going to use the same simple patterns in whatever platform is being used.
The key is to focus on what you are realistically going to have them do. If you are hiring a CRUD developer they should have a good handle on Data access, Relational or NoSQL theory and web/mobile technologies. Don't ask them to write an algorithm that factors prime on the whiteboard when no one is ever going to write that and even if they are, they are certainly not going to do it in a disconnected environment.
I look for three things, intuition, an inquisitive nature and motivation. Those are the three things that cannot be taught. It has yet to fail me other than the above mentioned anomaly.
I have exactly the same approach to interviews and hiring as you, it's never failed me yet. I don't care if they can code fizzbuzz in 20 languages, I want to know if they are ready to carry on learning when they need to and they can find information they don't currently have.
Nice to hear the voice(s) of reason and common sense.
You address them as professionals, and if they're lost as to what you're talking about, they're not professionals.
People can't talk the talk about specifics of industry experience if they haven't walked the walk, and that will become obvious in normal discourse around the matters of job role itself and their related experiences. You can be inquisitive, but starting off with CS101 quizzes is just condescending and wildly irrelevant to the actual position.
People can't talk the talk about specifics of industry experience if they haven't walked the walk, and that will become obvious in normal discourse around the matters of job role itself and their related experiences. You can be inquisitive, but starting off with CS101 quizzes is just condescending and wildly irrelevant to the actual position.
I don't think so. Hiring is vulnerable to "behavioral" factors: cognitive biases etc. I'm very fearful of being overconfident, trusting hunches etc. I need hard data.
When I'm being interviewed, I respect the interviewer for demanding hard data, instead of just checking who talks the talk.
When I'm being interviewed, I respect the interviewer for demanding hard data, instead of just checking who talks the talk.
Indeed the dialogue should go into this direction. Two (or more) people exchanging their experiences to see if they share the same values and can potentially join forces in this case.
You can accomplish that by doing preliminary research.
People have personal projects, accounts in social networks, personal blogs. Make a short list of candidates than go digging. You can soon get a good idea of their abilities and how far they are progressed on their professional evolution path.
That research will also quickly tell you if someone is a jerk. Read what they say and how they are saying it and you will learn all you need to know about their social skills. It's a more precise test than an artificial environment of a face-to-face interview when everyone tries to play an all-around nice person. But the thing is, you can't be a nice person 9-to-5 and a complete jerk in your off-hours. A jerk is always a jerk. Better observe them in the wild when they feel nobody's watching them and they can behave naturally.
It also works the other way. I sometimes encounter overall rude people online who share in passing what company they are employed at. I always try to remember the name to not mistakenly end up there.
People have personal projects, accounts in social networks, personal blogs. Make a short list of candidates than go digging. You can soon get a good idea of their abilities and how far they are progressed on their professional evolution path.
That research will also quickly tell you if someone is a jerk. Read what they say and how they are saying it and you will learn all you need to know about their social skills. It's a more precise test than an artificial environment of a face-to-face interview when everyone tries to play an all-around nice person. But the thing is, you can't be a nice person 9-to-5 and a complete jerk in your off-hours. A jerk is always a jerk. Better observe them in the wild when they feel nobody's watching them and they can behave naturally.
It also works the other way. I sometimes encounter overall rude people online who share in passing what company they are employed at. I always try to remember the name to not mistakenly end up there.
Try going to an interview as a dentist and refusing to answer the interviewers questions without even finding out what they are and storming out in a huff. See how many dentisting jobs you get offered.
My wife is a dentist and dentists don't really have technical interviews. You already have a degree and a state license (which will require a national certification test and another board test like CITA). Instead, most interviews are about personality fit and then you often have 4-8 hour workday with the office to see if you're a good fit.
You'd be surprised at how many people haven't learned to solve basic coding problems in college. I have no problem doing a whiteboard problem if I were interviewing.
It's entirely possible that the person who has gotten that far in the process literally cannot code Fizzbuzz. It's not an insult to be asked to do these things. It's a reality caused by the fact that some people can BS their way into anything, the hiring process at most companies is deeply flawed, and usually not the fault of the people you are talking to in the interview.
Obviously anyone who is that offended by this has never seen the other side of the equation where you've hired someone who turns out to be completely incompetent despite appearing to be very knowledgeable and smart in the interview, and now you've invested a whole lot of time and effort and money even if you are able to cut the person loose quickly. It happens. A lot. And it's often not because the hiring managers and other interviewers are idiots or otherwise failed to interview the candidate well.
It's entirely possible that the person who has gotten that far in the process literally cannot code Fizzbuzz. It's not an insult to be asked to do these things. It's a reality caused by the fact that some people can BS their way into anything, the hiring process at most companies is deeply flawed, and usually not the fault of the people you are talking to in the interview.
Obviously anyone who is that offended by this has never seen the other side of the equation where you've hired someone who turns out to be completely incompetent despite appearing to be very knowledgeable and smart in the interview, and now you've invested a whole lot of time and effort and money even if you are able to cut the person loose quickly. It happens. A lot. And it's often not because the hiring managers and other interviewers are idiots or otherwise failed to interview the candidate well.
I think the problem I have with fizzbuzz sorts of code 'challenges' is that it shouldn't be about if you got the right answer but more of how you go about finding the right answer; getting requirements, understanding the requirements, and coming up with something close to those requirements even if it's wrong. Instead, I've seen from other people's anecdotes is it's more treated as a standardized test for aptitude and it's just a bad approach to treat them as such. All the binary right/wrong approach proves is that some people aren't quick thinkers or they're bad test takers. In my own brief experience of a few years in programming professionally, the real world is rarely about binary right/wrong and more like iterative less wrong in terms of developing applications. The latter approach requires the ability to self-correct, seek solutions from others when you're lacking knowledge, and knowing when to tell your superiors that something contradicts earlier, mandatory, requirements of an application. So, I don't blame people pushing back against the HR-woo that's creeping into IT. Simply put, if a company thinks programming is like reciting all the capital cities of the United States and Territories then they have no clue what programming is about and maybe they should get out of that business altogether.
I hear you and understand the situation. What I'm saying is that some preliminary digging would improve your chances of encountering a truly skilled guy.
Academic institutions generally don't teach people to code. It's always a personal quest. You can tell a lot about somebody who's graduated but never gone any extra mile. That should be the basic filtering criteria.
I too have seen people studying at CS departments who were useless at coding. I even helped some mates with their assignments so that they wouldn't get thrown out having invested several years already, though our field of study was not purely CS but more the hardware side of things so graduating as a bad programmer wouldn't be a terribly bad thing. Yet I know for certain none of them ever planned to be looking for a job as a programmer. And if you investigated their programming accomplishments you would quickly find out they should be passed on.
I also noticed that people who are smart and even brilliant do graduate with real programming skills but without personal projects of any sort. The thing is, they may join in as an ordinary programmer but do not plan to stay there long, meaning to quickly move into management or a business branch. You probably don't want them either.
Some preliminary research is always the right thing to do. You won't believe how many times I arrived at an interview and watched the HR turn over my resume to the interviewer for the first time ever, so he had to quickly scan it to get an idea what to discuss. With that approach not much can be accomplished on the hiring track.
Academic institutions generally don't teach people to code. It's always a personal quest. You can tell a lot about somebody who's graduated but never gone any extra mile. That should be the basic filtering criteria.
I too have seen people studying at CS departments who were useless at coding. I even helped some mates with their assignments so that they wouldn't get thrown out having invested several years already, though our field of study was not purely CS but more the hardware side of things so graduating as a bad programmer wouldn't be a terribly bad thing. Yet I know for certain none of them ever planned to be looking for a job as a programmer. And if you investigated their programming accomplishments you would quickly find out they should be passed on.
I also noticed that people who are smart and even brilliant do graduate with real programming skills but without personal projects of any sort. The thing is, they may join in as an ordinary programmer but do not plan to stay there long, meaning to quickly move into management or a business branch. You probably don't want them either.
Some preliminary research is always the right thing to do. You won't believe how many times I arrived at an interview and watched the HR turn over my resume to the interviewer for the first time ever, so he had to quickly scan it to get an idea what to discuss. With that approach not much can be accomplished on the hiring track.
To add, this form of mutual preliminary research should really be a standard approach, followed by a remote first contact. If everything goes smoothly, then things can me moved to the next level and a personal meeting can be arranged. Much better than blindly bringing people in, sometimes from hundreds/thousands of kilometers/miles away only to find out within ten minutes this was all a huge mistake. You're wasting your time, their time, money, electricity/fuel on nothing and it's highly inefficient.
This is different than soft skills though. White board tests test one thing really: your ability to write code under stress while being watched by 2-3 people. I fail to see how that translates to being able to communicate with other people. It's more like asking for a magic trick than actual proof of social skills.
Agreed. And many software developers who like to approach work by carefully thinking things through will not be able to accomplish anything in this setup.
Also, many are simply not comfortable with the situation and too stressed to be engaged in any kind of intellectual activity.
That's not to mention that most cannot do thinking and verbally document the process at the same time. It's either or.
Also, many are simply not comfortable with the situation and too stressed to be engaged in any kind of intellectual activity.
That's not to mention that most cannot do thinking and verbally document the process at the same time. It's either or.
You are right. Most cannot. In my experienice, the very good developers can. However, I never judge a person solely on the whiteboard test and I only get to it with the candidates that have shown other indications they are good for our team.
> your ability to write code under stress while being watched by 2-3 people
But also on a fucking whiteboard! You're thinking about your handwriting, trying to form shapes you've probably never written (like curly brackets). You can't copy/paste and move things around when you notice you made a mistake. You have to remember syntax and stdlib APIs, which is not everyone's strong suit (especially in languages with inconsistent naming like Python and PHP).
It's just totally insane to say that whiteboard coding is anything at all like working as a coder.
But also on a fucking whiteboard! You're thinking about your handwriting, trying to form shapes you've probably never written (like curly brackets). You can't copy/paste and move things around when you notice you made a mistake. You have to remember syntax and stdlib APIs, which is not everyone's strong suit (especially in languages with inconsistent naming like Python and PHP).
It's just totally insane to say that whiteboard coding is anything at all like working as a coder.
I agree. It's not a great test. The first and only time I had to do it - we had a huge round table with all sorts of people. It was not natural, and I was not informed ahead of time that it would be occurring.
The main challenge is that you have to write what may be incorrect in order to get to what is correct in most problem solving. When you have people watching and potentially judging you, you try to program in your mind which is difficult. Then it shakes you because time is passing and you haven't written any code. They're drinking beverages and you're sweating, haha.
I will say however, that the company that had me do a whiteboard was very professional in how they handled disarming all these things you mentioned from my mind when they sensed them.
I got offered a job but I had several other offers. But I still had the sense that they were a good company.
I don't think whiteboards are fair, but I also don't think it's fair to write a company off for using them in their interview process.
If you're going to do them, inform the candidate ahead of time and also help put them at ease when you sense the inevitable anxiety. Let them know that you really want to see the approach not the end result and writing bugs is ok.
The main challenge is that you have to write what may be incorrect in order to get to what is correct in most problem solving. When you have people watching and potentially judging you, you try to program in your mind which is difficult. Then it shakes you because time is passing and you haven't written any code. They're drinking beverages and you're sweating, haha.
I will say however, that the company that had me do a whiteboard was very professional in how they handled disarming all these things you mentioned from my mind when they sensed them.
I got offered a job but I had several other offers. But I still had the sense that they were a good company.
I don't think whiteboards are fair, but I also don't think it's fair to write a company off for using them in their interview process.
If you're going to do them, inform the candidate ahead of time and also help put them at ease when you sense the inevitable anxiety. Let them know that you really want to see the approach not the end result and writing bugs is ok.
Yep that is what I got from reply as well but Steve meant it differently and everyone here probably agrees with him!
If you were being hired on as a HR person, and asked in the interview to do Scooby Doo impressions and somersaults, would you be uncooperative?
Sure, it's an extreme, but that's how most of these sorts of stories are taken by the interviewee, especially for a position that was advertised around very specific credentials or experience.
Sure, it's an extreme, but that's how most of these sorts of stories are taken by the interviewee, especially for a position that was advertised around very specific credentials or experience.
I have answered around 10 company interviews and cleared 8 of them. I have personally interviewed around 15 people so far.
My keys lessons are:
1. Whiteboard coding is not actually about coding. It is about talking with interviewer, coming up with examples and demonstrating a clear cut though process and of course then showing that you can convert idea into code.
2. All this requires very good communication. I always made sure I asked many questions to my interviewers, cares about what problems they solved and treated him as "fellow developer who took time to help me out getting a job" rather than someone who is a judge trying to judge me.
3. What really struck me about OP's rant is that he probably did not invest time in researching how he would be interviewed in first place. All the recruiters who contact you are absolutely clear in telling you what to expect. You were supposed to know what to expect.
4. If the interviewer was rude or indeed "threw" the resume on face, I would strongly recommend informing your recruiter about this. Such person should not be allowed to interview anyone else.
5. As an interviewer you are supposed to help the person get a job by convincing yourself that he could be a good fit in the company. This is not very hard. It is an exercise for you too. You just cant say "write DFS on whiteboard". You must drive the person in right direction, giving hints and even if the person lacks intellect/experience you must make him feel comfortable and good. Even though that person does not get the job eventually you must help him become a better interviewee as he leaves that room.
> you're truculent, uncooperative and insist on being the smartest asshole in the room, you will not be finding work with my team today
Can not agree more. Often really smart people tend to be humble and love challenges than insisting "this is not the good way to interview me". An intelligent and curious person will not run away from a mentally taxing activity, he would face it bravely and even enjoy it in the process.
My keys lessons are:
1. Whiteboard coding is not actually about coding. It is about talking with interviewer, coming up with examples and demonstrating a clear cut though process and of course then showing that you can convert idea into code.
2. All this requires very good communication. I always made sure I asked many questions to my interviewers, cares about what problems they solved and treated him as "fellow developer who took time to help me out getting a job" rather than someone who is a judge trying to judge me.
3. What really struck me about OP's rant is that he probably did not invest time in researching how he would be interviewed in first place. All the recruiters who contact you are absolutely clear in telling you what to expect. You were supposed to know what to expect.
4. If the interviewer was rude or indeed "threw" the resume on face, I would strongly recommend informing your recruiter about this. Such person should not be allowed to interview anyone else.
5. As an interviewer you are supposed to help the person get a job by convincing yourself that he could be a good fit in the company. This is not very hard. It is an exercise for you too. You just cant say "write DFS on whiteboard". You must drive the person in right direction, giving hints and even if the person lacks intellect/experience you must make him feel comfortable and good. Even though that person does not get the job eventually you must help him become a better interviewee as he leaves that room.
> you're truculent, uncooperative and insist on being the smartest asshole in the room, you will not be finding work with my team today
Can not agree more. Often really smart people tend to be humble and love challenges than insisting "this is not the good way to interview me". An intelligent and curious person will not run away from a mentally taxing activity, he would face it bravely and even enjoy it in the process.
> An intelligent and curious person will not run away from a mentally taxing activity, he would face it bravely and even enjoy it in the process.
So many fallacies there. You're assuming that intelligent and curious people can't also suffer from social/performance anxiety. What if the person's just very introverted? They could still be an invaluable member of your team, but you'd never know that if you insist on interviewing them in a manner directly contrary to their strengths. What if the person's female, and doesn't want you staring at her butt even more while she writes on the board. Yes, that s* happens.
Even worse is the way you use "bravery" to equate distaste with cowardice. I'm sure there are programmers who have exhibited more bravery in more contexts than you ever will, but might still balk at jumping through hoops for you when they could be engaging in more empirically-proven interview methods instead.
~25 times interviewing, on either side of the desk, is not much of a sample. Look to people who have been there hundreds of times individually, thousands of times collectively. You might find that there are more techniques, more pitfalls, and more kinds of people involved than you had ever thought of before you made your appeal to authority. Whiteboard interviews might have their place in some very limited circumstances, but making them a default part of the process is just lazy and sets up a generally unhelpful competitive/hierarchical dynamic. An intelligent and curious person will not run away from other methods, but will face them bravely and enjoy them in the process.
So many fallacies there. You're assuming that intelligent and curious people can't also suffer from social/performance anxiety. What if the person's just very introverted? They could still be an invaluable member of your team, but you'd never know that if you insist on interviewing them in a manner directly contrary to their strengths. What if the person's female, and doesn't want you staring at her butt even more while she writes on the board. Yes, that s* happens.
Even worse is the way you use "bravery" to equate distaste with cowardice. I'm sure there are programmers who have exhibited more bravery in more contexts than you ever will, but might still balk at jumping through hoops for you when they could be engaging in more empirically-proven interview methods instead.
~25 times interviewing, on either side of the desk, is not much of a sample. Look to people who have been there hundreds of times individually, thousands of times collectively. You might find that there are more techniques, more pitfalls, and more kinds of people involved than you had ever thought of before you made your appeal to authority. Whiteboard interviews might have their place in some very limited circumstances, but making them a default part of the process is just lazy and sets up a generally unhelpful competitive/hierarchical dynamic. An intelligent and curious person will not run away from other methods, but will face them bravely and enjoy them in the process.
Interviewing 15 people is not an indicator that you now know something about hiring.
To really learn about hiring, you'd have to interview those people and find out how well they do, but also how well the rejected applicants do. You can't test your assumptions if you can't compare the people you hire with the people you didn't.
And, for the record, I (and several of my colleagues) have interviewed almost 100 people each over the course of our careers -- more than 10 per year. We still don't have a secret sauce. Some filters work and some don't. Google has been famously working on this problem using extensive data analysis, and they still haven't cracked the secret of always hiring the best coders.
To really learn about hiring, you'd have to interview those people and find out how well they do, but also how well the rejected applicants do. You can't test your assumptions if you can't compare the people you hire with the people you didn't.
And, for the record, I (and several of my colleagues) have interviewed almost 100 people each over the course of our careers -- more than 10 per year. We still don't have a secret sauce. Some filters work and some don't. Google has been famously working on this problem using extensive data analysis, and they still haven't cracked the secret of always hiring the best coders.
I think what they wrote is an indicator that they know something about hiring.
I've been on both sides and the key lessons the parent laid out are good. They're related more to being a professional in interviewing and whiteboards, not key lessons to ensure you hire the best people available which is what you are discussing.
I've been on both sides and the key lessons the parent laid out are good. They're related more to being a professional in interviewing and whiteboards, not key lessons to ensure you hire the best people available which is what you are discussing.
Soft skills are not coding on a whiteboard. Or coding in front of interviewers. You have to be able to discuss what you are planning and how you came up with it; draw some diagrams etc. Having someone write code on a whiteboard and calling that testing soft skills is an instant fail. The smartest asshole as you say probably would do this pthough, not sure good experienced programmers would. I would never insult someone with talent like this.
stevetrewick wasn't saying soft skills are coding on a whiteboard. The soft skills he's referring to are how you deal with a face-to-face situation. If a candidate believed the coding test is a bad one then they should have raised the issue in a mature adult way (eg having soft skills) rather than either doing their own thing or complaining that the interview question is wrong.
Being a good developer requires the ability to write logical, maintainable code of course, but equally it also requires having the ability to talk to other developers, to work with a team, and to explain technical problems to non-technical people. Those are soft skills.
Being a good developer requires the ability to write logical, maintainable code of course, but equally it also requires having the ability to talk to other developers, to work with a team, and to explain technical problems to non-technical people. Those are soft skills.
"The soft skills he's referring to are how you deal with a face-to-face situation."
That's a non-credible excuse. If it's really about how you deal with adversarial situations, there's no reason for coding to be involved at all. There are plenty of other scenarios you could role-play that are more realistic and/or more informative wrt what software engineers actually do. Why don't people do those things instead? Generally, because it was never really about communication skills or reactions to stressful/adversarial situations. That's just the rationalization that people who actually did intend to measure coding skill come up with when they're forced to admit that the tool they've chosen is spectacularly ill suited to that purpose. Nobody wants to admit they've wasted so much of their own and others' time.
That's a non-credible excuse. If it's really about how you deal with adversarial situations, there's no reason for coding to be involved at all. There are plenty of other scenarios you could role-play that are more realistic and/or more informative wrt what software engineers actually do. Why don't people do those things instead? Generally, because it was never really about communication skills or reactions to stressful/adversarial situations. That's just the rationalization that people who actually did intend to measure coding skill come up with when they're forced to admit that the tool they've chosen is spectacularly ill suited to that purpose. Nobody wants to admit they've wasted so much of their own and others' time.
The original post was about coding on a whiteboard and Steve mentioned interviews LIKE that... But he did not mean that; I was referring to interviews like the original poster.
> The original post was about coding on a whiteboard ... But he did not mean that
...and the rest of us are supposed to read his mind? Since we're talking about communication skills here, I submit that good communication skills might include stating one's meaning more clearly.
...and the rest of us are supposed to read his mind? Since we're talking about communication skills here, I submit that good communication skills might include stating one's meaning more clearly.
Who said anything about writing code on a whiteboard? And coding tests on our (past tense) code base while sitting in with our team are absolutely testing soft skills. Are you going to ask questions when you get stuck? How are you interacting?
There's more to talent than writing code. It amazes me, this attitude that testing for social skills and fit is seen as insulting. Believe me, it's for the candidates benefit as much as the potential employer.
There's more to talent than writing code. It amazes me, this attitude that testing for social skills and fit is seen as insulting. Believe me, it's for the candidates benefit as much as the potential employer.
>Who said anything about writing code on a whiteboard?
The original poster and you responded you do similar things. You meant something different I guess.
I agree very much with a coder is not supposed to only code; I guess we agree if you take away the specific 'I had to code on a whiteboard without even a computer present' of the OP.
The original poster and you responded you do similar things. You meant something different I guess.
I agree very much with a coder is not supposed to only code; I guess we agree if you take away the specific 'I had to code on a whiteboard without even a computer present' of the OP.
Which only makes me wonder: What will they refuse to do when they're on the job too? Will they storm out in a tizzy because I politely asked them to explain how an algorithm worked using psuedo code on a whiteboard?
That is different again from coding on a whiteboard. Pseudocode could be handy although, again, I would prefer people to work it out first and then explain what it does after that. It is very different to explain some idea for a project you are in with your colleagues to them vs standing in front of a strange interview panel producing something that they can theoretical type in and compile. They are hardly related imho.
Exactly this. And we didn't use 'toy' problems like FizzBuzz either, it was 'connect to our DB, pull the following data, do some computation, present it in a UI' kind of stuff. We did this right in the office with the rest of the team so candidates were exposed to our everyday work environment. Got some really great devs that way.
We agree but this is different than what reads from your comment. I am not native English but reread it a few times now and it still reads like you approve with the OP in coding on a whiteboard as interview practice and calling that a softskill.
But yes what you suggest here is what we do. And that is actually fun for the coder (if not highly anti social) as well as it is for the team too.
But yes what you suggest here is what we do. And that is actually fun for the coder (if not highly anti social) as well as it is for the team too.
> truculent, uncooperative and insist on being the smartest asshole in the room
There seems to be very little basis for characterizing the OP that way, so now thousands of people reading this on HN get to associate that phrase with your name. What was that about soft skills?
There seems to be very little basis for characterizing the OP that way, so now thousands of people reading this on HN get to associate that phrase with your name. What was that about soft skills?
I like being challenged by coworkers, so I wouldn't dismiss someone that does it.
It is actually a great chance of engaging in a meaningful conversation and hear more about their experience. I like people that can think for themselves and can be diplomatic.
It is actually a great chance of engaging in a meaningful conversation and hear more about their experience. I like people that can think for themselves and can be diplomatic.
It was the right thing to do, but it was done with the bad timing.
This personal preference should have been communicated right after the first contact and before going on the first date, polite and firmly. That way nobody's time would have been wasted.
It's something I would do these days, given the current industry obsession with these weird rituals. A simple pragmatic and a [constructive] dialog about the needs of the company, my skills and whether there is a potential mutual interest - yes, white board coding, puzzle questions, technical interviews and take home tests - no. Whoever is not okay with this arrangement may move along.
All good jobs that I had were offered without technical tests and they came with nice and smart people. Every time there was some technical grilling involved, the people were arrogant and condescending, and I wouldn't have wanted to work with them anyway.
And anyway, this form of hiring protocol mostly seems to be practiced in the US job market, as well as by those countries trying to closely mimic their US counterparts. I've noticed that phenomenon in Eastern Europeans too. The Western European companies have massively different hiring practices.
For one thing the author is right. These broken hiring techniques force people to leave the mundane job market as quickly as possible, switching to looking for work through other channels. Perhaps this situation contributes to the visible lack of talent that some are observing. Apparently, the talent prefers a more personal and a more civilized approach that the generic job market is not offering.
This personal preference should have been communicated right after the first contact and before going on the first date, polite and firmly. That way nobody's time would have been wasted.
It's something I would do these days, given the current industry obsession with these weird rituals. A simple pragmatic and a [constructive] dialog about the needs of the company, my skills and whether there is a potential mutual interest - yes, white board coding, puzzle questions, technical interviews and take home tests - no. Whoever is not okay with this arrangement may move along.
All good jobs that I had were offered without technical tests and they came with nice and smart people. Every time there was some technical grilling involved, the people were arrogant and condescending, and I wouldn't have wanted to work with them anyway.
And anyway, this form of hiring protocol mostly seems to be practiced in the US job market, as well as by those countries trying to closely mimic their US counterparts. I've noticed that phenomenon in Eastern Europeans too. The Western European companies have massively different hiring practices.
For one thing the author is right. These broken hiring techniques force people to leave the mundane job market as quickly as possible, switching to looking for work through other channels. Perhaps this situation contributes to the visible lack of talent that some are observing. Apparently, the talent prefers a more personal and a more civilized approach that the generic job market is not offering.
The West EU market is indeed very different; reading hiring practice in the US on HN it mostly seems like abuse. Probably it is not that bad in reality but I am glad I never had and will never have to do these kind of things. Nor will I put people I hire through this. I guess it is the mentality here; might have said the opposite if I was from the US.
What's it like in the west EU?
Basically, the interview is all about getting to know a person. You discuss your experiences, your interests, your values. You get to know the people interviewing you, they get an image of you. The company tells you about what they do, then asks you to tell something about yourself. Then you move on to discuss the position, their needs and their objectives and eventually you both develop an idea if there is a good match (for the both sides). Through this not only do they learn about your professional level, but they also form an image of your soft skills and your presentation abilities.
Essentially, it's very important for them to find a nice colleague that will naturally integrate in the collective. Someone who can do the work, but also talk, communicate well and overall be a well-rounded person. The technical side of things is an additional criteria, but not the basis for a decision. You often get to hear the idea that "learning on the job" is the way they do things. Nobody has an idea to dismiss you because you don't remember some obscure sorting algorithm from 20 years ago.
At least I have not run in a single case when the interview was being run by people or the Western European origin and I got to be grilled on technical matters. The story was all different when among the Western Europeans there were the Eastern ones present at the table who were mainly asking questions. In that case all that you get asked is the minutiae of the specific technologies they use, and often the interview time is completely wasted as you don't get the chance to learn about the company, so you return home with as little information about them as you had before going to the interview.
After a while you get a clear picture of where everyone fits in the food chain. Western Europeans run a business, see the big picture and care about practical things. Eastern Europeans are grunt workers that are [happily] stuck in their technical silos.
Not meaning to offend anyone originating from Easter European countries and who do not fall under this description, but it's been my consistent experience and my individual observation that I've made while interviewing for positions in Western Europe (mostly in Germany) and also from interacting with my colleagues (of varying origins). There was always a clear separation of concerns to be felt.
Essentially, it's very important for them to find a nice colleague that will naturally integrate in the collective. Someone who can do the work, but also talk, communicate well and overall be a well-rounded person. The technical side of things is an additional criteria, but not the basis for a decision. You often get to hear the idea that "learning on the job" is the way they do things. Nobody has an idea to dismiss you because you don't remember some obscure sorting algorithm from 20 years ago.
At least I have not run in a single case when the interview was being run by people or the Western European origin and I got to be grilled on technical matters. The story was all different when among the Western Europeans there were the Eastern ones present at the table who were mainly asking questions. In that case all that you get asked is the minutiae of the specific technologies they use, and often the interview time is completely wasted as you don't get the chance to learn about the company, so you return home with as little information about them as you had before going to the interview.
After a while you get a clear picture of where everyone fits in the food chain. Western Europeans run a business, see the big picture and care about practical things. Eastern Europeans are grunt workers that are [happily] stuck in their technical silos.
Not meaning to offend anyone originating from Easter European countries and who do not fall under this description, but it's been my consistent experience and my individual observation that I've made while interviewing for positions in Western Europe (mostly in Germany) and also from interacting with my colleagues (of varying origins). There was always a clear separation of concerns to be felt.
Just to clarify. There are many smart and intelligent people among the Eastern Europeans who've moved beyond that level. It's just I've never encountered that type at the interviewing table. Those that I've seen were mostly interested in scratching their ego, proving their smartness to their bosses and putting down the candidate in public. Naturally, they were making a terrible impression of the company and I wouldn't have accepted to work there anyway (unless after a letter from the CEO stating they have all been removed from the company).
But how can they add routes in rails if they can't implement mergesort on a whiteboard? /s
I concur with this; it is the way I have encountered it as well and usually do it myself as well unless I have a specific deadlined project.
I agree that the preference (or demand in this case) should have been communicated upfront. The interviewee should have known well in advance how the interview would be conducted. Waiting until the actual interview just ended up wasting everyone's time for no reason.
Though, honestly, you're stuck between a rock and a hard place here. One of the tenants of interviewing is that candidates have to be evaluated fairly and equally - you can't have one candidate go through one evaluation process and another go through something completely different. As a company, you could easily be sued for this (you could be seen as showing preference to one candidate or the other).
I think the biggest issue is that companies like FB and Google and other tech giants use these interview techniques, so all other companies argue that those techniques "work" for (or at least do not hinder) companies that have literally billions of users and billions of dollars (in other words, you can't argue with the results).
So, until we have solid proof of a better process that scales I think those types of interviews are going to be a consistent part of the tech job industry.
Though, honestly, you're stuck between a rock and a hard place here. One of the tenants of interviewing is that candidates have to be evaluated fairly and equally - you can't have one candidate go through one evaluation process and another go through something completely different. As a company, you could easily be sued for this (you could be seen as showing preference to one candidate or the other).
I think the biggest issue is that companies like FB and Google and other tech giants use these interview techniques, so all other companies argue that those techniques "work" for (or at least do not hinder) companies that have literally billions of users and billions of dollars (in other words, you can't argue with the results).
So, until we have solid proof of a better process that scales I think those types of interviews are going to be a consistent part of the tech job industry.
>> you can't have one candidate go through one evaluation process and another go through something completely different
Yes, you can. Because people are all different and need to be approached differently.
>> I think the biggest issue is that companies like FB and Google and other tech giants use these interview techniques
Didn't Google recently admit that those "interview techniques" are worthless and have no correlation with the candidates' abilities to perform well in the field?
>> So, until we have solid proof of a better process that scales
You don't need to scale. You don't have to interview half of the town. Just find some people you can work with and stop there.
>> I think those types of interviews are going to be a consistent part of the tech job industry
As I mentioned earlier, those types of interviews aren't practiced in the Western Europe and hiring there works just fine without them.
Yes, you can. Because people are all different and need to be approached differently.
>> I think the biggest issue is that companies like FB and Google and other tech giants use these interview techniques
Didn't Google recently admit that those "interview techniques" are worthless and have no correlation with the candidates' abilities to perform well in the field?
>> So, until we have solid proof of a better process that scales
You don't need to scale. You don't have to interview half of the town. Just find some people you can work with and stop there.
>> I think those types of interviews are going to be a consistent part of the tech job industry
As I mentioned earlier, those types of interviews aren't practiced in the Western Europe and hiring there works just fine without them.
Plenty of irrelevant coding tests here in Barcelona. :(
I've been interviewing and interviewed for years. If you want to test someones coding ability, give them a computer, give them a problem and ask them to solve it in their favorite language.
The time during an in-person interview should not, I repeat, should not be wasted on solving a single problem on a whiteboard. Having someone whiteboard a design or system, etc., sure. But having them do code on a whiteboard is idiotic since no-one actually works like that (well not since Lisp was invented).
When I interview people, I ask them about their experience, and how they solved difficult situations they faced. I find out a lot more this way about their abilities to lead projects; if you do it effectively you can quickly determine where people are exaggerating their team leadership skills, or the amount of design they were personally responsible for on a project. Read about behavioral interviews for good material on how to properly interview in this style.
Going through this process also lets you know if you actually want to work with the person. Which, IMO is more important than hiring the greatest programmer in the world, if that person is also a narcissistic, egotistical maniac (and yes, all us programmers fit that description, but you know what I'm getting at).
After all that, you have their test, their github account, references (OMG, you can call people they know or ask on LinkedIn, what?). That should be sufficient in telling you about their coding ability, and far greater than a 45-60 minute white boarding session in which all you found out is if they can properly do quick-sort (where do I pivot again?).
I agree that this guy probably could have handled this particular situation better, but I also think it's a stupid waste of time on the interviewers part to ask questions that don't get at the heart of someones experience.
The time during an in-person interview should not, I repeat, should not be wasted on solving a single problem on a whiteboard. Having someone whiteboard a design or system, etc., sure. But having them do code on a whiteboard is idiotic since no-one actually works like that (well not since Lisp was invented).
When I interview people, I ask them about their experience, and how they solved difficult situations they faced. I find out a lot more this way about their abilities to lead projects; if you do it effectively you can quickly determine where people are exaggerating their team leadership skills, or the amount of design they were personally responsible for on a project. Read about behavioral interviews for good material on how to properly interview in this style.
Going through this process also lets you know if you actually want to work with the person. Which, IMO is more important than hiring the greatest programmer in the world, if that person is also a narcissistic, egotistical maniac (and yes, all us programmers fit that description, but you know what I'm getting at).
After all that, you have their test, their github account, references (OMG, you can call people they know or ask on LinkedIn, what?). That should be sufficient in telling you about their coding ability, and far greater than a 45-60 minute white boarding session in which all you found out is if they can properly do quick-sort (where do I pivot again?).
I agree that this guy probably could have handled this particular situation better, but I also think it's a stupid waste of time on the interviewers part to ask questions that don't get at the heart of someones experience.
>> Going through this process also lets you know if you actually want to work with the person.
This. That's the idea of an interview, to see if there is the right chemistry. It's like going on a date: the description/photos could be awesome but you quickly learn you don't even like having coffee together with that person. That is the point of a face-to-face meeting.
As for the background and the pedigree, plenty of the information can be provided and made ready for study without the need for an interview. The interview time should not be wasted on things you cannot assess in that short a time anyway.
This. That's the idea of an interview, to see if there is the right chemistry. It's like going on a date: the description/photos could be awesome but you quickly learn you don't even like having coffee together with that person. That is the point of a face-to-face meeting.
As for the background and the pedigree, plenty of the information can be provided and made ready for study without the need for an interview. The interview time should not be wasted on things you cannot assess in that short a time anyway.
References? Isn't it pretty taboo to give out bad references? How can you then trust the good references?
In Germany (and possibly in certain other countries) there is a special language people use in written references to issue a positive reference (others aren't permitted) yet include certain information "between the lines". There are books on how to write these things and how to detect them.
Same in the US. Basically you can either give someone a glowing review, or you can say, "yes, <person> worked here for <X amount of time>".
What you can't do is anything that hinders a person from getting a job, but it doesn't mean you need to lie and say they were great.
What you can't do is anything that hinders a person from getting a job, but it doesn't mean you need to lie and say they were great.
Didn't know that. Thanks for the info.
Commercial Software development is for a large part about communication with fellow humans, not just about typing into a terminal. A whiteboard is just another communication tool, quite often used by development teams.
Not for coding though. At least i have never seen that in 25 years and it would be rather inefficient as well. It was already inefficient in the 80s as you could put a television and the other coders could read while you coded but now it would be very weird imho. Diagrams and formulae etc sure but this guy was asked to code.
So? write pseudo code!
Agreed , but development teams already have a understanding of each and every team member's skill set. You pretty much go into whiteboard interviews without knowing the people all that well.
If you're in a small company, possibly. In a large organisation, I fairly regularly find myself having to explain technical stuff to people I've never met before. Some are non-technical, some are very technical. Some are external suppliers, or people working in one of our many overseas divisions.
Admittedly, my job may not be typical of what the average dev has to do. But if that's the kind of role that this company was looking for, then asking someone to talk through something on a whiteboard doesn't seem too unreasonable.
I don't know the company, but I'm guessing that they aren't going to be that bothered that you can't remember the exact syntax of a particular function without checking it on Google. What I assume they're looking for is someone who can clearly communicate their thought process.
Admittedly, my job may not be typical of what the average dev has to do. But if that's the kind of role that this company was looking for, then asking someone to talk through something on a whiteboard doesn't seem too unreasonable.
I don't know the company, but I'm guessing that they aren't going to be that bothered that you can't remember the exact syntax of a particular function without checking it on Google. What I assume they're looking for is someone who can clearly communicate their thought process.
Sorry, meant to clarify that with only small focused teams that could be working a specific feature etc. Yes if the job was for a more responsible role like the one you describe, I would hope they would give the applicant a while board and more to show his/her skills.
I can disagree that for a just a technical interview that a while board isn't the best tool to bring out people's collaboration skills.
I don't know what the whiteboard should be replaced with, though.
I can disagree that for a just a technical interview that a while board isn't the best tool to bring out people's collaboration skills.
I don't know what the whiteboard should be replaced with, though.
And during the process, you find out about each other.
You can do that in a real life situation too; why a white board without a computer? Sit all in front of a computer on a beamer or whatever and jump into something in a language the interviewee says she is good at. The whiteboard can be used for the high level decisions and the total process for the soft skills.
I do a lot of interviews and that's what we do for the more technical interview:
* give a written problem description with some reading time
* ask some questions about the problem and the tasks,
so we all have the same idea what is needed
* treat the candidate as a team member in the lead role,
support him/her
* let him/her explore the problem and a possible solution
design using the whiteboard
* support him/her
* use a computer/ide to sketch an implementation while
he/she has Internet access and can ask any question.
There is not a single solution we are looking for.
Let the candidate explore his/her approach.
* interview team sees a mirror of the screen, and the
candidate explains what he/she is thinking/doing
* try to get something useful running with some
tests written. A complete solution is not needed.
Working, tested, well written code > full solution.
* do a quick feedback/review round
* if the candidate is junior, didn't get that far,
but shows some promise, he/she gets the problem
as homework and can send in a complete and
tested solution within a week
That seems good to me. I would enjoy doing that kind of interview.
I do not understand how a "working" and "tested" code is not a "full solution."
It's not a solution of the whole problem given, that's what we would call a full solution. An extremely good coder might approach 99% of the problem, but the average coder will only get to solve one or two subproblems, which would be around 30% to 50% of the full solution. But that's fine for us. Selecting an interesting part of the problem is one of the tasks. ;-)
Not really - certainly not for everyone. A lot of deep technical work is done independently. You go heads down and you code.
The whole interviewer-interviewee dynamic is so messed up in technical hiring these days.
Recently I've been thinking about asking the candidate to ask me to whiteboard something. I actually think that might produce a more interesting conversation and a more meaningful assessment of fit from both sides.
Recently I've been thinking about asking the candidate to ask me to whiteboard something. I actually think that might produce a more interesting conversation and a more meaningful assessment of fit from both sides.
Throw in a couple of gotchas and no-nos and see how the subject responds!
They have a quantity of engineers they're trying to evaluate quickly. If you refuse why would they bother wasting their time? Chances are that you're not the stand-out candidate of the group so why not just pass over you and find one that fits within the checklist of tasks your boss told you to do to evaluate a new hire?
There's a time and place to take your stand. You need to work that out or you'll shoot yourself in the foot.
There's a time and place to take your stand. You need to work that out or you'll shoot yourself in the foot.
White board tests are pretty useless, but the applicant's behaviour was unprofessional, to say the least.
I would have ended the interview right there, as well.
I would have ended the interview right there, as well.
It's unprofessional to make an adult with potentially years of experience do a nonsensical, high-pressure test in front of an interviewer like a monkey. Whiteboard interviews are humiliating even if you pass.
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.
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.
This is like getting your knickers in a twist over being asked to make a coffee when interviewing to be a barista. "But I have years of experience, why should I just make you a coffee right now in front of you like a trained monkey?"
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.
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.
My issue is not testing someone's coding skills if they'll be coding for you. My issue is that whiteboard interviews are so different from real-life coding that they have no value at all.
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.
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.
A barista would be making coffees as part of their job. Not sure how many programmers code on whiteboards in stressful situations on a daily basis.
Maybe not often white boards specifically (although I've done that too) but does no-one else do pair programming? Code reviews? Emergency group debug sessions to fix a blocking bug? There are many situations which absolutely do require you to be able to perform on the spot and under pressure.
I have done all of those, but by that time I was aquatinted with the people I work with. During an interview you're stressed by strangers and the interview itself.
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.
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.
I don't think a barista is asked to make a coffee under supervision during his very first interview either? That would be demeaning in the extreme, in my opinion.
Seriously? What else would you do to interview a barista? You observe their presentation, chat with them a bit to confirm they have some base level of interpersonal skills, and you get them to make you a coffee or two.
Why does everyone seem to feel they're far too important to do their jobs?
Why does everyone seem to feel they're far too important to do their jobs?
My impression is that people come in for a chat about themselves and their past experiences. The guy running the shop can easily tell if they know what they are talking about. If he likes them they are brought on to the team and then evaluated over something like a two week period.
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?
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?
> too important to do their jobs
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.
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.
What's unprofessional about it?
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.
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.
It is not about whether this skill is required it is definitely a skill required. Interviewers are expecting the actual exact answer with syntax correctness instead of looking at thought process. Also when you do whiteboard u look for view of audience and in interview it is not the case. Why would interviewers not ask if the candidate is comfortable with whiteboard or a simple paper based or even a oral?
>Interviewers are expecting the actual exact answer with syntax correctness instead of looking at thought process.
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.
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.
> we were definitely not looking for 100% correctness
> 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.
> 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.
I agree with that.
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.
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.
I've always rather enjoyed doing them and at the start I almost certainly have no idea what the answers are; I just assume it's more about thinking clearly and asking good questions so I guess that works better for me than thinking I'm a performing monkey which would probably hinder my performance and enjoyment.
White board interviews are humiliating, especially if the level is pitched wrong. As someone with a career prior to starting grad school I'm sick of being treated like a child in the interview process and being given diddly little graph traversal problems when I used to building entire systems. The problem here is a mismatch in expectations. But the whiteboard interview does have its merits. I have sat on the other side of that table. We took a candidate with years of experience a masters degree from a prestigious university and a very very impressive thesis. We were almost embarrassed to give him the warm up questions. Until he completely utterly failed to complete them. We didn't even get past the warm up questions during the two hour interview. As a baseline measure of competence, it was a pretty good one and we (in a small startup) really dodged a bullet by doing this kind of testing.
> White board interviews are humiliating, especially if the level is pitched wrong. As someone with a career prior to starting grad school I'm sick of being treated like a child in the interview process and being given diddly little graph traversal problems when I used to building entire systems.
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.
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.
Being asked to write yet another depth first search implementation (honestly, 5/5 interviews at a large corporation were the same question) that any second year student can do is humiliating when your daily bread is building complex distributed systems. I still did it, because (unlike the writer) I understand that you do need to establish a baseline. As I've said, I've sat on the other side of the table, asked the humiliating question and seen the candidate fail miserably. It's a necessary evil, but it's still humiliating.
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.
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.
The "side projects" are large impact for the firm (either defensive or offensive, that is, either "save the day" or opening new opportunities), but they can still be well beneath the talent/skill level of the programmer assigned to it. If the programmer is going to feel humiliated by that, then we probably don't have time for that programmer.
IMHO, a good manager would communicate the importance of the project along with the spec of the project. "Because I said so, so do it" is not a good strategy for highly skilled, highly competent, highly intelligent people. The "why" is every bit as important as the "what". Presumably you wouldn't "waste" a good programmer on a simple task if it wasn't important. Similarly a good programmer would understand that business priorities means that some projects are complex and interesting, some are important and boring.
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.
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.
Maybe, maybe not. Perhaps you missed genius coders who suck at white board fizzbuzz.
I won't give away the details, but the warm-up question should have taken a about 14 seconds for someone with the claimed skill set. They should have been able to speak the code at us rather than use a whiteboard. Think of something like "write a program to sum the values in a 10 element integer array". It was supposed to be a fluff filter so we could get on to higher level architecture/design questions. I felt embarrassed to even give it. On resume alone, this guy was a definite hire. The interview was something else entirely.
I know great coders that have failed fizzbuzz. I've seen it happen in an interview where I was an interviewer, they were my friend, and I did everything in my power to make the process low pressure.
Some people just can't deal with the pressure of interviewing.
Some people just can't deal with the pressure of interviewing.
It looks like walking out was a win-win solution in this instance.
>Whiteboard interviews are humiliating even if you pass.
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.
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.
The original comment exactly describes the problem with the whiteboard situations. Maybe you are an extrovert and can just say something on and on when the interviewer prods you with nitpicking details that does not matter in a whiteboard.
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, 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).
Look, I'm an introvert. I despise being treated as a performing seal. I also have no problem with a whiteboard interview. Yes, I'm being made to jump through hoops, but I understand why. It's not just to make me jump through hoops. (If I pick up the vibe that it is just for that, then I don't want the job.) It's so that they can see how I think.
But maybe my saving grace here is that I don't fear pressure in that kind of situation...
But maybe my saving grace here is that I don't fear pressure in that kind of situation...
>I despise being treated as a performing seal.
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.
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.
It would be unprofessional to judge a candidate purely on the basis of their resumè. I wouldn't expect an adult with years of experience to find such a test even remotely problematic. And in case anyone missed it, part of the test is evaluating your attitude and your behaviour when a little pressure is applied.
Why do you think it's 'humiliating' to be asked to demonstrate your ability?
Why do you think it's 'humiliating' to be asked to demonstrate your ability?
Being tested is totally fine. I have no issue with testing someone's skills.
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.
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.
Do you know how I know you're in your 20s?
I dunno, it really depends on the details of how (s)he said it. One could refuse a white boarding session in a very professional way - tell the company that you don't do white boarding when they first schedule the on-sight so you don't waste anyone's time. If they still want to do it then politely refuse. Be the first to offer to leave so you spare the interviewer from having to kick you out. But, yeah, most people probably wouldn't be that professional about it.
No. One cannot refuse a whiteboard test.
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.
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.
Agreed. And the author later said they feel like they aced the Skype questions but wouldn't get the job because of young punks.
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.
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.
Sure you can refuse. By doing so you are basically saying that you don't want job, their loss, is your gain in happiness. And it feels so good to do it.
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 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).
> No. One cannot refuse a whiteboard test.
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 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 the parent was phrasing it as you can't refuse a whiteboard test if you want to work there.
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.
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.
Depends on the problem - it is ok for birds view oversight. If I want you to design a backend for an app - drawing the blocks, connections and the major interactions is ok.
But expecting someone to write compilable code on a whiteboard says more about the interviewer and not the interviewee.
But expecting someone to write compilable code on a whiteboard says more about the interviewer and not the interviewee.
Modern interviewing is about whether a candidate brings the right skills and whether s/he'd fit in. It's not about finding the best robot, it's about finding a colleague your both be able to work and have fun with. The author may or may not have had the technical skills but being a rebel in the interview process does never bode well for your ability to fit into the work environment.
You can actually, you know, talk to the candidate and find out if they fit. Wanting them to perform in front of a whiteboard is completely different.
A second tale from the same forum submitter:
> Had another interview on Skype with another company. Was grilled verbally without actual coding test.
> No way those verbal answers can be delivered unless you have experience, so I basically aced the verbal technical test on Skype. But I don't think I'll get the job anyway because the interviewers all seem like young punks who may not think I would fit their hip/young group.
There is a reason Rosa Parks and not Claudette Colvin [1] was used as the front figure of the bus segregation lawsuit.
Although there is an argument about the merits of whiteboard testing his (apparent) behavior and overall attitude could have contributed as much as his refusal to take the test.
[1] https://en.wikipedia.org/wiki/Claudette_Colvin
> Had another interview on Skype with another company. Was grilled verbally without actual coding test.
> No way those verbal answers can be delivered unless you have experience, so I basically aced the verbal technical test on Skype. But I don't think I'll get the job anyway because the interviewers all seem like young punks who may not think I would fit their hip/young group.
There is a reason Rosa Parks and not Claudette Colvin [1] was used as the front figure of the bus segregation lawsuit.
Although there is an argument about the merits of whiteboard testing his (apparent) behavior and overall attitude could have contributed as much as his refusal to take the test.
[1] https://en.wikipedia.org/wiki/Claudette_Colvin
tsk tsk tsk, somebody didn't read the whole thread. I highlighted the juicy bits.
I was told the hiring manager was very keen to make me an offer but I have to travel about 4 to 5 hours to their office for onsite final interview.
Yes, it's the team of young punks who interviewed me.
This was a recruiter involved exercise where I was contacted. Did not apply for this position.
Just an update. There's another Skype interview I had that was successful and I was asked to attend a final interview. I was told the hiring manager was very keen to make me an offer but I have to travel about 4 to 5 hours to their office for onsite final interview. I suppose this could involve white board testing or whatever. They want the interview/meeting this week/thursday, a bit of a rush. I am not so keen on travelling this week, and I expected them not to offer me anything at all in the first place. Yes, it's the team of young punks who interviewed me. I am way too jaded to make a 4 to 5 hours trip just to attend a final whiteboard test. But even then I have to make a move if I do accept this offer. This was a recruiter involved exercise where I was contacted. Did not apply for this position. I asked to confirm the interview agenda, and all the recruiter said was to discuss the offer. The last thing I want is to be bamboozled and surprised by a whiteboard test and wasted my trip there. Even then I am already not too keen on this job due to the need to make a big move.>> Although there is an argument about the merits of whiteboard testing his (apparent) behavior and overall attitude could have contributed as much as his refusal to take the test.
When I interview a candidate I don't ask him bending a knee in front of me. If he felt like that then something went wrong.
When I interview a candidate I don't ask him bending a knee in front of me. If he felt like that then something went wrong.
I applaud you! Whiteboarding (sounds like waterboarding) is an archaic practice and should be discontinued. A new hiring and vetting method needs to be invented. I also don't agree with these "coding puzzle" websites where you do silly questions to show your skills and "score respect". All technical interviews today are very confrontational by nature. Both parties start off on the wrong foot. There needs to be some sort of hybrid. I like to make the analogy to driver's licenses. There should be something like developer licenses that the industry defines and agrees upon. If you have a developer license for Android, for example, then companies should know that they can hire you for an Android project. Its silly for someone like me to go to every single company that wants to talk and jump through the same hoops every time to demonstrate competency. The conversation that we have in 30-40 minutes is given more weight than my entire track record over several years, which is just absurd. Each company also has to divert their energy from their core work to develop their own hiring practices. The same problem is being solved over and over by each company which is just a total waste of time. It is not fun for either side.
Site got hugged to death. Google cache: http://webcache.googleusercontent.com/search?q=cache:c1QjJhx...
I think I wouldn't mind doing some whiteboard pseudo-coding, to brainstorm on an algorithm for instance. To design an algorithm or sketch an architecture, I don't need Internet access.
Of course I wouldn't accept any critic on syntactic mistakes or even coding style, but I could explain out loud how I construct the initial steps of a program.
I would also let explicit comments like "//google a solution for that" or "//find a library that does this"
Of course I wouldn't accept any critic on syntactic mistakes or even coding style, but I could explain out loud how I construct the initial steps of a program.
I would also let explicit comments like "//google a solution for that" or "//find a library that does this"
Bang on. This is totally great just if the companies doing the white boarding interviews accept this kind of interactions. Most of them don't, and that is what white board interview enthusiasts are missing to consider.
I see a lot of different opinions in this comments and I believe that there is truth in both sides of the situation. Whiteboard is pretty much useless to determinate the technical skills of the person but it can be useful as to understanding how a person uses their communication/critical thinking skills . I do not think that the problem is the whiteboard per se but rather the use that the employers makes of situation. If the interviewer is aware of what using a whiteboard is good/bad for than the outcome can be good even if the whiteboard problem is not fully solved. The issue with the ordeal arises when people take the whiteboard approach at face value. "This is a problem, solve it." and take the end result as a direct example of the applicant's skills. I think that a good interviewer should be able to communicate what is expected out of a whiteboard test and make the candidate at ease. Obviously interviews with this approach are seemingly rather rare because people that conduct the interview often don't have the skills or the experience to conduct thought out interviews and take problems without maybe thinking of how they should evaluate the result of a test.
> I was also asked to do some weird personality test that is over 3 pages and I have no clue the format/questions being asked. I declined those as well.
Uncooperative and argumentative. I'd _really_ want someone like this on my team...
Uncooperative and argumentative. I'd _really_ want someone like this on my team...
Gets to the root of a problem quickly and points out the flaws.
I refused a whiteboard hazing a few months ago. It was more of a logistics matter where they scheduled me really late (around 7PM) and told me it was just an "introduction" interview.
It was not a good match and I don't regret it at all.
Edit: This was for an internship and they either were not honest in their phone call or there was some "implicit" things that I didn't get.
It was not a good match and I don't regret it at all.
Edit: This was for an internship and they either were not honest in their phone call or there was some "implicit" things that I didn't get.
This seems like 1) a communication problem and 2) an attitude problem, from the OP, more than anything else.
It seems like the OP is insistent on his own way of being evaluated, but hasn't informed these interviewers or recruiters ahead of time, or even try to discuss it (hence a communication problem):
> I just packed up and left. Didn't even bother to further explain why I refuse the whiteboard interview or tell them why their process is flawed.
Additionally, the OP seems to have an egotistic and judgmental temperament (hence an attitude problem):
> No way those verbal answers can be delivered unless you have experience, so I basically aced the verbal technical test on Skype.
> ... the interviewers all seem like young punks who may not think I would fit their hip/young group.
Given the above, I think it's unfair to use this particular anecdote fuel against the tech recruitment system (although I agree it is flawed), because those companies might have complied with OP's desires had he communicated them or handled the situation with a better attitude.
It seems like the OP is insistent on his own way of being evaluated, but hasn't informed these interviewers or recruiters ahead of time, or even try to discuss it (hence a communication problem):
> I just packed up and left. Didn't even bother to further explain why I refuse the whiteboard interview or tell them why their process is flawed.
Additionally, the OP seems to have an egotistic and judgmental temperament (hence an attitude problem):
> No way those verbal answers can be delivered unless you have experience, so I basically aced the verbal technical test on Skype.
> ... the interviewers all seem like young punks who may not think I would fit their hip/young group.
Given the above, I think it's unfair to use this particular anecdote fuel against the tech recruitment system (although I agree it is flawed), because those companies might have complied with OP's desires had he communicated them or handled the situation with a better attitude.
Okay, so a whiteboard interview is definitely flawed, and we all know it.
However, I would like to point out 2 things:
1. You should have known it was going to be a whiteboard WELL in advance of the actual interview. You could have asked the recruiter how you'd be evaluated. In the actual interview is NOT the place to refuse a whiteboard. You should have talked to the recruiter and told him/her that you wouldn't do a whiteboard evaluation. Instead you chose to waste everyone's time. So, you're kind of a dick for that.
2. "because the interviewers all seem like young punks" - yeah maybe the issue is your attitude. Just sayin. Again, you sound like you're kind of a dick.
However, I would like to point out 2 things:
1. You should have known it was going to be a whiteboard WELL in advance of the actual interview. You could have asked the recruiter how you'd be evaluated. In the actual interview is NOT the place to refuse a whiteboard. You should have talked to the recruiter and told him/her that you wouldn't do a whiteboard evaluation. Instead you chose to waste everyone's time. So, you're kind of a dick for that.
2. "because the interviewers all seem like young punks" - yeah maybe the issue is your attitude. Just sayin. Again, you sound like you're kind of a dick.
Pro-tip: If a candidate throws a tantrum during an interview when asked to whiteboard a problem, don't hire them.
Double pro-tip, if asked stupid questions, or better yet, they yell at you and trow anything at you, do not walk, run away.
I really really don't understand why people get so offended regarding whiteboard coding interviews. I understand not liking them, and even disagreeing with them, but walking out of a job interview because they ask you to solve a little puzzle doesn't make sense to me.
When you apply for a retail job, they'll ask you a question such as "how would you handle X situation," and you're expected to come up with a plan on the spot. In reality, you'll probably have a manager who will tell you what to do, or you'll at least have a team to discuss it with, but asking questions like this tells you something about a candidate.
The same thing with writing whiteboard code- it tells you something about the candidate. At the bottom line, it tells you whether the candidate can reason and think about code. It also demonstrates how the candidate can communicate their thoughts and questions with others on their team. Honestly I'd rather these skills be tested while I'm writing code, rather them asking some questions like "tell us about a bug you encountered and how you fixed it." I guess it also shows if the candidate has an ego too big to be willing to be interviewed for an hour.
When you apply for a retail job, they'll ask you a question such as "how would you handle X situation," and you're expected to come up with a plan on the spot. In reality, you'll probably have a manager who will tell you what to do, or you'll at least have a team to discuss it with, but asking questions like this tells you something about a candidate.
The same thing with writing whiteboard code- it tells you something about the candidate. At the bottom line, it tells you whether the candidate can reason and think about code. It also demonstrates how the candidate can communicate their thoughts and questions with others on their team. Honestly I'd rather these skills be tested while I'm writing code, rather them asking some questions like "tell us about a bug you encountered and how you fixed it." I guess it also shows if the candidate has an ego too big to be willing to be interviewed for an hour.
I don't get the whiteboard hate. The whiteboard is no different from typing, except it's slower. The trend towards live coding is just kind of gimmicky. You have spend your time talking about the approach and the algorithm before you start writing anyway. If you're judging a whiteboard interview on syntax[0] then you're doing them wrong. It's all about the back and forth. The code is almost an afterthought.
Every live coding interview inevitably comes to a crashing halt when the interviewer wants you to actually run the code, because then it's 10 minutes of chasing syntax errors. (Oh missed a semicolon. Didn't close a string. Oh it's not add()? Must be put(). Oh that wasn't imported. Oh that was misspelled. blah. blah. blah.) Followed by another 10 minutes of sticking in print statements to debug the damn thing because you can't write a unit test, or have a debugger.
It's an equally bullshit setup. No one writes production code on a whiteboard, and no one writes production code with some dude staring over your shoulder commenting every other line about a comma or an indent style or some other trivial thing. Even pair programming isn't supposed to be that, and that's assuming you believe pair programming is useful, which is debatable.[1]
[0] I one time had an interview where the guy actually said, "Isn't it .size() and not .length()?" My response was, "Whatever." [1] I actually don't have an opinion assuming "the navigator" is actually thinking strategically instead of saying bullshit like, "'instead' is spelled with an e-a not an a-e." Well, no shit. That's why it got flagged in the editor.
Every live coding interview inevitably comes to a crashing halt when the interviewer wants you to actually run the code, because then it's 10 minutes of chasing syntax errors. (Oh missed a semicolon. Didn't close a string. Oh it's not add()? Must be put(). Oh that wasn't imported. Oh that was misspelled. blah. blah. blah.) Followed by another 10 minutes of sticking in print statements to debug the damn thing because you can't write a unit test, or have a debugger.
It's an equally bullshit setup. No one writes production code on a whiteboard, and no one writes production code with some dude staring over your shoulder commenting every other line about a comma or an indent style or some other trivial thing. Even pair programming isn't supposed to be that, and that's assuming you believe pair programming is useful, which is debatable.[1]
[0] I one time had an interview where the guy actually said, "Isn't it .size() and not .length()?" My response was, "Whatever." [1] I actually don't have an opinion assuming "the navigator" is actually thinking strategically instead of saying bullshit like, "'instead' is spelled with an e-a not an a-e." Well, no shit. That's why it got flagged in the editor.
There are 3 main problems with the whiteboard tech interview.
1. It's not actually correlated to job performance. Google (and others) have done tons of studies on this, and the summary was basically, "Yeah, it's complete bs."
2. It is meant to show how a candidate would solve a problem, but it forces the candidate to follow a particular problem-solving path. Who in their right mind, when being first introduced to a new problem, cuts off all access to Google and other resources and tries to derive a solution from first principles?! Recent grads maybe, but not anyone who's been doing this for some time. It's not a good measure of how a candidate solves a problem if that's not the candidate's typical way of solving a problem. It's like to trying to see how good someone can ride a bike by handing them a unicycle.
3. We're the only industry that doesn't recognize success. At what point should the technical interviews cease? 5 years in? 10? Senior Engineer? Director? CTO? Can we really not tell if someone knows their stuff by just asking them about what's on their resume or by giving them a take-home project to submit?
The fundamental problem is trying to evaluate coding skill in an interview environment. The ability to regurgitate from Cracking the Coding Interview says nothing about whether a candidate can write well-documented, well-tested, maintainable code. It fails even more at determining whether a candidate knows when to write their own stuff vs when to use a library. It fails to determine how well a candidate can learn. All of those things are far more important skills to have.
The fundamental problem is trying to evaluate coding skill in an interview environment. The ability to regurgitate from Cracking the Coding Interview says nothing about whether a candidate can write well-documented, well-tested, maintainable code. It fails even more at determining whether a candidate knows when to write their own stuff vs when to use a library. It fails to determine how well a candidate can learn. All of those things are far more important skills to have.
when i've interviewed people I generally get them to answer a question on the whiteboard.
and... i couldn't care less what they write. What I do care about is how they go about the task. how do they approach the problem? do they plan or do they try first and fix it up? Giving the person a whiteboard marker and them being able to turn away from you helps overcome stage-fright.
exact memorization of an algorithm for an interview is worthless in my eyes.
and... i couldn't care less what they write. What I do care about is how they go about the task. how do they approach the problem? do they plan or do they try first and fix it up? Giving the person a whiteboard marker and them being able to turn away from you helps overcome stage-fright.
exact memorization of an algorithm for an interview is worthless in my eyes.
To me the problem with recruitment process in this industry is that you're experience and background are totally irrelevant and you are evaluated exactly as a just out of college fellow: all that matters is how you perform on that whiteboard test on that particular question in that particular day. That is the unfair part of it. Moreover the junior may even have advantage over you: he costs less.
The junior has an advantage that he has probably needed to write a sorting algorithm in the last couple of years for classes. In 14 years of coding the only times I have need to write sorting algorithms were for coding tests and university exercises.
The issue with software engineers is you can get resumes of people with years of experience and they don't know how to write a loop somehow.
[deleted]
My ideal hiring process for developers would be this:
First an on-site talk at the company site, with a general discussion with the candidate about his personality, background and technical experience, as well as a presentation of the company and the people he would be working with. A polite and pleasant talk, to feel each other out while still getting the relevant information.
After the interview is complete, the candidate would be given a couple of sheets of paper with two written tests: (1) A general IQ test. A lot of people seems to find these controversial (ignoring for the moment any legal issues which I believe are overblown), but I find them pretty good at gauging an individual's logic skills. (2) A small number of programming questions targeted to the language/platform/niche that the candidate would be working with. Not too hard or complicated, but merely a filter to quickly assess the candidate's experience. Questions about some common development paradigms, best practices, knowledge of frameworks, stuff like that.
The candidate would get 10-15 minutes for each of the two tests, and can do them any way s/he likes, in any order and with no requirements to complete all the questions (the questions s/he chooses, and choice between speed/thoroughness is itself an indicator about the candidate). S/he would complete the tests in a room alone without pressure or distractions.
After this, the interview process is complete. The candidate goes home and can be assessed from both his presence and statements, and the results from the tests. No confrontation necessary. The candidate gets a chance to look his best during a relaxed and affable conversation. The recruiter is able to easily get a picture of the person's hard qualifications. Any embarrassing slip-ups on the tests are evaluated offline after the candidate has left. Code is, after all, usually not written on a whiteboard in front of a group of people you have never met.
First an on-site talk at the company site, with a general discussion with the candidate about his personality, background and technical experience, as well as a presentation of the company and the people he would be working with. A polite and pleasant talk, to feel each other out while still getting the relevant information.
After the interview is complete, the candidate would be given a couple of sheets of paper with two written tests: (1) A general IQ test. A lot of people seems to find these controversial (ignoring for the moment any legal issues which I believe are overblown), but I find them pretty good at gauging an individual's logic skills. (2) A small number of programming questions targeted to the language/platform/niche that the candidate would be working with. Not too hard or complicated, but merely a filter to quickly assess the candidate's experience. Questions about some common development paradigms, best practices, knowledge of frameworks, stuff like that.
The candidate would get 10-15 minutes for each of the two tests, and can do them any way s/he likes, in any order and with no requirements to complete all the questions (the questions s/he chooses, and choice between speed/thoroughness is itself an indicator about the candidate). S/he would complete the tests in a room alone without pressure or distractions.
After this, the interview process is complete. The candidate goes home and can be assessed from both his presence and statements, and the results from the tests. No confrontation necessary. The candidate gets a chance to look his best during a relaxed and affable conversation. The recruiter is able to easily get a picture of the person's hard qualifications. Any embarrassing slip-ups on the tests are evaluated offline after the candidate has left. Code is, after all, usually not written on a whiteboard in front of a group of people you have never met.
I think this author is letting their ego get in the way. The interviewer doesn't have time to review their past work and make judgements on that. Devils advocate, even: How do they know you actually wrote that code? Granted I'm not on the programing side of things, but a white board presentation is a great way to quickly gauge how a person solves a problem, and if they know what they're talking about. My first programing job (in 2009) I was asked to hand write out a bubble sort. Ok, which flavor? Java? Sure thing. I got a few things wrong but the interviewer clearly saw I knew what I was talking about, I wasn't afraid to tackle a problem head on without a computer, and could think it through.
This author should really reconsider their attitude towards getting a job, and be willing to stand up and put the effort towards getting that job.
This author should really reconsider their attitude towards getting a job, and be willing to stand up and put the effort towards getting that job.
And how often have you had to write bubble sorts on the job? Or tackle coding problems without a computer?
Apply the 20/80 rule to software development. It's 20% technical, 80% people. My greatest challenge as an IT leader is not in writing code or solving technical problems, but in getting a team that plays together well. Although, I wouldn't be coding much as an IT leader, I would be happy to white board it to show that I still got it!
It's really difficult to access those who can code, I have seen plenty of people who can answer all sorts of technical questions/text book questions and yet they can't code their way out of a paper bag. Just as bad, the ones that can code but are not motivated nor desire to work well with others.
Stay humble!
It's really difficult to access those who can code, I have seen plenty of people who can answer all sorts of technical questions/text book questions and yet they can't code their way out of a paper bag. Just as bad, the ones that can code but are not motivated nor desire to work well with others.
Stay humble!
Quote from OA (actually a forum post)
"All I was interested at that time was to get the hell out of there, not a place I want to work in or the kind of person I want to work with/under."
...and, about a Skype based verbal interview with another company...
"so I basically aced the verbal technical test on Skype. But I don't think I'll get the job anyway because the interviewers all seem like young punks who may not think I would fit their hip/young group."
I suspect that the original author has a specific idea of the kind of context that s/he wants to work in. One hopes that s/he finds a suitable company soon.
"All I was interested at that time was to get the hell out of there, not a place I want to work in or the kind of person I want to work with/under."
...and, about a Skype based verbal interview with another company...
"so I basically aced the verbal technical test on Skype. But I don't think I'll get the job anyway because the interviewers all seem like young punks who may not think I would fit their hip/young group."
I suspect that the original author has a specific idea of the kind of context that s/he wants to work in. One hopes that s/he finds a suitable company soon.
Quotes from OA, from a later post in that same forum:
"I was told the hiring manager was very keen to make me an offer but I have to travel about 4 to 5 hours to their office for onsite final interview."
"Yes, it's the team of young punks who interviewed me."
"This was a recruiter involved exercise where I was contacted. Did not apply for this position."Question to non developer profiles in SV (marketing, sales, PM, etc etc): does your interview include the whiteboard test?
Always pisses me off seeing these entitled "programmers" whining about their technical skills being tested. What I wouldn't do to be able to show how well I can code in person. Instead I always get filtered out after non-technical Skype interviews.
[deleted]
Seems like a whiteboard win-win. Company did not make an unsuitable hire. Candidate did not take an unsuitable job.
The candidate doesn't know if the job was suitable or not because they wrote the company off for not having HR standards inline with their own.
They have thrown him the CV and the candidate does not know the company was run by idiots? You must be joking.
I'm not joking because I don't know much about the company other than it sounds like it was a large company. (Author says "avoid large companies in his post").
If the people that interviewed him at a large company were unprofessional when he refused THEIR process, that doesn't mean the company is necessarily bad. He doesn't know.
I've never worked at a company, even a small one, where I thought everyone was competent. He had an opportunity to placate them and give the company a chance but he was so set on trying to tell them why their process was flawed and how his was better (look at my github and code).
Part of working at a large company is being able to be tactful and wade through the bullshit, often times dealing with incompetent people or those that do things differently. Maybe large companies aren't for him. They aren't for me either.
But it's not fair to say the company was run by idiots because they tossed a resume back at him when he refused their process. He obviously lacks tact and knows everything while being insecure at the same time (see young punks statement in thread). We also don't know that the interviewers are running the company as you suggest. If it's a large company, they probably aren't.
If the people that interviewed him at a large company were unprofessional when he refused THEIR process, that doesn't mean the company is necessarily bad. He doesn't know.
I've never worked at a company, even a small one, where I thought everyone was competent. He had an opportunity to placate them and give the company a chance but he was so set on trying to tell them why their process was flawed and how his was better (look at my github and code).
Part of working at a large company is being able to be tactful and wade through the bullshit, often times dealing with incompetent people or those that do things differently. Maybe large companies aren't for him. They aren't for me either.
But it's not fair to say the company was run by idiots because they tossed a resume back at him when he refused their process. He obviously lacks tact and knows everything while being insecure at the same time (see young punks statement in thread). We also don't know that the interviewers are running the company as you suggest. If it's a large company, they probably aren't.
"Part of working at a large company is being able to be tactful and wade through the bullshit"
^ This may be the only thing a whiteboard test is actually good for.
^ This may be the only thing a whiteboard test is actually good for.
I've had similar using live coding tests, barely minutes in and the candidate is clearly not coding what was specified. Asked why, they offer criticism of the interview process and an explanation of why their thing (usually a game or some graphical doohickey) is better.
This is an instant fail. These tests are as much about interaction and personality as they are technical skill. Which is why your GitHub profile is not relevant until afterwards.
You can have a profile full of great looking code, but if you're truculent, uncooperative and insist on being the smartest asshole in the room, you will not be finding work with my team today.
Soft skills, people.