Twelve questions to ask at tech interviews


I’ve just come off six weeks’ of interviewing for medior software developer roles, in a market that is desperate for talent (Amsterdam). That means I went on a lot of interviews. In order to tease out which companies might be right for me, I wanted to ask many questions. You’ll have to find the right balance for you and the person(s) interviewing you.

If you’re job-hunting as a junior, you may find that you don’t actually care about the answers to any of these — you just want a job. Even if that’s the case, consider what would be a red flag for you and ask questions that will tease that information out of your interviewers. If there’s a deal-breaker, you want to know about it before you accept a job offer.

The typical process

Based on my experience, here’s how the process of interviewing generally goes:

  1. Screening call / potentially on-site interview. Typically done by someone in HR. If done by someone technical, it’s normally quite short (not a good time to fire all your questions).
  2. Technical interview. You’ll have another round of interviews with actual developers and they’ll dig into your knowledge.
  3. Technical assessment / homework / pair programming. Huge bonus points for companies doing pair programming, in my opinion. I understand why they assign homework, but for the most part it’s a waste of everyone’s time and does not assess the right skills.
  4. Final interview, meeting the rest of the team. Sometimes this interview is replaced with meeting the founder(s), if it’s a small company.
  5. Offer.

Naturally, this all differs quite a bit per company, but it’s a general outline for what you might expect during the hiring process.

Questions for your screener

It’s very common to have someone non-technical do the first interview. It’s not appropriate to ask them stack questions, because they often have no idea what you’re talking about — even in small companies.

Most of this call should be you talking about you. They already have your CV, but they’ll expect an introduction — make sure you have a good and concise story to tell about your work history. You’ll be repeating this story ad nauseum while interviewing.

What is the hiring process?

It’s likely they’ll go through this with you anyway, but if they don’t, be sure to find out what all the specific steps are with this company. If you’re just testing the waters here and they expect you to build a complete app next, it’s probably best to move along.

Tell me a little about the tech team.

How many members, makeup junior vs. senior, and any hierarchies (is there a CTO? Product owner?) should be easy for the HR person to explain. If not, particularly at large companies, that’s fine too.

Make sure you know the next step before you get off the phone with your screener.

Questions for the technical interview

Here’s where the bulk of my questions come out. They’re assessing you, but you’re also assessing them. Let your interviewers drive the conversation, but it’s fine to jump in with a question or two along the way. At the end of the meeting, they should ask if you have any questions and you can ask as many of these as feels right for the moment.

If you don’t care about the answer to a question, don’t ask it. There’s no point in wasting everyone’s time talking about a thing unless it will help you decide whether or not to work there.

I put these in order of relevance to me. If we’re having a nice chat, I probably don’t get to the ones at the end. If it’s a little painful and hard to talk to my interviewer, I might get to ask all of them, and hope that I have better rapport with the rest of the team.

Who is your ideal candidate for this role?

I really like this question because it gives you a better idea of what is expected of you, by framing it in a new way. If your interviewer(s) could create a person out of thin air to fill this role, who would that person be? Sometimes they will describe you to a T and other times you’ll hear a lot that doesn’t align with your background / skills / preferences. It’s a good way to see if you’d be a good fit at the company.

For instance, one company said they wanted someone who “doesn’t need a lot of help”. To me, that’s a red flag. Anyone coming into a new code base needs help to understand the business logic, even if they’re experts in the tech the code is built on. Developers who are hostile to a learning environment are a big turn-off for me.

On the other hand, I frequently heard that their ideal candidate would work “independently” and be “self-motivated”. These are great signs for me, as I see myself as both of them and don’t want a lot of nit-picking and forced structure in my own work. The two answers might mean exactly the same thing, but how they’re framed makes a big difference for your work environment.

What are the biggest challenges for this role?

The answer to this questions depends very much on what you’ll be doing. In all cases, it’s a great way to see behind some of the sunny information you’ll get from the rest of your chat. Pay close attention to what they think will be difficult in this role, and evaluate if you’re the right person to meet those challenges.

Who sets the vision for this company?

