How to lose a Job in 10 minutes

Whiteboard coding interviews can cost you a job

Recently I’ve been quite close to getting a job at one of the Big 5. I went through the screening process and the take-home assignment smoothly but I failed to pass one of the final stages, a set of one to one, or two to one, interviews:

• Whiteboard coding interview: algorithms.
• Technical interview: JavaScript, CS, React.
• Culture fit: that.
• Second whiteboard interview

It went wrong

There are a few mistakes that contributed to this temporary debacle.

I may have passed the techical test and the culture fit (let’s just assume that) but I admittedly performed badly at the whiteboard coding interviews.

Thinking in retrospective about that day I couldn’t expect any different outcome.

The truth is: I’m not prepared to do whiteboard interviews.

Whiteboard interviews

The whiteboard interview is, in some ways, a hybrid of a technical test of the depth of your knowledge and also a social exercise
(source)

We all know what it is, right? it’s not much about the code, it’s about your solving abilities, it doesn’t matter if etc etc…

I’m a frontend developer, I generally don’t implement interview-like algorithms or articulate my thought process while I code, I sort of make interactive UIs most the time.

How much do these tests tell about a candidate anyway?

Someone even said:

In real life, you would rarely just whip up an off-the-cuff algorithm from memory in the middle of a coding session. You are almost always going to use an existing library, which has its own test suite, and has survived the scrutiny of other developers.

The only world where you would actually need to be able to recall an algorithm would be a post-apocalyptic one, where the hard drives of all the computers connected to the internet were fried, and all copies of foundational academic papers and computer science textbooks had been reduced to ashes.

My opinion tend to match the one of the aforementioned author although I like to believe that such a skill (being good at whiteboard interviews) is about having a set of very good to have other skills, soft and hard.

Mitigating circumstances first

I’ll make this list because you may relate to some of them but most of all I still have to vent a little bit 😄

• I didn’t do the interview in my first language. Under pressure and under the spot it suddenly becomes more difficult to talk in english.
• I’m a self taught frontend developer. I lack an academic preparation.
• I didn’t do many interviews in my career. And not many of them had whiteboard interviews kind of tests.
• I don’t do much public speaking. Unfortunately, at the moment, not much.

You could object that none of these are actually mitigating circumstances and you would be right.

By definition, mitigating circumstances are out of our control: the truth is that I could improve my English, do more CS, do more interviews, do more public speaking.

---

I’m gonna try to solve that first whiteboard test the way I should have done that day and I’m going to try to report the process here.

The Test

;['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris'][
  // YOUR ALGORITHM
  (['Tokyo', 'Kyoto'], ['London', 'Donlon'], ['Rome'], ['Paris'])
]

That’s it. If you rotate the letters of each city you may or may not match another city. In case you do, put them together in a array on their own.

At work you’re escaping labyrinths of thousands of lines of code on a daily basis, how difficult is to show these people how to solve this simple and even kinda funny problem? Hold my beer.

Yeah…

Let’s pretend it went slightly differently.

The perfect whiteboard interview

Catchy paragraph title, although wrong. This is just the way I could have solved this test, both code and thought articulation. Who know how many other ways there are!

Me: thank you very much. I’ll gladly solve this problem for you (little bow)

Me: First question, do the letters just ‘rotate’ or they can be randomly mixed up?

Larry (to protect the privacy of the interviewers, I changed their name into a fancy one): Just rotate. First letter goes last, etc.

Me: right.

Larry: right.

Me: Right! I guess to start I would need a way to rotate the letters of each city. Tokyo would became okyoT, then kyoTo, oh cool! we’ve got kyoto now! Ok, I’m going to need a function to do that.

Me: I also need a way to loop through the input cities, ‘rotate’ the letters, do some matching and lastly grouping them together. I see that the input and the output are both arrays and they both contains the same values, the only difference is the depth of the two arrays, a flat one and an array of arrays.

Still me: I’m gonna write some pseudocode now to validate my thoughts. Later I’m going to test it too, cause I’m that good. 😏

