Coding interviews are stupid (ish)

Maaaaaybe, but I’m not ditching them. When I’m interviewing someone, I try to set them at ease. I’m not here to spot typos. I’m trying trying to trick you. I want to see how you think about problem solving, and I’m cheering for tou. I want you to be The One!

At a prior job I was the person who asked candidates to write fizzbuzz, and it was much more of a filter than I ever would have suspected. One senior engineer, from a company you know, with a master’s in compsci, couldn’t write a for-loop for the life of ‘em. Another QA engineer wanted to write tests for their implementation by capturing stdout and comparing it to a hardcoded string.

Me: What if you want to test the output of 1,000,000,005?

Them: We could store the test output as a file on disk instead of a string!

Me: Well, ok, suppose you only want to test that one specific value and not all the others?

Them: Ah, got it! We could discard all but the last line of stdout and just look at that.

Me: Can you think of a way to structure your code so that we could just calculate the output of one single number without all the numbers before it?

Them: Uhhh...

Those are 2 examples out of many. I honest to god don’t know how some people managed to build their resumes while not knowing how to do the simplest thing in their field imaginable. Imagine you were interviewing cardiologists and a solid 1/3 of them had never heard of blood. What? How? How did you get to this point?

And that’s why I’d never hire someone until I’ve collected evidence that they personally can turn ideas into code. If you can’t wrap your brain around fizzbuzz, you’re gonna have a hell of a time when a customer gives you a change request.

Everyone seems to agree live code interviews are both terrible and necessary.

I'm a self-taught coder without a degree. I guess it may be extra frustrating for graduated candidates where your hard-earned degree buys you no credibility for skill.

Kinda similar, after ten years of lead development coding every day in the enterprise on huge projects I still don't get a pass on the code interviews.

I will say, if you're trying to career pivot and apply for a management or product or sales engineering role etc., lots of technical experience does carry weight in interviews.

When I interviewed at Google I was making iOS apps using Objective-C at my current job, so I decided to stick with that for the whiteboard so I wouldn't blank out on some syntax at an inopportune time.

Big mistake. The method names get so long I was kept running out of space on the whiteboard and it took forever to write it.

I don't remember exactly what I wrote anymore (it was over a decade ago), but this site[1] has some examples of really long property and method names in Cocoa (its framework), like:

splitViewControllerPreferredInterfaceOrientationForPresentation

or

initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:

Anyway, for that and other reasons I didn't get the job (I apparently didn't prepare quite the right things, despite preparing for a few hours every night for the two weeks prior, which is how long the recruiter gave me before flying me to Mountain View, so my performance for at least two of the six interviews I had that day were a bit weak).

[1]: https://github.com/Quotation/LongestCocoa

How do you end the interview? To me it seems like that might be awkward.

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in CS and the coding abilities. This type of interview is similar to what engineers do at work too. We rarely invent new algorithms, but we do read white papers or blog entries or books to pick an algorithm to implement.

There are many variations in questions too: search a tree or graph with some customized criteria, using a double buffer to implement a tree-style prefix scan, implementing an integer multiplication with unlimited digits, some streaming algorithm, tree-walking to transform one tree to another, a simplified skip list, the options are unlimited. A good candidate tends to grasp the high-level concepts quickly (and they can ask questions), and is quick to convert intuition into working code. I find that there is a strong positive correlation between the performance in work and the performance in such coding interviews.