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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Thanks for sharing your experience Christian!
I can see that you aren't satisfied totally with the interview process at your company, so let me ask you some questions regarding that:
Yeah, those are some of the options. But I don't think there's only one solution for interviewing.
Home Assignments
They have the benefits of giving the candidate some room to breath and take their time to really polish their code, since having someone "breathing" on your shoulder can make them too nervous. But it is not fair for those who have a kids, a second job, college, or just have other interests outside of work.
Pseudo Code Tests
They don't provide enough insight of a particular language feature or functionality. Things like:
finalorconst?foror awhileloop? If so, how? Then why did you preferxoveryin this scenario?Giving him/her a laptop to code from scratch
It sounds better than having the candidate code on a whiteboard, but we still have the "breathing over your shoulder" issue.
But, this one can also help to test their debugging skills.
It would also require the company to dedicate resources into installing a wide range of tools like IDE/editors, so the candidate can feel somewhat comfortable.
Pair programming with the candidate
This is probably the one I'm most fan of. The interviewer can act as a guide for the candidate. As long as they provide a friendly approach to it. Instead of telling them what is wrong, the interviewer would have to say things like "this can be improved", "do you think we are missing something here?", etc.
Another big one for me is that I like to hear candidate's thought process. I ask them to speak out loud as much as they can so I can guide them through the process.
If the candidate turns out to make code that works but it might be missing some edge cases or could be cleaned up, I like to give them hints to see if they overlooked those details because they felt nervous or in a rush.
Personally, I feel that one of the best skills to have is to not only to know the programming language, but also the tools at our disposal. Some may think that a developer who depends too much on their IDE is weak, but I actually consider them to be productive instead.
And I've noticed this with candidates: they get too nervous, they stop their thinking process because they care too much about ending each line with semicolons, every parenthesis, etc. And if they are used to various languages, it can be even worse.
Those are some of the ideas I've considered, but I think I might have missed some details, I guess you can have a general idea of what are the things I look out for :)
I only can agree with you on these topics. We tend to recruit potential candidates similar the way you've just described.
Thanks for taking the time to share your thoughts with me! 🙏
I thought I'd pitch in one of my favorite interviews I've experienced. It was a remote interview, for an on-site position. It started with a Skype call in which the interviewer gave me a coderpad, explained the problem I was to be solving, let me ask any clarifying questions, told me I had 30 minutes, and then, get this, he ended the call. I was free to code and Google to my heart's content unsupervised!
There was no panic when I mistyped, no awkwardness when I had to Google something simple. None of that.
At the end of my time, we started the call again and I explained my approach and answered a few questions about it. I really really liked this approach because it was so low stress, but also because I think it showed that I could take a spec and work relatively independently on it, which is more or less what the job usually is anyway.
However, I don't know if this alone is enough for an interview. You probably also want to know if you can work with someone amiably, and I don't know if this method accurately shows that.
It's all tradeoffs ('-')/
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.
Thank you for sharing your thoughts with me Evan! 🙂
I also share the same opinion that the concept of using whiteboard questions as pass/fail components of a dev interview isn’t ideal.
I’ll prepare for a whiteboard interview if time will come to that though. 🤓
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.
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...
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.
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.
Thanks for sharing your experience with me, Teresa! 🙏 As I see you are quite experienced on this topic.
I can definitely see the connection between your response and Christian's, that pair programming is the best way to get to know your candidate. TBH my newest colleague has just got his job at us this way.
On his first day, he mentioned us that the best interview experience was at our company because we didn't make him do technical questions, rather assignments, and on-site coding.
Can I <3 this reply twice? Pls?
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!
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!
Thank you for sharing your experience with me!
I'm sorry to hear that you didn't pass this time! I wish you a good luck with your next interview! 🙂
No no worries at all! It wasn't the right time and the right place. All I know is I've learned a lot from this experience and it's on to bigger and better things ;). I did kinda wanted to see how the rest of the interview process would be. Like I mentioned, I've never had a white-board interview before. As a self-taught developer these things seem scary and I don't think they're a good way to assess skills (I've only interviewed interns myself but I couldn't imagine doing that to them). Yet I do feel like I sorta need to go with the flow...
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