Questions You Should Ask Them

Most people treat this moment as a formality. They say "No, I think you covered everything" and shake hands. That is a lost chance. The interviewer has spent 45 minutes judging you. Now you get 5 to 10 minutes to judge them, and the quality of your questions is one more thing they judge.

This lesson gives you a short list of questions for each person you will meet (an engineer, a hiring manager, a recruiter), what a good and a bad answer sounds like, a list of red flags, a one-hour method to evaluate a team, and a worksheet you can print. The earlier lessons covered how behavioral interviews work and the hardest stories. After this one we go to salary and offers.

Words used in this lesson

• Signal is a piece of evidence that tells the interviewer (or you) something real about the other side.
• Red flag is a warning sign. One red flag is a question. Three red flags is a pattern.
• Hiring manager is the person you would report to. They decide who joins their team.
• Recruiter is the person who runs the process: schedules, explains the steps, talks about money.
• On-call means being the person who gets paged when production breaks, usually in a rotation.
• Roadmap is the plan for what the team will build in the next months.
• Attrition (or turnover) is how many people leave the team in a year.
• Onboarding is how a new person is taught the code, the tools and the people in the first weeks.
• Skip-level is the manager of your manager.
• Runway is how long a company can pay its bills with the money it has, before it needs more.

Why your questions are scored

The handbook's behavioral pages say companies check motivation, being proactive, growth and communication, among other focus areas. Look at your own questions through that lens:

• A question about the work ("what does the team find hardest right now?") shows motivation and ownership.
• A question about how decisions are made shows you can work in an unclear environment.
• A question about how people grow shows growth.
• A question that is clear and short shows communication.

Now think about what "no questions" shows: low interest. And a question that you could answer yourself in 30 seconds on the company website ("what does your company do?") shows low preparation.

There is a second, more important reason. You are going to spend maybe 2,000 hours a year with these people. The interview is the only time you can ask them direct questions before you sign. Treat it as due diligence.

The three goals of your questions

Every question you ask should do at least one of these:

1. Learn the real job. What will I do on day 1, month 3, month 12?
2. Learn the real team. How do they work, argue, ship, and treat each other?
3. Show how you think. The way you ask tells them what kind of colleague you are.

Before each interview, write down which of the three you most need. If the job description is vague, goal 1 matters most. If you are a junior, goal 2 (will I get help?) matters a lot. If you are senior, goal 3 and the decision-making questions matter more.

How many questions, and when

A simple rule: prepare 8, ask 3 to 5. You will not have time for all. The interviewer may also answer some during the talk. Cross those out, and never ask what was already answered. If you ask a question that they answered ten minutes ago it shows you were not listening.

Write the questions in a notebook, not only in your head. Writing in a notebook during the interview is normal. It also shows that you take it seriously. If the call is video, say "I wrote a few questions, I hope that's okay" and look at the notes.

Questions for the engineer (a future teammate)

The engineer interviews you for technical skill, but they are also the best source of truth about daily life. They have no reason to oversell, and they will be honest if you ask in a friendly way. Ask about their experience, not about the company.

1. "What did you work on last week?" Why it works: it gets a real story, not a slogan. Good answer: a specific task, a real problem ("we were debugging a slow report query"). Weak answer: vague ("various things", "meetings, mostly").

2. "Tell me about the last time something broke in production. What happened?" Why: it shows blame culture or learning culture. Good answer: a short story, a fix, and what changed after. A very good answer includes "we wrote it up and changed our alerts". Weak answer: "a junior did it" or "we don't talk about it".

3. "How does a change get from your laptop to users? How long does it take?" Why: it shows the delivery process. Good answer: "pull request, a review within a day, automated tests, deploy by a button". Weak: "it takes two weeks and a manual checklist".

4. "What would you change about the codebase if you had a free week?" Why: honest engineers answer this with real pain. An engineer who says "nothing, it's perfect" is either new, careful, or not honest. Good answer is a specific, fixable thing, such as "our tests take 40 minutes".

5. "How do you decide what to work on next? Who can say no?" Why: it shows if engineers have a voice or just take orders.

6. "How often do you work outside normal hours?" Why: a direct and fair question. Ask it politely. Good answer: "rarely, and when we do we take the time back". Be careful about an answer that comes with a laugh and a pause.

7. "What made you join, and what keeps you here?" Why: personal and hard to fake. Listen to the pause and the tone, not only the words.

8. "If you could pick one thing a new person on this team should learn in the first month, what would it be?" Why: it shows onboarding and what the team values. It also helps you prepare.

A real conversation (made-up) so you can hear the rhythm

Here is how a good exchange sounds. The interviewer is called Mara and the candidate is you. Both are fictional.

What did the candidate do right? Three questions only. Each one followed something already said in the interview ("you said...", "I noticed..."). The last question set up the later conversation about success. And the candidate thanked her for being direct, which encourages honesty.

