What’s the worst thing about looking for a job in software engineering? In my opinion, that would be the technical interview.

It’s easy enough to talk about projects you’ve worked on or how you would be a good addition to the company, but it’s another thing to be able to show off coding skills on the spot, especially for a junior engineer.

I’ve completed (completed may be a strong word) several technical interviews. Each one a little different than the last. The worst was for a gaming company in town. I had twenty minutes to code, using C++, a problem they gave me. While normally this would be no big deal, my heart started racing when I knew I only had the 20 minutes AND two people on the zoom call were watching my every keystroke. That was horrible. Let’s just say, I did not hear back after that.

Other technical interviews are a little less stress based. I applied for a job at Amazon and went through multiple rounds of technical interviews. These were all timed as well, but didn’t have somebody watching me. It also consisted of multiple smaller exercises, and they mainly wanted to see what thoughts I could apply to these problems, if I didn’t finish it. I did well, was invited to do some in-person interviews, but ended up not pursuing any further after that because of a different job opportunity.

I think my favorite (favorite, yet again perhaps a strong word) technical interview was for my current company. There was no coding specifically, the hiring manager even mentioned that he can look at my portfolio to figure out my coding ability. We talked concepts. The manger provided different scenarios that fictional users may encounter. He wanted to see how I approached it from a high-level view. For example, one scenario was a new parking garage keeping track of cars that come in and go. The prompt was specifically vague, in order to see where I’d go with it. They’re looking to see if people create user stories, ask for more details, see prompt for what needs to be fixed, find out what external pressures there are, etc. The idea was to see how I would handle a new project and if I could ask the right questions while setting up something that the user actually wants, not just what the user says they want.

I liked this idea a lot more than the usual “here’s a problem, code it to make it work”. I think giving a more high-level view of a problem and seeing how somebody would handle it is more of an insight to a candidate than seeing if they can make a small problem work under pressure.

Let’s just say, I’m happy to be working for that hiring manager now. He clearly appreciates different views that his team members bring to the table. It creates an interestingly diverse team all working towards the same goal.