function groupCitiesByRotatedNames(cities) {
  // use a variable to contain the output.
  let output = []
  // loop through each of the cities
  //  rotate the name in any possible combination
  //  check if the output contains a city that matches a combination
  //   add that city to the array containing the match
  //   otherwise add the city to the output as a new array
  return output
}

Me, confident as a rockstar: let’s pseudotest my pseudocode (😛).

const input = ['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris']
console.log(groupCitiesByRotatedNames(input))
// That's how it would build up. The final output would be the last array:
// [
//     ["Tokyo"]
// ]
// [
//     ['Tokyo'],
//     ['London']
// ]
// [
//     ['Tokyo'],
//     ['London'],
//     ['Rome']
// ]
// [
//     ['Tokyo'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome']
// ]
// [
//     ['Tokyo','Kyoto'],
//     ['London', 'Donlon'],
//     ['Rome'],
//     ['Paris']
// ]

Let’s start implementing this algorithm.

First, the utility to rotate the letters of the city names. I will create a utility function:

Me: let’s make this function a bit smoother (and less readable). Overconfidence at its peak.

Me: Right! I like the reduce method, I’m gonna use it again! (It’s also very functional-programmy so it’s cool to use in an interview 😎)

The reduce() method applies a function against an accumulator and each element
in the array (from left to right) to reduce it to a single value
(MDN).

Our single value being the desired output.

Let’s sum up what this algorithm does:

We check for each city in the cities array, we rotate the nameand we match
every combination with the accumulator value. If we find something we add the new city to the array containing the matches (with Array.splice) otherwise we just push a new array containing our new city.

Et voila’:

All together now!

Get the Gist here.

The actual whiteboard interview

I started from the solution. I said, ok, I’m gonna need a reduce method. I immediately approached the board to write actual code without really knowing the plan. I did have an idea of the solution, pretty much the one I wrote in the previous chapter, but I didn’t articulate it, I didn’t really explain it consistently to my poor interviewers. So I got lost in the code, I lost the the train of my thoughts several times, I also stumbled on syntax errors, in a mix of poor written pseudocode and actual code. There was no way to turn the tide at this point. A performance like this can make a lot of damage to the outcome of the interviews, especially if you let this affect the rest of the process on your side.

What should I do now

Practice, practice, practice.

Get a whiteboard, pick a problem and talk out-loud to the air and write, do that a lot.

Practice the whiteboard interview, learn the routine. Your routine, any routine. Learn it like a song on the guitar, a card trick or whatever dangerous stunt with your skate.

You need to prepare a speech, it’s like a presentation.

It’s like a presentation with variables.

A variable is the problem.

I’ll go like this:

• I’ll spend some time analysing the requirements (1 min)
• I’ll formulate questions if necessary and get answers (3 min).
• I’ll pause and think of a direction to take (few min, don’t be afraid to stay silent for a while).
• I will propose initial solutions and get feedback from the interviewers (5 min).
• I will pause again and choose a solution (2 min).
• I will write pseudocode (5 min)
• I will test my pseudocode (5 min)
• I’ll finish by transforming the pseudocode into actual code. (until necessary)

In around 30 min I will have solved the problem in a enjoyable and ordinated way.

Conclusion

Thanks for reading

And Thanks Adam Mackintosh and Josh Comeau for proof-reading this :)

Hello, my name is Albino Tonnina, I’m a frontend engineer who does bad whiteboard interviews at the moment and works in London, you can find me on Twitter or Github or Instagram or around the city.

Comments

[Patrick Minton]

I applaud the effort in your post, but maannn.... I’ve been hiring developers for about 15 years and I’ve grown to despise white board interviews. I’m convinced that any organization that requires whiteboarding in their technical interviews is simply doing it wrong.

I’m also pretty convinced that the “big 5” have very inefficient hiring practices (and I’ve worked for two of them, so I speak from experience).

I understand why junior devs want to work for them, it’s a sort of initiation ritual into the tech world, but I wish more companies could move on from interviewing practices that were invented back when we used punch cards to write programs...

[Anthony Bouvier]

I agree totally with this. I don't do whiteboard interviews and I've been hiring other devs since early 2000s. It shows absolutely zero and starts everything off in a hostile environment. Prove to me you can cook a dish by writing out a recipe with your non-dominant hand. And stand on one foot.

