Questions to Ask Before You Take the Engineering Job

The interview is not just them deciding about you. It is your one clear chance to find out what the job is actually like before you sign for a year or more of your life. Most candidates waste it asking soft questions that get soft answers.

Here are twelve questions worth asking. They are built to get past the pitch and reach the truth, and the best signal is often not the answer itself but how easily the answer comes.

1. What does a normal week look like for someone in this role? Not the mission, the week. How much of it is coding, meetings, on-call, review, firefighting? If the person cannot describe an ordinary week in concrete terms, they may not know what they are hiring you to do.

2. Why is this role open? Growth, backfill, or someone left. If someone left, ask, gently, why. A role that has turned over twice in two years is telling you something the job description will not.

3. How do decisions actually get made here? Who decides what to build, and how does a disagreement between engineering and product get settled? Listen for whether engineers have real say or just build the list. A place where the answer is vague is usually a place where the answer is "the loudest person wins."

4. What happens when something breaks in production at 2am? This one question reveals the on-call load, the incident culture, and whether the team blames people or fixes systems. Ask who gets paged, how often, and what happens the morning after a bad night.

5. How does code get from my laptop to production? Walk me through it. The answer tells you the real state of testing, review, and deploys. "We are working on it" is honest. A long silence means you will spend your first six months on plumbing nobody wants to talk about.

6. How much of the codebase is code you are proud of, and how much is stuff you are afraid to touch? Every codebase has both. A team that can answer this honestly has a healthy relationship with its own debt. A team that claims it is all clean is either lying or has not looked.

7. What does progression look like, and who got promoted recently? Ask for a real example. The pattern of who moved up tells you what this company actually rewards, which is often not what the career ladder document says.

8. How do you support focus time? Meeting load, interruptions, and expectations about being always available. If the honest answer is that senior engineers are in meetings most of the day, know that going in. The gap between what a company says about focus and what its calendars look like is one of the most useful things you can learn.

9. What is the hardest part of working here? Everyone has one. A person who answers with a real, specific difficulty is being straight with you. A person who says "honestly, nothing" is either new or not telling you the truth, and both are worth noticing.

10. How does the team share context across timezones or when someone is out? If the team is distributed, this is not a soft question. Ask what happens when the one person who knows something is asleep or on leave. Teams that depend on a few people being reachable at all hours are fragile, and you may become one of those people.

11. What would you want the person in this role to have accomplished in six months? A good answer is specific and reasonable. A bad answer is either a fog ("just get up to speed") or a fantasy (three quarters of work in one). This tells you whether expectations are set clearly or set to disappoint.

12. Can I talk to someone who would be my peer, without a manager in the room? The willingness to say yes matters as much as anything the peer tells you. A team confident in its culture will set this up without flinching. Hesitation is data. And when you do talk to that peer, ask them the hardest-part question again and see if the answers match.

How to ask them

Do not fire all twelve like a checklist. Pick the ones that matter most for you and weave them into the conversation. Ask follow-ups. The first answer is the prepared one, the second is usually closer to the truth. When someone gives you a smooth line, ask for an example, and watch whether one arrives.

Save the sharper questions for later rounds, once there is enough trust in the room that people will answer straight. The hardest-part question and the why-is-this-role-open question land better in a fourth conversation than a first. And ask the same thing of more than one person on purpose, so you can compare.

How to read the answers

Watch for two things across all twelve. First, specificity. Real answers have names, dates, and concrete examples. Vague answers usually hide a vague or uncomfortable reality. Second, consistency. Ask the same underlying question of different people, the manager, the peer, the skip-level, and see if the stories line up. When they do not, you have found the thing nobody wanted to say out loud. That gap is often the single most honest piece of information you will get in the whole process.

You will not get perfect answers. No team is clean. The goal is not to find a place with no problems. It is to find a place whose problems you can see clearly and are willing to take on, told to you by people who were honest about them before you signed.

One more thing about the context problem

Several of these questions circle the same issue: how a team holds and shares what it knows. Places where all the context lives in a few heads look great until one of those heads is asleep, on leave, or gone. It is worth asking, plainly, what happens then. If the honest answer is that the team relies on writing things down so a teammate can get an answer without waiting for a person, that is a healthy sign, and it is the same idea StandIn is built around. The point is not the tool. The point is that a team which has thought about this question has usually thought about the harder ones too.