Published in


The Other Side of the Software Engineer Interview


I have now probably read more than 1000 responses to my article “If software engineering is in demand, why is it so hard to get a software engineering job?” My favorite comment, which came about a week ago, was by someone named Juan Nicholls, who apparently built his own comprehensive interviewing guide on Github for anyone to access for free. Someone made a YouTube video with the exact same name, and a comment that stood out to me on that was that this is a problematic question to even ask. The question, I want to remind any readers, was named after a Quora post but I still made the decision to call the article that (in quotes). To this day, that article still gets maybe 80% of the traffic on this blog.

I was aware that this article was discussed on ChangeLog, but I did not realize it was a podcast until yesterday. The mind-blowing part, for me, is that the person they interviewed was Pragmatic Engineer.

This is a video I have linked before on this blog. It is the best I have seen, not just for its practical advice but for its mature perspective. He encourages anyone going through the process to treat it as a learning opportunity, and not get hung up with whether you pass or fail.

This surfaces every month or every week, how the hiring process is broken… And I’m gonna challenge those people who say the hiring process is broken — talk with people in other industries, any industry, and you’ll see there’s two types of hiring processes. There’s the engineering hiring process, let’s say mechanical engineers, chemical engineers, which is pedigree-based. “Do you have a degree?” and “Where have you worked before?” and the actual interview itself is not that much. But it works great. It does lock out people who don’t have that pedigree… And it works because there’s not an increased demand; it’s kind of a stable supply, and it runs from like people start their internships at university etc.

And then there’s the other type of jobs, which are let’s say marketing, sales, some other white-collar jobs, which is completely subjective. You just show up and there’s no documentation on how to pass the interview, because it’s just completely dependent on the whims of the people who are there.

So this is the part where I think it’s good to bring some hiring managers, by the way, ask about this… Because it’s super-easy to complain about when you’re not on the outside; but once you’re on the inside — a founder, a hiring manager — you start to see that you’re kind of stuck. There’s physics involved. It’s a bit like, you know, we’re complaining “Why do airplanes only go with 700 miles an hour?” or something, and you realize after a while, when you look into it, that there’s the sound barrier, and if you break that, there’s this big explosion that can wreck all the windows…
— Pragmatic Engineer, emphasis mine

I imagine that if I were to have an imaginary argument with Orosz, it would go something like this:

Me: The hiring process is broken. Instead of providing simple coding tests to assess basic competency and interview questions that are more specialized, you ask a bunch of arbitrary nonsense we never use
Imaginary Orosz: Fine. What do you propose we do instead?
Me: Ask coding questions that are actually relevant. Front-end developer? Have them demonstrate that they know how to use an endpoint. Backend? Work on an actual API
Imaginary Orosz: It’s a trade-off. Personally, I think the solution is to relax hiring requirements, but put everyone on a kind of “trial period.” See how they perform in three months, and see if they are a bad fit
Imaginary Orosz: What?
Me: I don’t like that idea, either!
Imaginary Orosz: You can’t have your cake and eat it, too
Me: I’ll just buy two cakes

I wanted to dedicate an entire blog post to this, but not every company uses white-boarding. I have a friend who successfully received FAANG offers, and she said the studying process is like studying for the SAT. I disagree with this because every company, within reason, can more or less ask whatever they want.

Unconventional Interviews

Numerous people who read my post presumed, with reasonable justification, that I was just starting out in the field. That is not true. In my career I have received or been told I would receive a total of three offers, one of which was very strange (I will get to that in a second), two of which I declined before they could move further, and one of which I accepted. I still work there today.

In my particular software industry, and at my particular company site, not everyone uses “white-boarding.” Instead, my interview consisted of behavioral and technical questions. Interviewers were free to ask questions about coding or about design, and some of them did choose to ask conventional coding questions like determining if a linkedlist had a cycle, but the majority used panel discussions that gave more senior engineers opportunities to ask candidates technical questions. I know we are not alone in this, since another company in the same industry used a similar format. They had a panel of maybe six senior engineers bombard me, the candidate, with technical questions.

The weirdest interviewer I ever had insisted on doing the entire thing via text message. At the end they had me wait for three hours while they “processed,” then they told me I was now part of the team. I looked into them, and I do not think it was a scam company…but that was my most bizarre experience.

There is not a better system…?

Joshua Fluke proposed that we take software engineer candidates and have them compete in a series of college games. What they do not know up front is that anyone who loses a challenge will be killed on the spot. Eventually, candidates will fight to the death.