Whiteboard interviews are more hazing ritual than anything.

[Albino Tonnina]

Ahahah I enjoyed a lot your reply, thanks :)

[Anders Baumann]

Hi Patrick.
What do you use instead of the white board interview to make sure the candidate is right for the position?

Thanks,
Anders

[Patrick Minton]

We do one design interview, and one programming interview (out of 5 total). Candidates are encouraged to use the whiteboard if it helps them explain their thinking, but the whiteboard is just a tool.

So "design" will concentrate on architectural decisions, whereas "programming" will concentrate on things like algorithms and data structures.

The other 3 interviews are all about behavioral questions, not programming ones.

[Dominik Schwind]

I've long made a pact with myself: the moment an interview process includes a whiteboard part, I walk out and tell them it's because of the whiteboard. At this point they either want me enough to hire me anyway or it is a better outcome for both parties when I don't work there.

[Ben Sinclair]

The people in charge of the interview process may well not represent the rest of the company or its culture. At at least one place where I worked, the interviews were done by tech-savvy senior management without involving any of the day-to-day development team at all, which resulted in us employing a lot of people who never lasted their probationary period.
In the trenches, it was still a good team to work for :)

[Chad Smith]

When I am interviewing people I honestly don't even care if they give me a fully correct solution. I understand not everyone can do that spur of the moment. I certainly can not. What I'm looking for is confidence in your solution, your thought process, the questions you ask, and if you can explain why you think your solution is right.

[Albino Tonnina]

That's exactly what I did wrong. :)
Knowing me, not knowing how I should do whiteboard interviews I've got nervous, ultimately auto-sabotaging my performance. So what this test proved of me is that when I'm agitated I cannot articulate the solution of an algorithm. It's something that for me has to do more with public speaking than the job itself. I never have that feeling at work, not like that!

[Till Gartner]

The interviewer did a bad job: it’s his duty to make you feel comfortable and safe. And it’s his job to animate a conversation if you’re stuck in your thoughts. And it’s his duty to guide you to write or discuss top level pseudo code.
Then whiteboard interviews make sense...

[webware]

"The interviewer did a bad job: it’s his duty to make you feel comfortable"

Agreed. I always try to make people feel comfortable because if they don't, I ultimately don't get a chance to see what they are really capable of.

[Fabian Holzer]

Well, interviews are always stressful situations, so don't beat yourself up about it.

But one remark: try to resist showing off too much technical cleverness. Two reasons for that: first of all, you risk getting lost in unimportant technical details (what was the exact signature of a reducer function again?) rather than acutally solve the problem. Also you might also raise suspicion that you value complexity over simplicity.

Personally I think the best interview preparation is having a real person in the room (which doesn't need to be technical at all) to which you talk. Mentally walking through an interview on paper or in a preparation book is not the real deal. It costs a little bit more effort, but is worth it. The second best to that is rubber ducking. But by any means: talk out loud, even if you are alone in your room.

All the best for your next interview (with or without whiteboard)

P.S. I could not help it, and came up with this alternative solution to the problem

[Andreas Pizsa]

Love your solution, Fabian; short, precise, efficient, readable & understanding the actual problem over having to show off reduce :)

This might be for you:
goodgamestudios.com/careers/jobs/h...

[Andreas Pizsa]

Here’s my take based on anagramNormalized (SCNR ;) )

function anagramNormalized(str) {
    return str.toLocaleLowerCase().split("").sort().join();
}

function groupBy(array, fn) {
    return array.reduce((result, word) => {
        const group = fn(word)
        const target = result[group] || []
        target.push(word)
        result[group] = target 
        return result
    }, {})
}

const list = ['Tokyo', 'London', 'Rome', 'Donlon', 'Kyoto', 'Paris'];

Object.values(groupByAnagram(list, anagramNormalized))

[Albino Tonnina]

Thanks both of you!
Your solution I'm afraid doesn't solve the problem though!
It's important that the letters rotate one by one, sorting them would create false positives.

So London and Donlon would go in the same array but not DnnooL!