Questions for the hiring manager

The hiring manager is the one person who can change your daily life the most. A common saying is that people leave managers more than companies. I did not check a source for that saying, so treat it as common experience, not proven fact. Even so, it is wise to spend your best questions here.

1. "What does success look like in this role at 3, 6 and 12 months?" A strong manager has a concrete answer with outcomes. A weak one says "just get up to speed" with nothing more. If they cannot say what success looks like, they will not be able to judge you fairly later.

2. "Why is this role open?" There are only a few answers: growth (good), replacement (ask why the person left), or a new problem (ask more). If they say "we lost two people this year" follow with: "What do you think led to that?"

3. "How do you give feedback, and how often do we meet one on one?" Good: weekly or every two weeks, written notes, feedback that is small and often. Weak: "we do a review once a year". Our team lead lesson on 1:1s explains what a good one looks like from the manager's side, and you can use it as a checklist.

4. "Tell me about someone who grew a lot on your team. What did you do to help?" Shows if the manager develops people. A good answer names a person (no last names needed) and an action: "I gave her ownership of the billing project and reviewed her design doc."

5. "What is the hardest thing about managing this team?" A rare question and a strong one. Honest managers answer truthfully: "priorities change too fast" or "we have too much to do for six people". A manager who says "nothing, they are great" is hiding something or has not thought about it.

6. "How do you handle disagreement, for example when an engineer thinks a deadline is unrealistic?" You learn how pressure works. Good: "we talk about what to cut". Weak: "we find a way".

7. "What is the team's biggest risk this year?" It shows you think about the business. It also tells you if the team might be cut, merged, or moved.

8. "How does this team connect to the company's goals, and who decides priorities?" For a team lead on senior roles, see also Stakeholders, Meetings and Change to hear how a good lead explains the "why".

Questions for the recruiter

The recruiter is not technical, and they are the best person to ask about process and money. They also report back on how you behaved, so be warm and brief.

Ask these early, not after the final round:

• "What are the steps, and how long does each take?"
• "Who will I meet in each round, and what is each round for?"
• "Is there anything I should prepare?" (Many recruiters will tell you the format: coding, system design, behavioral.)
• "When do you expect to make a decision after the last round?"
• "Is the salary range for this role set? Can you share it?" (Lesson 6 explains this, and in some places the law requires them to share a range. Check your local rules.)
• "Is the role remote, hybrid or in the office? Is that written in the job post, or can it change?"
• "Who do I contact if I need to reschedule?"

A good recruiter answers clearly and gives you dates. A weak process shows up here as well: "we will get back to you" with no date, or the recruiter changing every week.

Questions for a skip-level or a product partner

Sometimes the last round is with a director, a product manager or a designer. These people see the bigger picture, so ask bigger questions:

• "What is the most important thing the company needs to get right this year?"
• "How do engineering and product decide together what to build? Can you give me an example where engineering changed the plan?"
• "What did the company stop doing in the last year? Why?" (Shows if they can say no.)
• "How is the team's work measured?" (Shows if the metric is customer value or just output, like number of tickets closed.)

For seniors it is also fair to ask about money and runway if it is a small company: "Is the company profitable or funded? When is the next funding round or milestone?" Be polite. Many founders will answer, because they expect a senior to ask.

Questions about remote and hybrid work

If the job is remote or hybrid, ask about the habits that make it work. The 37signals public handbook (which I read) describes one way to do it: people post what they worked on every afternoon, post a plan every Monday, and most requests are written down and answered later instead of in a live call. It is one company's way, not a rule for everyone. But it shows the kind of detail you can ask for:

• "How does the team communicate day to day: chat, documents, meetings?"
• "Which hours are everyone online at the same time? How many time zones are on the team?"
• "How do you make decisions: in writing, or in meetings?"
• "How do new people get to know the team when no one is in an office?"
• "Is there a travel or meet-up budget?"

Lesson 7 goes deep on remote work. Here the goal is only to learn how real the remote culture is.

Red flags: what to listen for

A red flag is not proof. It is a reason to ask one more question. Here is a table I use.

And the other side of the coin, green flags: people who explain things in plain words, who admit what is hard, who listen to your answers, who describe their own mistakes, who give you dates, and who answer your questions without defensive tone.

How to evaluate a team in one hour

Before accepting an offer you can do a short "due diligence". It takes about an hour in total. Here is the plan I follow.

10 minutes: read the public facts. Look at the company website, the engineering blog (if there is one), the job post, and their public repositories. Check: does the job post match what the interviewers described? Does the blog show real engineering topics or only marketing?

10 minutes: check people's careers. On a public professional profile, look at the team members you met. How long have they stayed? If everyone has been there under a year, ask why. If everyone has been there ten years, ask how new ideas arrive. (Be fair. Both can be fine. They are reasons to ask.)

