How to evaluate a codebase and engineering health during interviews

When you’re interviewing for an engineering role, the job description tells you what they want you to do. The interview should tell you what you’ll actually inherit: code quality, build flakiness, release cadence, and how the team handles problems.

This guide gives you concrete ways to assess engineering health during interviews—what to ask, what to look for in answers, quick repo checks you can do, and real red flags that should make you pause.

What “engineering health” really covers

Engineering health isn’t just whether the code compiles. It’s the combination of codebase quality, test coverage and reliability, CI/CD and deployments, incident history and postmortems, backlog and technical debt management, ownership patterns, and developer experience (tooling, onboarding, code review flow).

When you evaluate a role, you want to know both the current state and the team’s capacity to improve it. A messy codebase with a clear remediation plan and executive buy-in can be better than a “stable” codebase that no one is allowed to touch.

Questions to ask in interviews (and why they matter)

Use short, targeted questions that invite concrete examples. Avoid vague prompts that generate marketing-style answers.

Below are grouped questions you can sprinkle into technical screens, manager interviews, or the loop’s wrap-up. For each question I also note what a useful answer looks like and what to watch out for.

• “How often does this service deploy to production? Walk me through the last successful deployment.” — Good: frequent automated deploys, rollback plan, short lead time. Bad: manual gated deploys, deploys done only by one person.
• “Show me one recent incident and its postmortem—what happened and what changed?” — Good: blameless postmortems, concrete fixes, measurable follow-ups. Bad: no postmortems, blame language, “we fixed it” without specifics.
• “How do you track and prioritize technical debt?” — Good: explicit backlog items, scheduled debt sprints, ROI-based prioritization. Bad: debt is “just tickets” nobody prioritizes.
• “What’s the onboarding process for a new engineer joining the repo?” — Good: documented setup, first-week tasks, buddy system. Bad: “figure it out” or hours wasted on build issues.
• “Who owns the architecture decisions and how are they made?” — Good: clear decision-makers, RFCs, documented trade-offs. Bad: decisions made ad hoc by whoever’s loudest this week.

Quick repo and product checks you can do before or during interviews

If they link to a public repo, demo, or even an internal README, use a few quick heuristics that reveal a lot. You don’t need to be the codebase expert—just look for signals.

If you can’t access code, ask for screenshots, a short walk-through, or an architecture diagram during the interview.

• README and onboarding docs: are they present and up to date? A friendly README often correlates with a team that cares about maintainability.
• Commit history and PRs: is there a steady flow of small PRs or large infrequent merges? Large merges often mean risky releases and poor CI practices.
• CI status and pipeline files: failing builds, long-running jobs, or build scripts that require manual tinkering are red flags.
• Test files and structure: are there tests near the code? Look for unit tests, integration tests, and whether tests are run automatically.
• Issue tracker: are tickets actionable and tagged (bug, tech debt, infra)? A chaotic backlog suggests unclear priorities.

How to interpret common answers

Not every problem is fatal. Listen for specifics and ownership. Answers that include names, timelines, and measurable outcomes are trustworthy. Vague answers with lots of qualifiers are not.

Examples of useful language: “We ship daily; last week we fixed a flaky test by isolating the mock and added a CI check to prevent regressions.” Useless language: “We have occasional deploys, but it’s fine.”

Red flags that should slow you down

Some smells are worth taking seriously. They don’t always mean decline the offer, but they should trigger follow-up questions and a plan for what you’d accept or negotiate.

If multiple interviewers tell different stories about how decisions are made, that’s a sign of misaligned leadership or poor documentation.

• No postmortems or a culture of blame after incidents.
• Only one engineer can deploy or perform key maintenance tasks (knowledge silos).
• CI is green locally but frequently red in the main branch—flaky tests and fragile pipelines.
• Technical debt is constantly deferred and never budgeted for.
• New hires take weeks to build the app or tests are skipped to get features out.

What to ask the manager vs. the team

Different people give different perspectives. Ask the manager about priorities, resource allocation, roadmaps, and budget for refactoring. Ask the team about day-to-day workflows, code review norms, and pain points.

Example distinctions: a manager might say “we budget 10% of sprint time for tech debt.” Engineers can confirm whether that actually happens, and how it shows up in practice.

• Manager: “How do you measure engineering velocity and quality?”
• Engineer: “Show me a recent PR and what reviewers focused on.”
• Manager: “What’s the on-call model and escalation path?”
• Engineer: “Tell me the last thing you refactored and why.”

You don’t need perfect answers from every interviewer. Your goal is a coherent picture: are the problems obvious and addressed, or hidden and ignored? Combine answers, repo signals, and your own tolerance for cleanup work to decide.

If you like the role but find concerning signals, ask for commitments—documentation, onboarding improvements, or a shared plan to tackle tech debt—and get them in writing where possible before you accept.