They are, I was interviewed that way when I got into my current job and I've been guilty of asking candidates to do it many times.

Thanks to posts like this I'm now aware that it is not the most optimal way to evaluate a candidate and I'm working on making a paper so I can bring it to my team leader to suggest alternatives with pros and cons of each one of them.

I'm part of a small team at my company, so this could potentially be brought to everyone's attention so others can also stop doing whiteboard interviews.

I've been interviewing actively for the past few months and, yes, whiteboard interviews are very common (unfortunately).

Typically, it's some kind of coding puzzle that frequently doesn't have much to do with your ability to do the job. So, practice up on your basic data structures and algorithms even if they aren't all that applicable to the job in question.

As for interviews I've conducted in the past when I've been the one doing the hiring, I prefer a conversation to testing. I ask about their projects, what they found most enjoyable and what was their least favorite, most and least challenging, etc. I ask about their approaches to problems.

Based on my reading of Cracking the Coding Interview whiteboard interviews are standard practice at the "top tier" tech companies. From what I understand they bleed down into most smaller companies as well (about 90% of my software interviews had a whiteboard component).

I do tend to ask a few whiteboard questions when I interview people but I try to focus on the conceptual understanding and communication skills rather than syntax specifics. Most of the time the candidate produces psuedocode similar to the language they said they would use and I am fine with that.

I don't think requiring runnable code or using the whiteboard portion as a pass/fail component are all that useful when evaluating candidates.

All that being said, if you are looking for a new job I would prepare for a whiteboard interview question because you will probably get one.

White board interviews almost always exist as a component of an interview if you're going to be working with other developers and other team members.

In general, I usually start off the interview with basic conversational questions, getting a feel for their personality and what their strengths and weaknesses are. I have about 7 or 8 "vanilla" system architectures that I use as references when talking about various projects and concepts, which we generally flesh out over the course of the interview.

Assuming that the interview is going well, that's where we bring in the white-board, and I have them start diagramming out some of the architectures we've discussed. This helps me get an idea of their communication skills with whiteboards, ability to regurgitate the information we've just discussed, and get a good understanding of how their brain works.

With most interviews, I'm always asking myself how well this person will integrate with the team, how their communication skills are, will their personalities mesh, is this someone I would want speaking to a client. It's the soft skills that are most important because the technical know-how is already a constantly changing landscape and we can always use training to elevate their coding skills.

But if they can't communicate an understanding of what we talked about or be able to draw out various whiteboard exercises based on the concepts we've discussed? It's usually a thank you for your time moment.

