Software Engineer Interviews: A Check-In
What better way to spend a morning than with four straight hours of interviews?
One thing you may have noticed about this blog, besides switching from weekly posts to bi-weekly posts, is that the last few things I have written have been a little more…questioning. Are coding interviews justified? Why do we do coding interviews?
As for the bi-weekly thing, please bear with me. I now have three Medium accounts I maintain, and by community standards I never use duplicate content. I call it the “Corginia Trinity,” and I hope it does not collapse.
I think the comment above, left on my CodeSignal post, embodies the attitude of most people in our field. I recently had a conversation with Smack, and we came up (well, I came up with these terms. He nodded along) with two terms. One, which I called AR, is ARbitrary bull****…it stands for the things you need in software engineer interviews that have nothing to do with the actual job, like rotating a matrix. On the other hand, we have US, or Useful S***. These are things you may be asked about in a software engineer interview that are completely fair and relevant, like dynamic_cast if you are a C++ developer, or frontend trivia if you are a frontend developer.
Some of the interviews I have had measure fairly highly in the US area:
- I had an interview where they gave me a CSS file, an HTML file, and a JavaScript file. They then asked me to add a feature
- I had an interview where they talked to a system from a high level, showed me code, and asked me to explain what the code was doing to them
- I had my first system design interview ever, and it went about as well as you would expect
Anyway, the happiness from that CodeSignal post was short-lived. After passing with a low 700 score, I went onto a final round four-hour interview in four separate parts— the feedback was negative all around. I think the coding solution was close, but they may not have thought so — it was a variation of TwoSum (twosum closest to zero) , so I used a sort and the Two-Pointer Technique, but had a bug in the solution so that it got the correct answer, but proceeded. Their feedback said: We gave him hints on the optimal solution, and even after the hints he still could not get the correct solution. This should probably be another post, so we can fully work through the problem and determine whether or not it was actually as close as I thought it was.
The system design interview did not go well, but that was more fair. That could also be its own post, but among other things they wanted to have an IoT device interface with a database. To say that is not really something I do in my day-to-day is not a valid excuse. Had difficulty explaining technical things and articulating high-level components. Would take a long time for him to ramp up to be successful here.
Another interview was walking through code, and that one was a little more puzzling to me. Did not go at the pace we were expecting, and I had to provide more help than I typically do. What is it they wanted? It was code that found the five most recent points and saved it to a kind of imaginary database. Then they had me walk through sample test cases. Did they want me to write more and explain less? It is possible, but first they clarified that they really wanted me to explain everything and go through my thought process.
That could…also be another post.
By the way, the answers were on Glassdoor. Just wanted to throw that out there…a friend suggested I just study the questions on Glassdoor, but I did not believe they would just ask the exact questions on Glassdoor.
“If Software Engineering is in demand, why is it so hard to get a job?”
I wanted to revisit the structure of this post, which to this day still gets the majority of the blog’s traffic and is also the sole reason I have 500+ followers. Apparently the article or title really resonated with people, and continues to.
But is that a good thing, or a bad thing? Maybe time could be better spent checking out this guide, which was updated in 2022, or the non paywall-blocked BaseCS, or the very active Interview Resource that I have not contributed to in a while.
Step 1: Remember to Breathe
On average, software engineer jobs pay fairly well. Many would argue that they are also difficult jobs, and a lot of people are willing to compete for positions. All of these forces combine to make for a competitive situation, but the market has been fairly hot lately.
Pragmatic Engineer says to treat interviews as a learning opportunity. You can pay more than $100 to have a professional evaluate you, or you can apply for a job and get feedback for free.
The sad part is you may not get feedback, period, but that could be a rant for another day.
The Process Revisited
I joined a FreeCodeCamp group. Admittedly, I have not much for them (yet), but they stood as a good reminder of what I think programming should be like: They talk tech, they build things, and they enjoy doing it. Instead of framing your journey with, “When I get that dream software job, I will be happy,” it short-circuits to “I am doing software engineering right now, and because of that I am happy.”
Some of them were relatively new, and they seemed very interested in the job search process. You can seek out third-party recruiters, but I personally have a low opinion of them. You can follow this guy’s advice and use LinkedIn strategically, but I admit I have never done this myself. I follow the “shotgun method”: I just kind of spam indeed.com. I would say this strategy is not great, but also not terrible.
You can apply through friends. I admit that I have almost never done that. You can try other sites, like AngelList and ZipRecruiter. I also hear there is something called The Hidden Job Market, but I have never leveraged it myself and I hear you need to mine ten obsidian to teleport there.
The Initial Phone Screen
I think this can be the least fun thing to prepare for, which is a little bit ironic. Here, you get to prepare by actually researching a company and seeing if you think you are a good fit. Typically the interview is with HR, and they will just ask behavioral things or some formulaic questions about citizenship. They may also ask about tech that is not listed on your resume, to see if you have other experiences not listed.
While I can understand why initial phone screens are necessary, I also think they feel unnecessary…unlike technical interviews, they kind of just seem like a streamlined way to avoid manually filling out some form, or sending two or three emails back and forth.
The Technical Interview
Coding interviews are basically the theme of this entire blog. CORGICorporation, in case you were not aware, is a parody company…but if it were real, I would have loved to give this speech:
At CORGICorporation, we assign coding tests but do not care whether or not you finish. We want to see your problem-solving ability. If all we cared about was whether you finished and produced the correct results, our process would only hire people who had the time to memorize LeetCode answers. I care a lot more if you can work through a problem logically and have coding fluency than if you just produce code that gets exactly the right answer.
They can ask you virtually anything in a technical interview, though. Maybe if you say you are a Java expert, they have every right to ask you about the diamond problem.
The Behavioral Interview
Anything goes. Seriously.
If I were a real CEO, I would ask everyone about corgis.
Strengths and weaknesses. Biggest challenges. Most interesting technical solution. This is the kind of thing lots of blogs anticipate a job interview should be like, but in our world there are also LeetCode things, and diamond problem things, and system design things.
System Design
Smack calls this almost 100% US, or useful s***. System design is really important, and though it seems kind of hand-wavey compared to algorithm/LeetCode tests, where “the code runs and speaks for you,” the structure seems more fair. Yes, there are a million correct ways to solve a system design problem…but there are a billion incorrect ways to fail it. You can draw out a design that makes absolutely no sense.
I am going to link this guy, who is really a gem, but I am way too inexperienced in system design interviews to provide more than that.
