[mike_hearn]

If you'd like an article giving an explanation for this that doesn't require upgrading to a paid Medium subscription, try this one I wrote a few years ago:

https://blog.plan99.net/in-defence-of-the-technical-intervie...

It is, natch, hosted on Medium, so you will see a banner, but unlike this paywalled article it's dismissable. Just click the X to make it go away and then you can read the whole thing for free.

The summary is that many interviewers ask "unrealistic" algorithmic questions because:

1. They fit in the short amount of time available.

2. They get people writing programs that cover all the basic features of the language.

3. They don't ask people to do excessive amounts of work (e.g. takehome assignments)

4. They wash out people who lack basic skills you'd expect programmers to have, like actually starting a new project and being able to compile/run it in their self-chosen editor.

5. They are general and don't tend to require knowledge of specific frameworks or even specific languages.

The questions are unrealistic because they're designed to be fast ways to extract information in an interview setting, not to actually be an accurate sample of the daily work (which in the time available may only cover a fraction of the skills required of a working programmer).

[pavlov]

Claims 2 and 4 don't apply to the way these algorithmic questions are usually administered at large companies, which is pure whiteboard coding where you can't run any of the code you're expected to write.

[mike_hearn]

Whiteboard coding used to be common but I haven't run a whiteboard interview for over a decade. I don't know how many companies still do that, but it's definitely a bad idea. You want to see how well a candidate knows their tools, and they will be more comfortable working in an editor, so it's a win/win to do that. Also if you do coding interviews from home it's easier for candidates and they're in a more comfortable environment.

So yeah I'm sure some firms do this, but there are plenty of others that don't.

[telotortium]

I think whiteboard interviews for coding definitively went away with the COVID pandemic - everyone uses some kind of live editor, usually requiring you to run the code as well.

[alephnan]

A fizzbuzz question would sufficiently address points 1 thru 5.

The issue at hand is that the "unrealistic" algorithm questions aren't fizzbuzz.

[tzs]

If I didn't know ahead of time that Fizzbuzz is to weed out people who pretty much don't know how to program at all I could actually fail it on an interview. It would go something like this.

They would ask me to write Fizzbuzz. I'd see how simple the problem is and immediately think of something like this (assuming they want it in Python):

  def fb(n):
    for i in range(1,n+1):
      if i%15 == 0: print("fizzbuzz")  
      elif i%3 == 0: print("fizz")  
      elif i%5 == 0: print("buzz")
      else: print(i)

  fb(100)

But then I'd think that this is too simple. That's something you could write just after glancing through a Python book at a bookstore. Surely I should use more language features to try to stand out among the candidates, right?

So I'd probably end up trying something like this:

  def fizzbuzz(n, *args):
    cur = ['' for x in range(1,n+1)]
    for m, postfix in args:
      cur = [y+postfix if x%m==0 else y for x, y in zip(range(1,n+1), cur)]
    cur = [str(x) if y == '' else y for x, y in zip(range(1,n+1), cur)]
    return cur

  print("\n".join(fizzbuzz(100, (3, 'fizz'), (5, 'buzz'))))

But Python isn't my main language and if this was a whiteboard problem I'd probably make some mistakes and they would be very unimpressed.

[andruby]

There are problems between fizzbuzz and the leet-code algorithms that are small enough to be solvable in 5 to 20 minutes. I like using one of them to complement other non-code questions.

[mike_hearn]

Fizzbuzz was the leetcode of yesteryear. It's exactly the same concept, just a different unrealistic question.

The leetcode issue is to a large extent caused by, literally, leetcode.com the website. When I first started doing technical interviewing this website didn't exist, so if you developed a question that wasn't too easy or too hard, covered the bases, fitted well into 45 minutes, that you could calibrate the difficulty of on the fly etc - basically a good question - then you could make it last quite a long time.

At some point people started sharing questions and pre-canned solutions online, and many candidates will cheat by looking up answers and copying them from another screen if they can. Also some shady recruiters started leaking questions to candidates ahead of time. That forced interviewers to start constantly inventing new questions.

One of the points I used to make in interview training is that questions are like programs, you have to design them. Some are better than others, they can vary in efficiency etc. Often you can't really know how a new question will work out until you try it a few times. Making a good interview experience for the candidate is hard work and it's easy to screw up, lots of interviewers do and it leads to a lot of bitterness (e.g. questions that are far too hard or specific or don't fit in the available time).

Unfortunately if you're constantly having to invent new questions to keep ahead of the people sharing them and grinding the process, then the quality will inherently get way more variable. By the time you've calibrated the question it's been leaked already. And there are a finite number of programs that it's reasonable to ask someone to write in a short amount of time, so by now these giant databases of interview questions and candidates memorizing the answers at scale makes it harder to get accurate information, which was the only goal in the end. Because indeed the specific tasks themselves don't matter much.

[alephnan]

Right, but points 1-5 aren't about these issues you're bringing up.

Sure, people can rote memorize "public static void main(String[] args)", but there's way you can test them their understanding on each of these magic keywords. This would achieve the goal of understanding programming language constructs without unrealistic algorithmic questions.

[mike_hearn]

That's covered in the article, my bullet points were just an attempt at a summary.

Briefly, it doesn't work like that. Interviewing developers is very unintuitive. Many reasonable expectations are violated. There are lots of people who can talk very well and will appear to have a good understanding of programming, up until the point that you ask them to write a program (any program) at which point they can't even start. If you don't force candidates to write an actual working program you will pretty quickly hire people who just can't do it, and then have to fire them later. Yes this sounds totally wrong, everyone struggles with this fact at first. It's sort of like the Matrix. Nobody can be told what interviewing is like from the employer's perspective. You have to see it for yourself.