Hey dev.to community! 👋
I’m curious about a question.❓
As I got my current / first frontend position through friendship and didn’t have to do any interviews, I was wondering about:
- Do whiteboard interviews still exist?
- Is it still a common procedure (regardless of company size)?
What was your interview process like (if you had one)?
I’m thrilled to hear about your experience! 🤓
Ps: The Internet is so populated with that picture. 😄
Don't you agree with that?
Latest comments (29)
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
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.
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.
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.
Yep, if you make it far enough into the interview process I've always had a whiteboard interview, or a "google docs" interview.
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.
Thank you, Chris, for sharing your experience with me! 🙏
I've already thought about doing interviews next to my current job, not because I'd like to change, but to practice how to participate in a job interview. 🙂 I guess I'm just about to start this process.
You're very welcome! Good luck!
If you learn a little from every interview you do, you'll be super-strong in no time!
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.
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.
One thing that often gets lost in the whiteboard communications process is that a lot of programmers are introverts and are less than comfortable with public speaking/performance, especially in a stressful situation like a job interview. You'll rarely see the best performance from them in this kind of situation.
I like the idea you have of discussing something before jumping right into the whiteboarding. For example, if you asked me to code out a random data structure or a low level database access method cold turkey, I would be likely to stumble about, trying to quickly recall something I haven't used in years. But, if you were to ask me to sketch out how I used a facade pattern in the application we just discussed, I could describe it well.
As an introvert I think that I might have an issue with freezing up if asked to whiteboard in front of someone, especially if I don't know them. I just would feel really uncomfortable.
Part of it is just my personality, the other part is that I tend to code in bursts.
I'm not sure of how others do their thing but when I am working on something I sit back and think for quite a bit of time before implementing a solution to build a mental framework for the task at hand. Sometimes this process can take a long time.
For example, at my last job I was asked to refactor a Salesforce trigger that had a DML limit issue. Being both new to Salesforce dev and the company I had to really go through the code to understand the objects, business rules and relationships involved. I'm not sure how many times I read and reread the code before jumping off, probably 2 or 3 hours of trying to understand what was going on. I took notes and first built up the solution on paper via a mix of psuedo and real code to break the monolithic method (something along the lines of 500 lines of code) into smaller, more atomic chunks to resolve the issue.
I know that doesn't directly apply to white boarding a solution, which is likely to be be a much smaller problem set but it does show how I think. I've always been someone that likes to build up a strategy/plan for what I need to accomplish before acting. I could appear to be stuck or not understand to a casual observer while I am going through my problem solving process. Once you add the pressure of observation to the equation I am more likely to act before I get a chance to think things through fully or not be able to perform entirely. The same sort of issues occur when I am writing code and suddenly notice a boss or lead type of person silently looking over my shoulder silently observing me working.
Yes, one of the really important things I learned early on is that each shop has their own culture and vocabulary. And as an INTP I also have a lot of empathy for introverts. So it's really important not only to establish a rapport with the other person, but also make sure your using the same words to mean the same thing.
Case in point. I was graduating from university many years ago. I had lined up some interviews with various consulting firms and I went into an interview with a recruiter from Arthur Anderson. I was going to be fresh out of college and getting my first "real" job in my field of study, Computer Information Systems.
I forget how exactly we led into the question, but the basics of it was:
AAR: "What is a tuple?"
ME: "A what?"
AAR: "A tuple, come on...surely you know this?"
ME: "..."
AAR: "You don't? What are they teaching you here?"
ME: "..."
AAR: "If you can't answer something this simple, I think we're done here."
ME:
Now, years later I realize that this was probably some junior level peon off on a power trip. He probably did this as some big ego stroke about how he knew fancy terms compared to us wet-behind-the-ear college grads. OR maybe he just had a sheet of definitions he was reading from with all the answers printed out. Or maybe it was some weird test of personality that I failed miserably at. I like to think they missed out on a really good hire because of it.
In any case, instead of tuple, if the recruiter had asked me: "So tell me about compound keys, records and relational databases?" I could have talked his ear off for 15 minutes about record sets, one-to-many relationships, cascading updates and deletes, acceptable values and lookup tables.
BTW: Tuple really just means a row or record in a table.
Because of those painful scars I always want to make sure that when I do interviews it's never a black and white Q & A, that we always get into discussions and clarifications so we're both on the same page (which is just as important to demonstrate their own communication skills as well as arriving at the technical answers), and that the "shape" of the answer is the most important thing, not the label we learned to call it by.
And yes, it may be petty, but I still smile and chuckle to myself when I think about where Arthur Anderson is today...
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.