TL;DR
A Substack post by Dollar Dhingra lays out a checklist of focused questions engineers should use to probe company culture, technical practices, on-call rules, and career ladders during interviews. The guide highlights specific green- and red-flag answers to reveal whether a role will involve meaningful engineering work or frustrating maintenance and burnout.
What happened
In a December 25, 2025 Substack piece, Dollar Dhingra advises software engineers to treat interviews as two-way evaluations and offers a structured set of questions to expose how teams actually work. The author breaks the checklist into four areas: engineering culture and process, work–life balance, technical maturity and challenges, and career progression. For culture, Dhingra recommends asking how ideas become tickets and how code reviews differentiate between blocking issues and stylistic nitpicks, calling out practices like design docs and automated linters as positive signs. For balance, he recommends clarifying on-call recovery policies and how the team responded after past deadline crunches. On technical maturity, he suggests asking about recent production failures and the hardest technical problems faced. Finally, he warns engineers to confirm whether a meaningful individual-contributor career path exists, rather than a forced move into people management.
Why it matters
- Helps candidates spot organizations that treat engineers as problem solvers versus mere implementers.
- Reveals whether on-call duties are paired with explicit recovery policies or left to informal flexibility that risks burnout.
- Uncovers whether code review culture prioritizes learning and architecture or enforces manager-driven style gatekeeping.
- Shows if the company learns from failures (systemic fixes) or focuses on assigning blame.
- Clarifies whether progression for senior engineers includes non-managerial Staff/Principal tracks.
Key facts
- Ask how a project moves from idea to a ticket and when engineers join that conversation.
- A positive sign: engineers sit in roadmap meetings or write design documents before coding.
- A red flag: product hands down requirements and engineers only execute them, described as a 'feature factory.'
- Ask how code reviews separate blocking feedback from optional nitpicks and whether linters are used to settle style disputes.
- Green review practice: automated linters plus a rule that anyone blocking a PR should propose a fix.
- Clarify on-call recovery policy—whether overnight pages allow taking the next morning or day off without using PTO.
- Ask about the last production bug, the team’s immediate response, and whether a blameless post-mortem process is used.
- Request specifics on the hardest technical obstacle in the last six months to learn if challenges are technical or organizational.
- Ask to see the IC career ladder and whether Staff/Principal engineers exist and report to senior technical leadership without managing people.
What to watch next
- Vague answers about when engineers are involved in planning or about responses to production failures are a warning sign.
- Promises of being 'flexible' around on-call recovery or deadline crunches may conceal a culture that expects unpaid overtime.
- not confirmed in the source
Quick glossary
- Design doc: A written plan describing architecture, trade-offs, and implementation approach before coding begins.
- Linter: A tool that automatically enforces coding style and highlights common errors to reduce manual nitpicks.
- Blameless post-mortem: A retrospective that focuses on systemic causes of an incident rather than assigning individual blame.
- On-call: A rotation where engineers are responsible for responding to production incidents outside normal hours.
- Individual Contributor (IC): A career track focused on technical leadership and coding rather than people management.
Reader FAQ
What should I ask about on-call responsibilities?
Ask explicitly about the official recovery policy after overnight pages and whether compensatory time is standard.
How can I tell if engineers really influence product decisions?
Ask when engineers are brought into the idea-to-ticket pipeline—early participation or only after specs are set is telling.
What indicates a healthy code review culture?
Look for automated linters, clear distinction between blocking issues and optional comments, and rules requiring suggested fixes when blocking.
Is there a way to confirm career growth without moving into management?
Ask to see the IC ladder and whether Staff or Principal engineers exist who advance technically and are compensated similarly to managers.
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 Must Ask Future Employers in Interviews (and Why)
- viraptor/reverse-interview: Questions to ask the company …
- Reverse Interviewing Your Future Manager and Team
- Reverse interview questions
Related posts
- US Trade Dominance Is Poised to Erode as Tariff Battles Intensify
- Could an Upside-Down Rowboat Let You Walk the Seafloor Like Jack Sparrow?
- Explaining Rust’s Loan Algebra: New Borrow Kinds, Tables, and Rules