“Why Can’t Programmers…Program?”
A response to Jeff Atwood’s viral article
I cannot put into words how much I dislike this article, but it was written by Jeff Atwood — he is one of the most successful, universally loved people in the entire tech industry, whereas I am a random person with a blog and a few hundred followers, in contrast to Atwood’s 500 million. The post, which is still a top result in Google searches today even though it came out in 2006, argues that 199 out of 200 applicants for programming jobs cannot write any code whatsoever. The crux of his argument is FizzBuzz, which is — and I am not the first person to point this out — a test to see whether or not someone knows the mod operator (you can find implementations of it without the mod operator, but I find them convoluted).
The article is extremely short, so it does not elaborate on why FizzBuzz is a good test. I think that his claim is wrong and out of date, but all I can provide as proof is my own anecdotal experience.
Here are coding interview questions I have actually received:
String Compression, which I touch on in my now infamous post. I spent the first few minutes of the interview waffling about whether to use a hashmap, which people made fun of me for on Reddit. What you should use is a fairly intuitive for loop that checks for when the character changes, but if they ask the medium LeetCode variation then you are going to have to use something called the Two-Pointer Technique
Insert, Delete, GetRandom In O(1)
Convert a Binary Search Tree to a doubly linked list and merge two sorted lists. These questions were both asked by a FAANG company
Valid Parentheses. This, luckily, was a LeetCode easy
Valid Anagram. This was another lucky instance of a LeetCode easy.
All of these problems, I would argue, are considerably harder than FizzBuzz. If you Google for coding interview questions and stumble on the Atwood post, you will probably come away thinking that the ability to solve FizzBuzz will elevate you above almost everyone.
Better Post: The Guerrilla Guide To Interviewing
A user named Greg Skinner linked me to Joel Spolsky’s post from 2006 — he did so to provide proof that Gayle McDowell is not responsible for the state of coding interviews today, as Spolsky’s post predates Cracking The Coding Interview. A lot of people lump Jeff Atwood and Spolsky together…
…but I like the post a lot more, even though it is essentially in agreement with the style of interviews Atwood advocates for. The tone is completely different; he articulates his points like so:
And the same thing happens in programming. If the basic concepts aren’t so easy that you don’t even have to think about them, you’re not going to get the big concepts.
Serge Lang, a math professor at Yale, used to give his Calculus students a fairly simple algebra problem on the first day of classes, one which almost everyone could solve, but some of them solved it as quickly as they could write while others took a while, and Professor Lang claimed that all of the students who solved the problem as quickly as they could write would get an A in the Calculus course, and all the others wouldn’t.
The coding portion of Spolsky’s post can be broken down into two areas: First he advocates for a baseline test, then he argues for a harder coding test that involves recursion/pointers. The baseline test is a bit LIKE a FizzBuzz. For example, he might ask the candidate to write a function that takes in radius and outputs the area of the corresponding circle.
That the ability to solve basic coding questions incredibly fast correlates to successful software engineering is debatable. So is the second half of his argument:
For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.
That’s the source of all these famous interview questions you hear about, like “reversing a linked list” or “detect loops in a tree structure.”
This is something I had never thought about before — that the interest in linked lists and trees all relate to a deeper desire to assess one’s understanding of pointers. Once again, I think this is a little bit weird. If you are a frontend web developer, it actually kind of makes sense that an interviewer would emphasize trees; I believe it was Mayuko who speculated that Facebook tended to ask more tree questions because of their relevance. I cannot confirm how much software engineers at Facebook work with trees, but I CAN confirm that they like to ask about them on their coding interviews.
To say that they ask tree/linked list questions because of pointers seems odd.
Above, Ustav advocates for coding interviews because of “signal,” an indication of how competent the candidate is. Signal definitely sounds like something I will send over to my evil sister blog, Kurt Shiba Inu, to make fun of.
Closing Thoughts
Let’s say that we had this imaginary world in which software engineers, instead of taking coding tests, were asked to play chess against the interviewers.
Let’s say, in this metaphor, that a lot of people complained about it. You would play chess multiple times, and if you won every single game or at least were believed to have the skill necessary, you were hired. Then when you were hired, you didn’t play chess, you did software engineering.
Huh. Perhaps I am botching this bad metaphor.
Well, how good are the interviewers? I suppose they could be…1600. So on average, to land a software engineering job, you have to be playing chess at about 1600.
You can study. You can memorize patterns. You can look up past games from past players, but you might just find that your skill level plateaus. For better or worse, it seems to require a tremendous amount of effort to jump from your current level to 1600, so all you can really hope for is to maybe get lucky in a game or interview with a below-average interviewer who plays at a lower level.
There is a big opportunity cost here, and it could be better spent studying something useful. System design comes to mind. Another idea is to do what Ustav suggests above — focus on the fundamentals. That could be a whole series where, instead of simply trying to work through LeetCode, we just take some textbook concept from back in college and elaborate on it.
System Design could be a bit harder, but we could simply take the solution to some known problem from System Design Primer and do a bit of research, then do a write-up.
Another idea: Talk about some specific interview concept, like various guidelines from Exceptional C++. I have definitely had questions before like, “What is the difference between a static_cast and a dynamic_cast?”
Going forward, at least for the time being, that might be a better use of time. That way if I never do hit 1600, at least we’ll have a lot of useful knowledge to fall back on.
