5 Essential SWE Interview Questions

When I was a junior developer interviewing for my first job, I was so overwhelmed by the process that It felt more like a one-way interrogation than an actual interview. Sure, I had seen endless posts on LinkedIn assuring me that I was also interviewing them, which made sense, but without any real experience or knowledge of the industry, I didn’t know what to ask.

As your career in software progresses, you’ll see what works and what doesn’t. All of these experiences will arm you with the knowledge required to ask more meaningful questions about processes, the people you’ll be working with, and whether or not the company is a good fit overall. When you’re new to the industry, you don’t know what to ask, so I’ve made a list of 5 questions you should probably ask in interviews.

1. Who makes decisions regarding new features, and how does that decision flow down to a team?

It’s important to know who is making decisions and how that flows from the business side to development. If you’re applying to a huge organization, this may be a slightly difficult question for someone to answer, but it’s especially important to understand how these decisions are made. You want to know:

• Is engineering beholden to unrealistic business requests?
  • Is there a singular gatekeeper in the organization that makes unilateral decisions and/or silos information?
  • Do development teams have an open line of communication with architects and/or product owners?
  • Do product owners understand the epics and stories they create?

You don’t need a super-detailed explanation here- you’re just looking to see if the person interviewing you can describe the process at a high level and name all of the key players.

Why do I ask this? Because I’ve worked in a shop where there was one grey-beard who, aside from making unilateral decisions and refusing to document anything, answered all questions with ‘because I do it the right way’. Teams had zero input, and after a few months the project I was working on imploded. That’s not a recipe for success.

2. Every company has tech debt, but how do you approach it?

If anyone tells you that they don’t have technical debt, run the other way. Regardless of size or how many superhero, 10x, former FAANG tech lead, or code ninja developers a company employs, there is technical debt if they exchange money for a product. I had a senior developer at a startup tell me that they never really incurred technical debt because they hired the best. While that was likely an attempt to minimize a real problem (or arrogance in the worst case), the fact that something as serious as technical debt is minimized or obfuscated is a serious red flag that should be explored with further questioning.

Again, you’re not looking for a detailed roadmap here, just transparency and an articulable process. In the healthcare and fintech sector, I’ve found that most interviewers are pretty honest about their technical debt situation because they frequently deal with older codebases and legacy products that are sometimes slow to evolve due to regulatory compliance requirements. Startups and small companies trying to find their ‘visionary engineer’ tend to obfuscate the real technical debt situation.

3. What role does QA play within the software development process and to whom do they report?

his might not seem all too important, but coming from a QA background means that I care about what role QA plays, how they’re treated, and who their direct supervisor is. As an SDET, I was embedded with a team but reported directly to the director of engineering. This did several things, but it mostly allowed us to kick back stories or create bugs without worrying about pressure from team leads. “It’s not really broken, so we can just create a story to fix it later. Can’t you just make the test pass for now?” is something I’ve heard more than once as an SDET.

What this question does, at least for me, paints a picture of the team organization and how seriously they take QA. Most companies likely have at least one embedded tester/SDET on each team who reports to a quality director. If there is one QA person per team, it might be prudent to ask how much of their time is spent manually testing stories compared to writing automated tests. Ask about their automation plan and who is architecting their tests. Even if you’re not interviewing for a test engineer position, a mature and structured QA program speaks volumes about a company’s product.

If nothing else, you can gauge attitudes towards other teams. If you get a sense that QA isn’t well respected, it is my experience that they don’t respect interns, DBAs, tech support, or DevOps engineers either. If you get the sense that the company has an ‘us vs. them’ mindset, run away.

4. If you were given a team for a sprint and allowed to work on anything you wanted, what would you build?

It might sound meaningless, and I’ve gotten more than a few “well, that would never happen” answers, but it exposes their level of enthusiasm for both you as a candidate and their job as a whole. As a candidate, you should be showing a degree of enthusiasm (hopefully you’re applying to projects that you’re truly excited about), and that goes for the team interviewing you as well. Any question that requires thought and creativity will work, especially if it relates specifically to the product you’ll be working on.

During an interview, everyone should be at least somewhat engaged in the process. I’ve learned over the years that distraction or a sense of disinterest is usually a good indicator that the job isn’t going to work out.

5. What problem do you solve that other products in this space don’t?

If you were seeking capital to fund a product, this is likely the first question a VC would ask. Sure, you could make a poor clone of an existing product but how long are you going to survive if you’re providing the same service with a fresh coat of paint? Even worse, what if you aren’t providing the service or functionality that your competition can?

I’ve been around healthcare a long time, and believe me there are some awful, solutionist systems out there. Good health record/clinical management software is hard to do well, and I can count on both hands the number of companies that have nailed it (I’m looking at you, Epic). In fact, I got into software because while I was working part-time as an ortho tech at UF, I was convinced that I could make one of our inventory apps better. It was slow, probably from the early 2000’s, and was just general dogwater. Turns out, our supply company provided software that did the same thing a whole lot better.

If you’re going to work for a company for any length of time, you should be satisfied that your time is spent on something useful. If there’s no real articulable benefit (and “we provide a personal touch” doesn’t always cut it) you need to dig deeper. I suggest doing a few minutes of research before your interview to make a list of competitors, their functionality, and customer reviews if you can find them.

Conclusion

No matter where you are in your career journey, don’t ever forget that an interview is a mutual process of discovery. If you’re straight out of college or a boot camp the pressure to take the first thing that comes along is strong. Remember that it serves no benefit to take a job that you aren’t comfortable/and or happy with out of convenience. Find a place where you fit and can grow as a developer.

Over time, you’ll develop your own questions and methods for interviews. Just remember to be prepared, do your research, and stay positive. A good fit is out there if you’re patient.

Photo by LinkedIn Sales Solutions on Unsplash