I’m looking here for the long-term plan, and hopefully to talk some about goals for growth. The only answer that strikes me as a red flag is if they don’t know how to answer the question. “The founder” seems like a fine answer for me for a small company, and “the board” and “management” as you get into larger companies. Major bonuses if everyone feels that they have input into creating a larger vision and roadmap. Blank stares would be bad here — you want to work at a company that knows where it’s going.

How do you measure the success of the development team / individuals / the company?

Again, a process question. I want to know how my work and my team’s work will be evaluated. If they have trouble with this one, I switch it around and ask how they know if they’ve done a bad job. In my opinion, if there’s no way to know if you’ve done well, but they’re clear about what “messing up” looks like, that’s a red flag. How can you be successful at your job if you don’t know what being successful looks like?

What is the most enjoyable / frustrating thing about working here?

This question is great to re-use on multiple people. Ask it as two questions, back-to-back (I prefer asking the positive one first). You’ll often see patterns come up — everyone is annoyed about the same things. Getting people to talk about a negative is always hard in interviews, but I find this one is difficult for people to side-step.

They probably won’t tell you the big systemic problems of the company (they might) but at least you’ll get a feel for some of the process / personality / bureaucracy challenges of working there

Describe the code review process.

The answer to this one tends to be fairly short — they do PRs, a colleague reviews on GitHub / wherever. Dig a little further to find out what kinds of reviews, the average time to merge after submission, etc. Are they going to be super nit-picky about everything? Let massive errors through? Do they actually care or are they just showing off their own knowledge? What about testing? How often do they release?

How does an idea go from “out in the world” into the backlog and finally to code and production — walk me through your feature development process.

I want to know where new ideas come from. Are they looking at the data and then building based on an informed worldview? Or does the founder get an idea and then everyone jumps to meet his expectations?

This question is a lot like the “vision” one, and can be asked as a follow-up. Once you have the vision, how does an actual feature get described and then coded? I consider this the closest to “what is it like to work here?” without needing to ask in those words and get a trite answer.

Explain a technical challenge you’ve recently faced.

If they struggle with the question above, this one should be easier — I’m asking for a concrete example of recent work they’ve done. Was there collaboration among team members or did one person just figure it out themselves? Were external resources brought in? Was the feature dropped? Again, this question is good for getting an idea of the day-to-day operations.

Bonus: What are the plans for onboarding new hires? How do you incorporate new developers into the team?

I consider this one fairly low-priority unless you are junior. Juniors should be looking for significant plans for onboarding and even training. Mediors and seniors can ask this question to see if they have an answer. I’d like to know that they have considered what it is like for new developers to start. Have they thought about how to make the transition into the company easier? It’s not necessarily a deal-breaker if they haven’t — because lots of companies have not.

Related, I like to ask if they hire juniors and how they work with them, but only if we are already solid that I am not a junior. I’m nearly three years into my career, but I don’t want to give anyone ideas. More senior engineers could ask this without fear of being mistaken for a junior, and get good information about how employees are valued.

Questions for the final interview

In this last interview, you might already be talking salaries and start dates. If they make you an offer, get really clear on what is on the table — bonuses, pension, equity, vacation days, starting date, etc.

Here’s a question you might consider asking but need to tread lightly and read the room:

Are there any internal politics I need to watch out for?

In a bigger company, they can put this on “sales” and let you know that they are the gods around here and not to piss them off. In a smaller company, they are liable to tell you there are no problems. What you’re going for is some first-day-on-the-job knowledge — who actually calls the shots? Is there a project on the table that some people think is not worth doing but others love? If they’re willing to give up a little dirt here, it can help you in your first weeks. It also shows that you care about fitting into the company and properly negotiating all the personalities floating around.

Final notes

All of these questions can lead into some great discussions. Don’t feel like you need to jump into each one. Start with the most important or most informative ones and go from there. It’s much better to have a back-and-forth than fire off each question.

In my assessment of a company, I’m trying to find out would I enjoy working here? and would they want me as a colleague / employee? Whatever conversation we can have that leads me closer to an answer to either of those questions is best. These prompts are just helpers to get there.

Good luck in your job search!