Career strategy
You interviewed for the job. Did you interview the team?
You can pass every technical round and still learn too late that the job was wrong for you.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
5 min read
A few years ago, a client travelled in for a product demo. We had prepared the meeting and were ready to show the work. Then the servers went down.
The demo never happened.
What I remember isn't the outage. It's the conversation that followed. We talked about what the client needed, what worried them, and what we would build next. Nobody spent the meeting looking for a person to blame. We left with a clearer understanding of the product and a client who felt heard.
I think about that experience when I'm evaluating a team. I want to know how people behave when the plan stops working.
Job descriptions rarely tell you. They mention collaboration, ownership, agile delivery and a supportive culture. Nearly every team can describe itself that way.
The useful information appears in the examples.
I've sat on both sides of technical interviews for years. When I'm the candidate, I don't save ten questions for the last two minutes. I work them into the conversation as the relevant subjects come up.
Here is what I try to establish before I say yes.
How does the team respond when a release goes wrong?
The next time someone mentions a recent release, ask what happened when the last one slipped or caused a problem.
I'm interested in the next morning. Did the team investigate and fix the process? Did they reduce scope and communicate with stakeholders? Or did everyone look for the engineer whose commit triggered the incident?
An incident isn't proof of a bad team. Every team has incidents. Repeated blame without improvement tells you more.
Don't settle for a claim that the team has a blameless culture. Ask for a recent example.
Who can review your work properly?
This matters especially in mobile engineering, where the iOS or Android group may be small compared with the rest of the organisation.
I ask how many mobile engineers work across the company, whether they review one another's code, and whether they have regular opportunities to share discoveries. I also want to know whether mobile engineers participate in decisions about APIs, authentication and release policy, or simply receive requirements after everyone else has agreed on them.
A technically impressive team can still be isolating if you're the only person responsible for a platform and nobody understands the constraints you work under.
Ask how a difficult pull request gets reviewed. Who can challenge a design? How long does it usually wait? When did feedback last cause someone to change approach?
Those answers reveal a learning environment more clearly than the number of approvals required by policy.
What happens when deadlines become unrealistic?
I want to know who sets delivery dates and which part of the plan changes when the estimate turns out to be wrong.
Does the team negotiate scope? Does the date move? Does the answer become another weekend?
One difficult release means little. A culture where every deadline becomes an emergency means you are joining a predictable problem.
I also ask who writes tickets, who decides sprint priorities, and whether there's a product owner or business analyst. Not because every team needs the same process, but because unclear ownership costs engineers a lot of time.
A board full of tickets isn't a plan if nobody can explain why the work matters or who can change the priority.
What does the normal week look like?
Ask a future teammate to walk through the previous week. How much time went to planned work, incident response, code review, meetings, releases and helping other engineers?
For mobile roles, ask how a change reaches testers and the app stores. Are builds and checks automated? Is a release dependent on one person who knows the manual procedure? Who carries the pager, and how often does it interrupt evenings?
The answer doesn't need to describe a perfect process. It should describe a process that people understand and can improve.
I also want to know how frequently engineers move between teams. If people are reassigned with almost no warning, they may spend years starting projects without seeing their decisions through to production.
What does AI use look like when nobody is presenting a demo?
I'd ask which tools the engineers use, what the company pays for, what data may be sent to external services and who reviews AI-assisted changes.
If a team talks about shipping three times faster, ask how review time and test strategy changed. If the company expects engineers to use AI tools, ask whether those tools are company funded and governed.
A clear policy is more useful than an enthusiastic announcement.
How do people at your level grow?
A promotion framework can look excellent on a website. I would rather hear about a recent engineer who grew into a broader role.
What changed in their responsibilities? Did they start influencing other teams? Were they given time to mentor, lead a migration, or own a decision that lasted beyond one sprint?
And when a release went well, who noticed the work? If good work is invisible until something fails, that's worth knowing before you join.
Don't turn the interview into an interrogation
These are topics, not a script to read through at the end of the call.
Choose two or three that matter most. If the interviewer mentions a release, ask how it reached users. If they mention AI, ask who owns the output. If they mention a mobile platform team, ask how knowledge moves between engineers.
People give better answers when they can see that you're picturing yourself doing the job.
And compare perspectives. A manager can explain the intended process; an engineer can describe a normal Tuesday. Differences are not always warning signs, but they deserve follow-up.
You spend hours preparing to demonstrate that you're good enough for a company. Spend a little of that time finding out whether the company will be good for your work.
The offer is important. The team you join after signing it will shape far more of your career.
If you're trying to choose a clear target role and avoid applying indiscriminately, the Engineer Career Rebuild is built around finding roles that fit your experience and positioning your evidence for them.