10 minutes: check the money side. Is it a funded startup, a profitable small company, or a large listed one? Look for news about layoffs or funding. Use only reliable public reports and take rumours with care.

15 minutes: write down what you saw and heard. Fill in the worksheet below, honestly, while the memory is fresh.

15 minutes: ask for one more talk. It is acceptable and often welcome to say, after an offer: "Before I decide, could I have 20 minutes with someone on the team? I'd like to ask about day-to-day work." A good company agrees. A company that refuses may be hiding something. (It may also be too busy, so ask once politely.)

Worksheet: team scorecard

Print this or copy it to a note. Score each line from 1 (bad) to 5 (very good). Leave it blank if you do not know, and then write down the question you still need to ask.

How to read the result: add the scores that you could fill in and divide by the number you filled. An average under 3 is a warning. But a single 1 on something you cannot live with (for example, hours, or pay) can matter more than a high average. Decide your must-haves before you see the scores, and write them at the top. For example: "must-have: at least two days remote, no weekly on-call".

Questions you should not ask (yet)

Some questions are fine, but at the wrong time they give a poor impression:

• "How much holiday do I get?" as the first question to the engineer. Ask the recruiter. It is a fair question, but ask the right person.
• "How soon can I be promoted?" in the first round. Ask instead: "How do people grow here?"
• "What does the company do?" You should know this.
• "Will you check my references/background?" Ask the recruiter about the process instead.
• Negative questions about a person ("Is the manager difficult?"). Ask the neutral version: "How would your team describe your management style?"
• Questions that sound like you want to do as little as possible ("Do I need to attend meetings?"). Ask: "How are meetings used here?"

Also never ask a question just to look clever. A forced question is easy to see.

What to do after you ask

Listen to the whole answer. Don't write the next question while they speak. Say "thank you" and, when it makes sense, link their answer to your experience in one sentence: "That's similar to how my last team handled releases, and it worked well for us." This shows you can be a teammate.

At the end say a clear closing: "Thanks for your time. I'm very interested in the role. What are the next steps?" The next steps question is a simple, professional way to leave.

A follow-up email after the interview (complete script)

Send this the same day or the next morning. Keep it short. Customize the bracketed parts.

Subject: Thank you, [Role] interviewHi Mara,Thank you for the conversation today. I enjoyed hearing how your teamhandles night incidents and how you are working on the test suite.That is the kind of problem I like to work on, and it matches the workI did last year when I cut our test run from 40 to 12 minutes.I'm very interested in the role. If it helps your decision, I'm happyto send an example of a design doc I wrote for that project.Thanks again, and I look forward to hearing about the next steps.Best regards,[Your name]

Why it works: it names one real thing from the talk, connects it to your work in one sentence, offers something useful, and is under 100 words. Do not write three paragraphs, and do not write only "thanks for your time".

Try it

Exercise. Imagine this job post (made up): "Backend developer for a small team that runs an online booking service. You will work on the API, join on-call, and help improve reliability. Fully remote in one time zone."

1. Write 8 questions you would prepare: 3 for the engineer, 3 for the hiring manager, 2 for the recruiter.
2. For each question, write one line: "A good answer sounds like..." and "A weak answer sounds like...".
3. Choose the 3 you would actually ask if you only had 5 minutes with the engineer.

Sample answer.

• Engineer: (1) "Tell me about the last time the booking API had an incident. What happened afterward?" Good: a story with a fix and a change in process. Weak: "it doesn't happen much." (2) "How often are you paged, and what happens the next day?" Good: a number and time off. Weak: "it depends" with no number. (3) "What would you fix first in the codebase?" Good: one concrete thing.
• Hiring manager: (1) "What does success look like at 6 months for this role?" Good: two or three outcomes. Weak: "get up to speed". (2) "Why is the role open?" Good: growth. Weak: vague. (3) "How do you handle a deadline that the team says is not realistic?" Good: "we cut scope". Weak: "we make it work".
• Recruiter: (1) "What are the next steps and timeline?" (2) "Is the salary range set, and what is the remote policy in writing?"
• Five minutes with the engineer, I would pick: incident story, on-call load, and what they'd fix first. These three show reliability culture, hours and honesty, which are the main parts of the post.

Interview questions

Key takeaways

• Your questions are scored, and they are also your due diligence. Prepare 8, ask 3 to 5.
• Ask each person what they know best: the engineer about daily work, the manager about success and feedback, the recruiter about process and range.
• Questions about stories ("last time something broke") give better answers than questions about values.
• A red flag is a reason to ask one more question. Three of the same kind is a pattern.
• Write your must-haves before you see any offer, and use the team scorecard to decide with a calm head.
• Send a short follow-up email the same day. Mention one real thing from the talk.

What's next

You now know what to ask them. In lesson 6 we talk about the part that makes people most nervous: salary, offers and negotiation, with real arithmetic and complete scripts. For how a good manager thinks about the same topics from the other side, see the team lead series on hiring.