Computer Geek, SharePoint MadHatter, devOps Champion, Automation Fan, PowerShell Player and sometimes I write Blog Stuff. I know GeekFu and TechNinja. Passionate about software delivery, devOps, agile
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.
Computer Geek, SharePoint MadHatter, devOps Champion, Automation Fan, PowerShell Player and sometimes I write Blog Stuff. I know GeekFu and TechNinja. Passionate about software delivery, devOps, agile
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...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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...