How to lose a Job in 10 minutes

Albino Tonnina on June 12, 2018

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 th... [Read Full]
markdown guide
 

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...

 

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.

 
 

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

Thanks,
Anders

 

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.

 

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.

 

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 :)

 

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.

 

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!

 

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...

"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.

 

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

 

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...

 

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))

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 :)

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.

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! ;)

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!

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

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());
}


 

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.

 

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.

 
 

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

 

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

 

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 :)

 

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??

 

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.

 

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!

 

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.

 

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.

 

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

 
 

Eeeew hard-coded <br> in the middle of sentences. You should have
a doctor look at that!

 

Hi! Where is the hard-coded
? I have the doctor on the phone as we speak.

 

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

This renders really badly for certain viewport sizes. Excellent article though, I really enjoyed it!

Oh! That's bad! Thanks for telling me! I checked my article, no extraneous html tags so I guess the markdown parser that dev.to uses could be the issue. I'll forward this issue to someone!

And thanks for reading my article :)

Hey!
I think I've found the issue! It should look better now :)
Thanks for the feedback!

 

Thanks for sharing, I had almost the exact same experience it seems like. I interviewed at one of the Big 5 (from your explanation it sounds like it may have been the same one actually...), where I had 4 hour-long interviews back to back in one day.

I tried to prepare and review my algorithms etc. before going (it was a cross-country trip for me, so I had time...). I felt like I did pretty well on the first 3 interviews, and I'm sure I did a crappy job on the last one (which was purely algorithmic in nature).

And it was mostly because of the same things you described...I just did a bad job taking my time, explaining my approach, asking questions for clarification, etc. Literally as soon as I got back to my hotel room after that interview I banged out the solution in no time, but I just kind of choked in the room during the interview. I think it was nerves and being a little exhausted from the multiple interviews and probably just not being fully prepared with enough algo stuff. I don't know how old you are, but I've been out of college for almost 15 years, so it had been awhile since I had focused on that stuff.

Anyway, all this is to say that I have some idea of how you feel, and while it was pretty disappointing at the time, life goes on :) You sound like you learned a lot from the experience, so at least you got something out of it ;) Some of the feedback I got was to brush up on some of that stuff, and re-apply after some time. I have no idea if that would actually work (I haven't tried...) but it's probably worth a shot.

 

Hello!
Thank you for sharing your experience! I'm not alone :)
As you said it's been a learning experience so I'm fine :) Thank you!
And in your case, of course it's worth a shot, re-apply!

 

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...)
 

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

 

It's midnight here, and the article is too long, but I did a quick read, and lose a job after a interview recently.

There're a lot of things to think about, like how to solve this problem? If I can do the interview again, what should I do?

Then I come up with a theory that's the solution must be simpler than I thought, yeah, It's must be. But what is this?

Then somehow, I forgot to think of the solution, got high a little bit, etc

Then ... f*ck off, I fail because they didn't want me, that's it, haha. Move on to the next interview. My theory is proved now. LOL

 

I know how frustrating whiteboard interviews can be. It's why I made an online course to help people struggling with JavaScript interview questions. If anyone wants to check it out, here's a link with a coupon code already applied. The first few problems & solutions are free for anyone to look at. Hope this helps!

 

woah, looks great – have been (somewhat desperately) looking for something like this!

 

Hi Albino and friends,

Documented this "interview pattern" on a post here: medium.com/@dimist/red-flags-in-in....

After some deliberation I find it difficult to get out of my life, study algorithms for some time just to pass an interview, and then forget them, unless the interviewer confirms that day to day activities consist of doing such things.

I have a friend in a similar situation like you (self taught, Italian :), front end). His approach is to iterate through many companies until he finds one that does not do that type of interviewing, they are out there.

 

Hey ciao! ;)
Thank you so much for your comment, really appreciate it! Gonna read the article very soon, from the beach (taking a break from all this interview madness :P )

 

From reading your post: do a reverse Cinderella thing: instead of trying to change your foot to fit the shoe, get another shoe.
(and post pics with lots of sand).

 

Nice article. I too suffer from lack of skill at whiteboard interviews. Bummer you missed your chance this time at a big five. Keep at it; you can do it. A thousand no's but one yes is still a yes. Keep ya' chin up, you got this.

 

White board interviews 'should' be about how you think on your feet and whether you can explain your process. 'But' they seldom are. Frequently, the interviewers are technical people and they are expecting a specific set of solutions - ones they have seen before for a given problem.

It is possible to practice, even memorize, specific algorithms. There are books out there that are set up in a nice format to do so. I have read through and worked with many algorithms, but refuse to memorize them. Because I LIKE thinking through a problem and devising new strategies.

I often fail whiteboards! And I'm okay with that. The few times I've turned the interview around (because I wasn't totally whipped) have been when I started speaking to what I do know, to what I can do, and why. It is unfortunate that many interviews are about regurgitation.

 

Is it a misuse of reduce to modify acc (because, ideally in functional programming, things are immutable), or does returning acc from the reducer function mitigate that?

 

Hey! Thanks!

I would go for the mitigation :P

const groupCitiesByRotatedNames = cities => newArray

I guess you could return always a clone of acc? For the purpose of the article, I would not give too much importance to this to be honest :)

 

Really enjoyed your post, unfortunately, you didn't get the position but it seems you have learned a good deal with the interview process.
What I have been hearing on all the podcasts that I follow is that when you are in the interview you should talk through your process and also ask questions and include the interviewer as you try to deliver the code. Sometimes the test that you get won't have a quick solution and what the interviewer wants to see is how you react to pressure and if you are a good fit for the team.

I think being a self-taught coder makes things harder, we are used to having no one to talk to and it feels awkward to do it at first, I guess practice could help with that. One thing that could definitely help would be pair-programming so two of you could share ideas while coding.

Finally, the big 5 are very algorithm based and people that took a CS degree will always have some advantage in this scenarios. Doing exercises in sites such as codewars could perhaps prepare you for some of the questions that you might get in the whiteboard exercise.

I wish you the best of luck on your search :D

 

Hello !

I tried your problem, just to see if I can do it, I've used an ASCII sum, I think it should work, what do you think?

Go here: repl.it/@hydroweaver/how-to-lose-a...

I apologize for the code not being readable, I'm trying to slowly get there :)

 

You caught me with the first couple paragraphs.
I'll save this as a good read for later +Reading list

 

Ottimo articolo!
Mi è piaciuta molto la tua sincerità, e l'onestà di riconoscere le proprie mancanze
Stessa esperienza mia fatta svariate volte)))
In bocca al lupo!

 

Non ci arrendiamo!

Grazie Francesco! Crepi! :D

 

Really nice use of .reduce() there in the getWordRotations, been studying the implementation and curious how this thing knows when to return the array 🤔

 

Ok never mid, it's [...word] spreading it into an array which is just being used as an 'iterations count'. Noob moment there 😝

 

Noes! Let's outlaw whiteboard interviews instead -- don't encourage this -- they're on the way out in their traditional form.

 
 

Man, do I empathise! Thank you for sharing your experience!

code of conduct - report abuse