Thoughts On Software Engineer Job Interviews

If you are looking for a coherent post, keep looking — this is 100% rambling

Curt Corginia
5 min readJul 21, 2023

Once again, for the sake of sparing embarrassment I will not reveal when this interview took place — whether it was a week ago, a year ago, or ten years ago. This was my most recent software engineer interview, and there is a twist: I got it. I got an offer. I also did not take it, for reasons I would prefer not to go into (they include some things I learned in the interview itself about what the project was), but the experience taught me a few things:

  • Some large companies are willing to hire after just one technical interview
  • Some large companies are willing to hire without requiring a single coding test
  • Soft skills are important, as is the ability to simply have a conversation. Maybe this is more like a test, but you can benefit from making it seem more like a conversation

This last one was from Smack , who heard the story. His belief, which I disagree with, is that everything can boil down to a behavioral interview. Coding interviews can be exaggerated through “confident delivery.” Technical achievements can be exaggerated. Another coworker gave this advice: Throw away your interview books and purchase a joke book instead. If you can make your interviewer laugh twice, you get the job. If they do not laugh because they are too serious and uptight, then you do not want to work for them anyway.

I only made mine laugh once and got an offer anyway, so there.

A typical software engineer “circuit,” in my experience, consists of an initial phone screen with HR, followed by a coding test very similar to LeetCode, followed by a system design interview, followed by a behavioral interview. Then you have to do everything all over again in a three-and-a-half hour final interview.

What begins as yet another parody of the onerous software engineer interview process quickly escalates into an entire Succession-inspired pilot episode about a startup CEO secretly running an obvious Ponzi Scheme and revealing his entire plan to the new hire

This one was basically a 45-minute conversation in which we talked about, among other things:

  • The actual job description and what they were looking for
  • My proudest technical achievement
  • Web frameworks and microservices

For full context, I have to admit that I thought I failed within the first few minutes. Perhaps because of this, I had something that was more like a casual conversation for the remainder of the interview.

How Confidence Can Help In Any Interview

For a long time, I dismissed people from other fields who gave me advice on interviewing. How could they know? The had not seen what I had seen. The nested for loops. The 2D arrays. They had not watched as their dream jobs disappeared within those endless labyrinths, the places we had pursued into that darkness.

Interviewer: What do you sacrifice?
Interviewee: Love. Family. 9–5. I’ve given up all chance at inner peace. I’ve made my mind a sunless space and shared my dreams with computers. My anger, my ego, my unwillingness to go outside, my eagerness to do LeetCode instead of making friends, they’ve set me on a path from which there is no escape. I yearned to get that dream job without contemplating the cost and by the time I looked down there was no longer any ground beneath my feet. What is my sacrifice? I burn my sanity and my happiness and my freedom for a position that will no longer exist by the time the interviews are over.
— Definitely not ripped off from Andor

…but actually, confidence and calm could have helped me in my worst interviews. Let me think back to the top three.

My third worst interview, in a now-infamous story that has been ridiculed so much that it has almost achieved meme-worthiness, is when I tried to solve the string compression problem with a hashmap.

Why did I do this? I had not thought the problem through and only wanted to start coding as soon as possible. This was a test, and what kind of student wastes valuable time on a test?

In my second worst interview, I thought I would have a choice of programming language, but the interviewer told me it would have to be in Java. I will never know exactly what his side of the story was, but what I do know is that nothing went well. I asked if I could use C++, and the interviewer said the question made him very concerned. I started to write Java and asked how large of an input this would have to process, and the interviewer said it did not matter. I asked how efficient it had to be, and he said it did not matter. Confidence may have helped me get out of this funk.

If you are interested, the entire story is here:

My worst interview has actually never been blogged about here — it was with a startup that has about 300 employees and 100 million users. The interviewer was perfectly polite, and he asked me a coding problem to find the three most popular videos where popularity was determined by unique user ID. Confidence was definitely a factor here as well, though the other takeaway was directly tied to hashmaps. It seemed like a perfect use case for a hashmap, but using a hashmap requires at least a basic understanding of key/value (as in, if you are going to use a hashmap, specify what you are using as a key and what you are using as a value), and the ability to do basic hashmap operations in your programming language. I don’t think I had to know the internals of how a hashmap works under the hood — like how it deals with collisions, for example — though this knowledge would have helped.

Then I explained it to a friend, who explained in detail how he would solve the problem. He readily admitted that he would not be able to code it in an interview — he had not interviewed in a while, after all — but without writing any code, his ability to articulate a solution seemed so much better than the performance I gave. All I did was continue to code while digging myself further and further into a hole. He seemed confident, enthusiastic, and knowledgeable, and I imagine he would have been open to discussion.


“What is your proudest technical achievement?” is, in my opinion, a good interview question. A candidate can say virtually anything, and a technical interviewer can drill down into specifics to assess areas of expertise. It is also a question I anticipated.

I had a story prepared. It had characters. It had conflict. It even had a joke sprinkled in. I think the story could have gone over well, had it been field tested on more interviewers. The problem is that the story was about data serialization, and the interviewer had just established that he was interested in frontend web development. I had much more luck conversing with him about frontend web development.

Closing Thoughts

I’ve said it before, and I’ll say it again: Companies can ask virtually anything. They can hire after one interview or seven, and everything from soft skills to very specific certifications can matter tremendously to different people.

I imagine the blog will quickly transition back to its usual format, but this anecdote made for an interesting change of pace.



Curt Corginia

Founder, CEO, CTO, COO, and janitor at a company I made up called CORGICorporation