Also using reduce on an array is not showing off, come on, it's using a legitimate method of the array object, what's wrong with it :)

[Andreas Pizsa]

Ah, you’re right, I missed that requirement.

Nothing inherently wrong with reduce – I’ve used it in my solution ;)

But back to whiteboard interviews:

I've seen dev interviews from both sides of the table. Currently I manage a team of developers and as such I also hire people; we conduct interviews over video calls, and I ask candidates to take an actual coding challenge.

You might be surprised at how many people with "impressive" resumes apply for senior dev positions and can not explain or let alone code the simplest thing. And I mean the simplest thing, like sorting an array.

So, I like my whiteboard interviews because it helps me identify the strong candidates that we then hire to build a great team.

[Albino Tonnina]

Hi Andreas!
I cannot surely disagree with you.

With this article I just explored a thought, a little doubt about this process: what is the actual skill that is being tested during a whiteboard interview? We know that observing a candidate during a whiteboard interview gives us insights about both their communication and their technical skills.
My hypothesis is that the particular "sub-skill" of communicating effectively under stressful circumstances such as an interview is a must-have if a candidate wants to pass this test.
This sub-skill though may tell little about the talent of the candidate, unless you are looking for someone that needs to have that of course.
And the lack of it though could overshadow any other skill they may have, maybe jeopardising the entire interview.
In conclusion what I would say is that people should do practice for this test.
If you're not a natural, practice is the way to go. Problem solved! ;)

[Andreas Pizsa]

In conclusion what I would say is that people should do practice for this test.

I agree and I appreciate your pro-active approach.

Keep in mind that failing this interview because of your lack of this one skill didn't get you the job you wanted and applied for. (I’m not saying this to criticize you)

Great candidates master this skill and at the same time are great developers as well. These are the ones everyone is looking for; and they are your competition.

Taking the proactive route of acquiring this skill will take you a lot further than blaming employers for doing whiteboard interviews; Kudos to you!

[Juraj Polačko]

Can someone please elaborate on why the solution with sorting string literals to be compared and then finding out if they are same (case insensitively) would not be sufficient? How does it not meet the requirements?

I understand that the point of this post is elsewhere but just not to wrap my head around it anymore.

Thank you

[Fabian Holzer]

Well, the solution matches the provided test case, but the test suite obviously was not extensive enough to test for all edge cases. Poof provided in his reply the hint

So London and Donlon would go in the same array but not DnnooL

It also was in the "interview" part of the article:

First question, do the letters just ‘rotate’ or they can be randomly mixed up?
Larry (to protect the privacy of the interviewers, I changed their name into a fancy one): Just rotate. First letter goes last

So comparing by the anagram builds up groups of the wrong equivalence class. To use the phrasing of Poofs article, it is "randomly mixing".

But the definition of "just rotate", as I understood it after the new test case, that DnnooL is not in the same equivalence class as London, is to be case insentively the same string as one element of the set that you get when you split the string at any index, swap the parts and concatenate again.

Albeit, I still stand by the general structure of the solution I proposed, which doesn't need reduce at all. Just swap the predicate isAnagram with isRotation, e.g.

function range(n) {
  return Array.from(Array(n).keys());
}

function allRotations(str) {
  return range(str.length)
    .map(index => [str.substring(index), str.substring(0, index)])
    .map(array => array.join("").toLocaleLowerCase());
}

function isRotation(a, b) {
  return allRotations(a).includes(b.toLocaleLowerCase());
}

[Dustin King]

An alternative approach to this question is to put the cities into an easier to work with data structure, such as a map (aka object) of sets, with the key being a canonical rotation, and then translate that into the desired array of arrays in the output. (Here is that as a gist. )

You didn't ask for suggestions on the solution, but I couldn't resist playing around with the exercise. I might have drawn a blank if asked to come up with this at a whiteboard though. My first solution was four nested loops.

[Albino Tonnina]

Hi Dustin, thanks for your reply!
I didn't ask for suggestion because I'm sure there are so many solutions to this test!
More performant, more declarative, more functional, more more more :)
Someone may even find an O(1) version of this, I don't know :D

