Is the Coding Interview on Crack? Why all tech screens should be open-book
Would you take a programming job where you weren’t allowed to use any reference material besides what you had in your head?
I had two technical interviews today: a fucking terrible one, and an amazing one.
I’ll be honest, when I sat down to write this article I was ready to come out guns blazing making ridiculous hardline statements (as I am wont to do) about how all programming interviews are garbage and belong in the trash.
I’ll be more honest: I’m a shitty programmer, so naturally technical screens are my mortal enemy.
I’ll be the most honest I can be without the sheer weight of my honesty collapsing the planet into the center of a supermassive black hole:
Today I realized I was wrong: not all programming interviews are shit.
Before I can tell you about this revelation, though, you need some context on me and why I haven’t just put my nose to the grindstone on leetcode like everyone else.
Developer Relations
I work in developer relations. As a field, it’s our job to serve as the bridge between developers who make technical products and developers who use them. This includes a lot of teaching, speaking, community building, anything to help external developers better understand and use the tools internal developers create. Most of the industry does not push to production. So, tech screens are even farther removed from my natural workflow than most.
If you’re asking yourself why I don’t just man-up and practice, it’s because developer relations as a field is so cross-sectional, there’s no guarantee a given interview process will even have a tech screen. This makes the expected return of reading Cracking the Coding interview and drilling hackerrank different for developer relations vs normal software engineering.
Ok, now back to the story at hand:
The Terrible One: The way it is, was, and has been.
Now because I don’t do many technical screens, I had kind of forgotten how much I hate them. In a stroke of luck, today I was dragged back into reality and reminded how bad things really are.
A recruiter found me on Linkedin a week ago and sold me on an AI-powered dashboarding company.
“Sure,” I said “Interesting enough, I’m always down to have an intro conversation!”
Within 10 minutes of dialing in for this interview I was in an unexpected pairing portal (that didn’t execute code). The engineer gave me a poorly specified problem and told me we were doing it in python because he saw it on my resume. This man then deadass grunted at every other syntax error I made.
We went back and forth while he gave me the characteristic “help but not help” vague answers that didn’t help to further specify the problem. Eventually, frustrated, he started coding the functions he wanted to see rather than elaborating them with words.
I’ll admit: this was a terrible situation. It was a caricature of a bad interview. He sucked, I sucked even harder, no one was having a good time. There’s a lot of distance between this and a middling tech screen experience. However, IMO, that distance is still not enough.
Syntax(Sux)
Once, I talked to a Meta (then Facebook) coding “ninja”(they legitimately call their tech screeners this) who bragged offhandedly:
I’ll have them do the interview in a language they listed on their resume. If they aren’t fluent in it, that looks REALLY bad.
I really wish I could go back and ask him what he was thinking.
I worked at Slack for 2 years. Every piece of code I shipped there I shipped in Hack, which is a flavor of php used at pretty much only Slack and Meta. The last piece of Hack code I shipped was over a year ago.
I don’t think I could tell you how to declare a variable properly in Hack without looking it up.
Should I remove Hack from my resume as a skill, even though it’s the language I used to deliver every project during my tenure at Slack? Is being skilled in a language synonymous with being fluent in it when cut off from online resources?
I get that there are people who are embedded in a language or technology to the degree that the grammar is second nature to them. Me? In a given day I may switch between python, C #, and whatever wildcard project caught my eye that month. I spend a lot of time googling syntax, because the setup cost is so low that it doesn’t make a lot of sense to learn it by heart unless you need to convince a strange grunting man on the internet to pay you money.
Thankfully, I don’t.
The Open Book Revelation
About a week earlier, I received the normal recruiter wall of text about expectations of performant, optimal, tested, best practiced, commented, relevant-language-libraries-used, big O notated, data-structures-and-algorithms-leveraging code that taught them something they didn’t know, done in 55 minutes while paired. Needless to say, I was not optimistic about the interview going into it.
But there was one small shining, odd note at the bottom of the recruiter’s email:
“We want you to be yourself- use whatever resources and references you normally would. Using resources like Google and StackOverflow effectively is encouraged!”
Wait what?
You can… do that?
15 minutes after I ended the terrible grunting surprise programming interview early, I had a very different experience.
I’m not going to say I passed the programming interview with flying colors- I probably didn’t. As we addressed above, I spent precious time googling correct syntax. I think that’s a good signal for the interviewer: if they wan’t someone who is a fish to water in a specific language, then I’m not their person.
But that didn’t matter to me; I was having fun. The interviewer and I got along, and they encouraged me to use them as a resource, working like copilot to build out repetitive parts of the code we’d already moved past, and helping find and remove errors as I searched any unknown stack traces and called them out.
I felt free to be the shitty programmer I really am. Not just free, confident! Not like I was attempting to convince some algorithmic high adjudicator of my innocence. We’ll all be spending the better part of the 2060’s doing that anyways, so why get a head start?
To top that all off- I felt like I got insight into the company I was applying for as I worked side by side with one of their engineers. All this thanks to just letting me use the internet while I program. What a novel concept.
Costly Symbols: Why it's a bad thing that every recruiter is recommending "Cracking the Coding Interview"
Programming interviews are costly signals. Individuals that are able to devote the time to get good at them demonstrate a willingness and determination to join your group, be it by learning to invert a binary tree or learning to do a backflip. In my series on conformity and professionalism I point to standardized testing and similar filtering mechanisms as irrelevant to role-specific merit after establishing base competency.
“But wait!” you might say. “Programming interviews are directly relevant to the tasks being performed in the role you are interviewing for.”
How often have you referenced Cracking the Coding interview in your day-to-day work as an engineer? This calls to mind the famous Max Howell tweet:
Over time the industry has surrogated technical screen performance from a metric that served as a leading indicator of ability; to a means to its own end. Hell, Oxford still makes their students hand-write computer science exams- do we really want to take our technical lead from an institution older than the Aztec empire? I don’t.
So what are we going to do about it?
Passive Noncooperation
“The power of the people is much stronger than the people in power”
I’m about to suggest you do something extremely stupid that will make someone else’s day a lot harder. If you don’t like being stupid and you would prefer not to make someone’s day harder, stop reading.
Alright, now that all the squares are gone, we can talk. We’re all stormtroopers on the death star. Who gives a shit if you make a tech screener’s day harder? You think they are planning to make your day a walk in the park?
Next time you sit down for a remote programming interview that’s “closed book,” refuse. Tell them you are going to program like you would in your natural workflow. Google, StackOverflow, API docs- use them, and be vocal about it.
I’ll remind you- you are interviewing them as much as they are interviewing you. The technical screen has been one-way slanted in favor of employers for too long. Make them do the hard word of justifying why you should work for them in the technical interview.
I’m not advocating you spit in the face of every employer that won’t put up with your bullshit. That would be the job search equivalent of a tinder profile reading “if you can’t handle me at my worst you don’t deserve me at my best.”
I am advocating that you insist on demonstrating your ability to perform the role, not your ability to practice tech screens.
I’ll throw out a few criteria so any bikeshedders have to reach deeper to find silly simple things to take issue with:
Don’t Do This If:
You need the money.
You want/need the job and doubt you can get one elsewhere.
You can’t do it respectfully (i.e. without burning bridges).
You have better things to do with your time.
You think it’s dumb.
Do Do1 This If:
You don’t need the money.
You’re unsure about the job.
You know you can get a job elsewhere.
You’re tired of this bullshit.
Change doesn’t occur without friction. If you’re as tired of this as I am, be the friction.
Conclusions
Programming interviews are supposed to be signals of technical competency. The way they are conducted right now, they are signals of anxiety and prep time. In order to fix what’s broken we have to bring interviews closer to the reality of day-to-day work in a technical role so that we can evaluate candidate’s merit in a relevant, non-contrived context.
Employers: Allow candidates “open book” access to the normal resources they would use while performing the role they are interviewing for. Have them execute code. The realer, the better.
Applicants: You’re interviewing them as much as they are you. If a potential employer won’t let you have open book access, take it.
Afterward
As always, thank you for reading another long-winded article by yours truly.
If you hated the post, leave me a comment saying why :
Hell, maybe even share it with likeminded individuals anyways. Then, round up a posse and come harass me on twitter.
Maybe even consider subscribing so you can dunk on my next stupid post 😘
Until tomorrow, lovelies!
Lol I said doo-doo.