When I realized the article was getting popular, I showed it to a coworker I call “Smack” (he always finds his way into this blog somehow). Smack said he would have been much more interested in WHY companies use whiteboard-style interviews, not my specific experiences interviewing.

Pragmatic Engineer’s take is that these are a “cookie-cutter approach.” Top tech companies did it, and the rest followed suit.

Now, tech is in-between these, because I think the interviews are very well documented, you know what to expect… It’s stressful, that’s true, but you don’t need a pedigree, you don’t need a degree from MIT… I mean, if you have it, it probably helps a little bit, but not by that much, because they’ll still put you through the same process… And you know what to expect.

So actually, when we’re complaining about this, whenever we suggest how to fix the interview, the two ways to fix it is first of all some people say “Hey, I’m a senior engineer, I did all this stuff… I shouldn’t have to do this text.” “Sure. Let’s hire you, because we know your buddy. They tell you are good”, which means you’re hiring based on references, which means the other person who has the same background, but you don’t know them, or they don’t have open source contributions — you won’t hire them, and your process is now more biased. So actually, this is one of the reasons why all the large tech companies have the same process. It’s like a cookie-cutter, it’s documented, you can prepare for it, because it’s the same for everyone.
— Pragmatic Engineer, emphasis mine

Another coworker, who wished to be featured anonymous in this blog as “Dick Wheels” (yes. Really. That really is close to his real name), had this to say about challenges:

“I think it’s tricky because you don’t actually know a person’s background, and you want to get a good feel for how they work out problems. Experience is great to have, but if you don’t ask questions and continue to swirl on a problem without getting anywhere, a top tier programmer who hacks their way through a coding problem can produce just as poor material as a newbie that’s afraid to ask questions. On the flip side, if you have a newbie that’s passionate about what they’re doing and asks a lot of questions to figure out what actually needs to be done can be as effective as a senior engineer who’s working on a lot of projects and knows the ins and outs of the system”
— Dick Wheels

It is hard to deny that the way to prepare for coding interviews is…well…by preparing for coding interviews. Gayle McDowell lamented that two intelligent candidates failed because they turned to algorithms textbooks. Today we have her book Cracking the Coding Interview, we have Leetcode, and we have requesting $60 a month for interview preparation access while well-intentioned people at FreeCodeCamp attempt to build out free alternatives. The market is competitive because the competitors are intelligent, and because the software industry consists of people who want to provide easy access to education. This is neither good nor bad…but then again, yes it is bad, instead of making candidates do this we should just scan their brains and look into the future.


I had an automated coding test with a new platform. Two of the tests were typical (albeit easy) coding challenges. The third asked me to write an email. I could see an error message they ran into with their database. I was welcome to use Stackoverflow or anything else I would like.

The idea was great, and I passed the test, which I feel empowers me to complain about it. The coding questions were not good. Simply put, they had me work with vectors and a series of requirements, but their requirements did not match the data structures at all. It was essentially a bunch of typos, like asking a candidate to work with a list of names and then having a list of different names in your problem description.

One day, maybe someone will figure this out and disrupt coding interviews. This platform definitely seemed like a step in the right direction, but the implementation seemed unfinished.

I had a company ask me the “mislabeled apples and oranges riddle.”

I had a company ask me if I would leave them in the event I received an offer at Google.

I had a company ask me what 2 to the power of 32 was.

The fact that a company can ask you just about anything, within reason, is both the best and worst thing about the process. At best, maybe you can find a place where your relevant skill set really shines through. At worst, there is no universal standard and no surefire way to prepare.

There is a lot of wisdom in this podcast episode

I had seen this before, but did not know they had recorded an entire podcast episode related to it.

Admittedly, the majority of this ChangeLog interview was about a different topic, and I found it a lot more interesting than the interviewing topic. They were discussing product features, and how engineers are incentivized to build from the ground up instead of improving on existing products. Why are there so many Google chat apps? The answer is more nuanced, but they argue that it is because engineers receive more recognition for creation than upgrades.

They spent the majority of the episode talking about how hot the tech market is right now — they believe it is historic.

Closing Thoughts

The Pragmatic Engineer provides perspective on the original question. As a knowledgable hiring manager, he had firsthand experience of the process and observed the tradeoff between a smoother interview for the candidates and a less labor-intensive screening process for the interviewers.

Even though he essentially disagreed with me, I was still honored Gergely Orosz shared his thoughts on something I wrote.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store