As you said the problem is doing it there, under pressure. I like to write elegant code, I like approaching problem methodically, I do like these problems. But my method it just doesn't work in a context like that. Not when the stakes were so high.

[Rafe Goldberg]

@poof – speak truth my man!

[Ope Adeyomoye]

I laughed so hard at "four nested loops" 😂😂😂

[Till Gartner]

I do whiteboard interviews (interviewers side ;) ).
A clean and readable solution with nested loops would have been perfect for me.

[Ben Sinclair]

Cool article.

I would approach something like this in as simple a manner as possible though. I'd use those creaky, dinosaur-like for loops and so on. I'd tell them I was doing it deliberately, too. I might make the code more modern in a second pass or talk about it in the inevitable section afterwards where they ask you what you could do to improve it.

Just my vector. I've never passed a whiteboard interview, though, so what do I know.

[Albino Tonnina]

Thanks Ben!
While I agree with you, it's becoming more rare everyday for me to use for statements. They just don't came anymore as first option to be honest! I guess that the community did a good job in advocating for array methods lately!

[Victor Bordo]

Completely empathize with your experience. Whiteboard interviews just aren't sufficient for gauging the skill-level of a dev. It also makes it difficult to figure out how well that individual can function in a team environment because the whiteboard interview is so artificial. Ensuring that the interviewee is embedded in an experience that more closely resembles the collaborative setting software is built in usually produces a better result for everyone involved.

This is actually what led @tonymastrorio and I to build Whiteboardfree. You can use the site to find jobs at companies that don't whiteboard during the technical interview process. No need to hassle with those interviews anymore :)

[Till Gartner]

So if the company doesn’t do a whiteboard interview, doesn’t give out coding exercises, then how should they get an idea of the candidates capabilities??

[ErnestJoyce]

Just my two cents, here, but I think the interviewers are looking to see if think about grouping the city by length first, and then check for rotation matches.

Then, if you want bonus points, I would not write a function that create the rotations for one city, but checks if two cities are rotation matches. You don't really need to creates strings, just compare offset indexes. You can quickly decide that a pair of cities are not a match here, by finding all the letter in the second city that match the first letter of the first one: if none, not a match ever, and if there are, then you just reduced the number of possible rotations "anchors".

Granted, not necessarily easy to think about all that under pressure, but that is what a whiteboard coding interview is: not focusing on the small syntax details, but on the general approach to the problem.

[Christoph Michel]

That's a nice idea. I also just thought of a useful way to check if two strings x,y are rotations of each other.

x is a rotation of y iff x occurs in yy and size(y) = 2*size(x)

Actually, it's quite similar to what you're suggesting.

[Gabriel Magalhães dos Santos]

I think whiteboard interviews is too much old for 2018.
Today we have so many ways to know the level of knwoledge of a candidate, with a simple test or pair programming already know the level.
The best experience i had in interviews was when the interviewer send me a test and when i finished he call me and ask how and why I come to that result, he tried to understand my logic and how difficult/ease it was for him to understand

• no pressure
• no fear
• just code and a good conversation (like us in a day job) 🙂

The tips I have is:

• aways remember, the interviewers DON'T know development, with lucky they know what is a if() or for() 😂, so trie to communicate, talk about what you want to do, sometimes they understand everything only reading the variables and some explanation.
• Make all the questions you need to resolve the problem, they have the answers you need to get in the result.
• You don't need to trainnig aways, but only if you want to switch the job, in this case I suggest you training one of this coding challenge websites (HackerRank, TopCoder...)

[Albino Tonnina]

Hello Gabriel, wonderful comment, thanks! Couldn't agree more!

[Jonathan David Forrider]

Personally, I think a Whiteboard interview would just infuriate me. I watched a mock whiteboard interview on YouTube done by one of the "Big 5" and I was pissed at the end. It felt to me that the interviewer was just trying to trip up the interviewee. Kinda like, "You think your smart eh? Then prove it, Dumb Dumb." Frankly, I think Whiteboard interviews strip companies from hiring very talented thinkers and coders and they also seem slightly dehumanizing. IMHO

[Albino Tonnina]

Chapeau 😊