So I refused a white board technical test and was asked to leave

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.

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 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.

>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.

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.

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.

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.

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.

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.

12% ? Oh wow... I will never visit a dentist again :(

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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).

> 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.

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.

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.

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.

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.

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).

Maybe, maybe not. Perhaps you missed genius coders who suck at white board fizzbuzz.

> 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.

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?

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.