TL;DR
A checklist-style guide urges engineers to treat interviews as two-way evaluations and outlines practical questions to uncover real engineering practices, on-call expectations, technical challenges, and promotion paths. The piece pairs suggested questions with 'how to read the answer' green and red flags to help candidates assess cultural and operational fit.
What happened
The author presents a structured “Reverse Interview” checklist for software engineers to use when the interviewer asks if they have questions. Rather than focusing only on compensation or perks, the checklist probes four areas: engineering culture and process, work–life balance, technical maturity, and career progression. For each area the article offers specific questions — for example, how projects move from idea to ticket, how teams distinguish blocking feedback from nitpicks in code reviews, and whether on-call recovery time is standard policy. It also suggests asking for concrete examples of recent technical problems and post-incident responses. Each recommended question is accompanied by indicators of healthy or concerning answers (green and red flags), giving candidates a framework to spot micromanagement, feature-factory dynamics, burnout risk, or lack of a clear IC career track.
Why it matters
- Helps candidates verify whether company descriptions (e.g., “agile,” “modern stack”) match operational reality.
- Reduces burnout risk by clarifying on-call expectations and compensatory time policies before accepting an offer.
- Reveals whether engineers are empowered to shape solutions or relegated to executing predetermined specs.
- Protects long-term career trajectory by checking for individual contributor tracks and advancement parity with management.
Key facts
- The article frames the interview as a two-way evaluation and coins the term “Reverse Interview.”
- It groups recommended questions into four areas: engineering culture & process, work–life balance, technical maturity & challenges, and career growth & progression.
- Suggested questions include: “How does a project go from an idea to a ticket?” and “How does the team distinguish blocking feedback from nitpicks in code reviews?”
- The author recommends asking about on-call recovery policy, specifically whether taking time off after a night page is standard.
- For post-incident handling, the article highlights looking for blameless post-mortems as a positive signal.
- It warns that phrases like “we work hard here” or “it depends” can indicate poor planning or burnout culture.
- Candidates are advised to verify whether there is a genuine Staff/Principal IC track comparable to management for senior advancement.
What to watch next
- Whether stated on-call recovery policies are consistently honored in practice — not confirmed in the source
- If code-review tooling (linters, automated checks) is actually in use to reduce stylistic debates — not confirmed in the source
- Whether the company documents post-mortems and follows concrete process changes after incidents — not confirmed in the source
Quick glossary
- Reverse Interview: A set of questions a candidate asks employers to evaluate the company’s culture, processes, and fit — treating interviews as mutual selection.
- Code Review: A process where peers examine proposed changes to source code to catch bugs, improve design, and share knowledge before merging.
- Blameless Post‑Mortem: A retrospective after an incident that focuses on system and process failures rather than assigning personal blame.
- Individual Contributor (IC): A technical career path focused on engineering influence and delivery without people-management responsibilities.
- Linter: A tool that analyzes source code for stylistic and some correctness issues to enforce consistent formatting and basic rules.
Reader FAQ
What is the main purpose of these questions?
To vet whether a role’s daily reality aligns with your professional expectations and to surface signals of healthy or problematic practices.
Should I always ask about on-call recovery and overtime?
The article recommends asking about on-call recovery and how often teams work nights/weekends to gauge burnout risk.
How do I interpret vague or evasive answers?
Vague responses are flagged as red flags in the guide; the piece advises seeking concrete examples or documented policies when answers are unclear.
Is asking about salary and benefits recommended here?
not confirmed in the source
Discover more from Dollar’s Substack My personal Substack Subscribe By subscribing, I agree to Substack's Terms of Use, and acknowledge its Information Collection Notice and Privacy Policy. Already have an…
Sources
- Questions engineers should ask future employers in interviews
- viraptor/reverse-interview: Questions to ask the company …
- Reverse Interviewing Your Future Manager and Team
- Reverse interview questions for Software Engineers
Related posts
- The Reverse Interview: Key Questions Software Engineers Must Ask in Interviews
- US Trade Dominance Is Poised to Erode as Tariff Battles Intensify
- Could an Upside-Down Rowboat Let You Walk the Seafloor Like Jack Sparrow?