I've been interviewed that way at Google with 5 interviews in a row, and I'm pretty sure they are still doing this. So if you want to get a job at Google, better get a copy of "Cracking the Coding Interview" and train yourself at being able to solve optimization problems on a whiteboard.
(I used my window for that - perfect solution if you don't want to buy a whiteboard.)

In other companies I've been asked single questions where we used the whiteboard. But most interviews actually had practical coding questions, where I had to sit down and develop a piece of code. For example, I was asked to develop an app as homework and deliver it after a week, or had a couple of hours to submit code to a coding question. I even had whole probation days where I was asked to do pair programming with the interviewer.

From my personal experience as a team lead who interviews people for Android positions, I'd say that practical coding, especially pair programming, is the best way to assess the abilities of a candidate. Not only the technical ones, but also the soft skills that you need if you work in a team, like communicating strategies or discussing alternative solutions.

Yep. Whiteboard/algorithm interviews are alive and well.

I once had an interviewer pose a question to me, then basically wait for me to say, "Dijkstra!" and put the code on the board. (Full disclosure: I failed to do so. I blame jetlag.)

At another company, they didn't have whiteboards, so they asked me to write out code with pen & paper.

And I did a Skype interview that consisted of, "Hi, how are you? I'm going to share a document with you. Please type in a sorting algorithm." Once I'd completed that, they thanked me for my time (all of 15 min.) and that was it.

Algorithm interviews are bogus, but I'm not about to let them stop me from getting a job, so once in a while I open up a fresh project in my IDE and code up a quick sort implementation, or do some kind of tree/graph traversal exercise to keep it all fresh in my mind.

On the other hand, the kinds of questions an interview poses, and how they company conducts interviews tells you a lot about the company culture, and who you'll be working with.

I see from your profile that you're a junior dev. One thing I wish I'd done early in my career is take interviews for jobs, even if I wasn't really looking. As long as a job looks like it might be a step up, apply for it and take the interview (if they call you). It'll sharpen your interview skills and give you a window into what opportunities are really out there.

I haven't had a whiteboard interview in either developer position I have held. However, there was a "code" component to each.

The first job, I was still in school. After getting through the talky part of the interview I was asked to take a seat next to my future boss by his desk. He pulled up a chunk of code and asked me if I could explain what it does. I stumbled a bit because it was my first time even looking at in-production code(he literally opened up their code base and pointed to a method for me to describe to him). It was a basic database query with some data manipulation that was dropped into a data table. I explained to him that I had never seen a datatable(for some reason this wasn't covered in school despite having multiple semesters focused on C#) before but it appeared to be grabbing multiple rows from the database via the query. Long story short, I got the job.

The second job I got I had 3+ years in doing .NET dev but was interviewing for a position requiring me to learn their entire tech stack. They sent me home with a coding project. It was basically to mock an API call with an allotted time of 1 hour in the language of my choosing. I was working with a pretty vague definition (which they said was intentional). I didn't quite finish in the time allotted but got pretty darn close. It was close enough for them to decide to hire me as well.

I just went to an interview process that included a codility test that I didn't pass. The next step would probably have been a white-board interview. I got my last job in a very friendly and natural way as well, so I was kinda thrown off by the whole idea!

Yeah they do. In Data Science I've been asked to solve silly non-data science related questions on a whiteboard.

Recently we hired a Data Scientist where I work, and I was tasked to screen the candidates. We gave them an option to present a project of their choice that covered certain topics related to the job, or gave them an assignment that was 100% related to the posted job.

The interview consisted on bringing their solved assignment, and we would go over and ask questions about things their missed, or didn't have time to put much effort into it because of other responsibilities. We were VERY clear the assignment was only to asses their expertise for the posted job, and they didn't have to spend much time on it as they would be guided in the interview to solve the problems they didn't have time to tackle. I would say that assignment was only 20~30% of the weigh of the final decision. All but one candidate passed the assignment. The one who missed clearly needed a little extra experience for the position.

We need to see candidates as people, and not objects.

Fortunately they still exists, I think is a good way to see how a dev thinks a problem and just talk and find solutions for problems. It is not related to a specific technology, paradigm so is more about what you are made of and less the knowledge.

Whiteboard I mean in the broader sense, it is a good env to explain and draw what you think, how you solve a problem in collaboration or draw diagrams, and less about syntax and using an IDE. I think is a good way to express yourself if used right. I think whiteboard would be more popular if developers and companies would see it like this and less about "stupid highschool algorithms that noone use".

I suggest going to local meetups and ask around if these kinds of interviews exists in your town, at your companies and positions, the dev.to community is pretty spread out si any answer here would not help you so much.

The last time I was searching for a job, I had in total half a dozen interviews. The technical part of most of the interviews came down to a conversation from developer to developer. One interview included some live coding (they had a small exercise prepared - but a rather mundane task, nothing what could catch you cold) and in the interview which lead to my current position, I was given a few short code snippets and was asked to comment on them - it served more or less as a coarse filter whether or not I knew some Java fundamentals.

The write down insert obscure algorithm here from memory on a piece of paper interview I have thankfully not encountered yet.

So we do both home code tests and use a whiteboard as part of our interview process. I've sat in a few of them and we're not trying to see how the candidate thinks and approaches a problem.

Generally we're looking for pseudo code and we're mostly seeing how well they can solve a problem (generally, we start with a simple problem, then change it a bit, tthen change it a bit more and so on). This way we can also look for candidates who get precious about their code. If you're not willing to rub something out on a whiteboard when you don't need it anymore then you are unlikely to be able to do it with code. Which is a bad sign.

I'm maybe too nice, but there's been at least one candidate weeded out of the interview process because of their whiteboard test. Nice but out of their depth.

Unfortunately, they do. I have declined several invitations for such interviews in the past as it seemed pointless to me. I've got all of my jobs with technical questions and code challenges or sample projects.

Yep, if you make it far enough into the interview process I've always had a whiteboard interview, or a "google docs" interview.

PAIR PROGRAMMING?!? Are you NUTS?

If whiteboarding is the frying pan, pair programming is the fire. I'd rather be homeless than do that ever again