-
Notifications
You must be signed in to change notification settings - Fork 61
Questions to Ask Your Interviewer
Why this matters & what to look for
Why ask this?
This question helps you understand how the company evaluates developer productivity and what is considered truly “valuable work”.
What to look for:
- Focus on outcomes rather than output
- Impact on the product or users
- Emphasis on quality, collaboration, and ownership
Red flags:
- Measuring productivity by lines of code
- Over-reliance on story points or velocity as a performance metric
- Emphasis on quantity over quality of work
🔗 Source: 3 Questions Experienced Developers Ask to Reveal a Bad Workplace
Why this matters & what to look for
Why ask this?
This question helps you understand how responsibility is distributed within the team and whether there is a blameless culture.
What to look for:
- Bugs are treated as a shared team responsibility
- Developers are encouraged to work across different parts of the codebase
- Focus on fixing and preventing issues, not assigning blame
Red flags:
- “The developer who created the bug is responsible for fixing it”
- Strong blame culture
- Knowledge silos (only one person understands a part of the system)
🔗 Source: 3 Questions Experienced Developers Ask to Reveal a Bad Workplace
Why this matters & what to look for
Why ask this?
This question helps you understand how the team plans work, collaborates, and whether there is space for exploration and technical discovery.
What to look for:
- Regular backlog refinement and clear prioritization
- Use of spikes for research and proof of concepts
- Collaboration between developers and product stakeholders
- Focus on product value rather than rigid processes
Red flags:
- Lack of task refinement
- No spikes or time allocated for exploration
- Overly rigid or top-down process control
- Signs of “waterfall inside Agile”
🔗 Source: 3 Questions Experienced Developers Ask to Reveal a Bad Workplace
Why this matters & what to look for
Why ask this?
This question helps you understand how the company approaches urgency, prioritization, and planning. It can reveal whether “urgent” work is truly business-critical or a result of poor planning and constant firefighting.
Follow-up questions to ask:
- When was the last time your team had a high-priority or “urgent” task?
- What caused it — was it expected or unexpected?
- How often do such situations happen (e.g., weekly, monthly)?
- How do you define something as “urgent”?
- What percentage of your work is typically considered urgent?
- How do urgent tasks affect your planned work (e.g., sprint commitments)?
- Do you re-plan the sprint when something urgent appears, or add it on top?
- Who is usually responsible for handling urgent issues?
- Do you perform root cause analysis after urgent incidents? If yes, what does that process look like?
- Can you give an example of a recent urgent issue and what changed after it?
Red flags:
- “Everything is urgent” or no clear definition of urgency
- Frequent interruptions to planned work (urgent tasks are the norm, not the exception)
- Urgent work is added on top without re-planning
- The same types of issues happen repeatedly
- No clear ownership of urgent incidents
- Reliance on “hero developers” to fix critical issues
- No root cause analysis or follow-up after incidents
- Vague answers with no concrete examples
- Inability to explain what changed after past incidents
- Signs of constant firefighting or reactive culture
Why this matters & what to look for
Why ask this?
This question helps you understand whether the team invests in long-term growth or is focused only on short-term delivery. It can reveal if there is space for learning, improving skills, and working on meaningful challenges — or if the team is stuck in repetitive work with little opportunity to grow.
Follow-up questions to ask:
- How do you support learning new technologies or skills?
- Is there time allocated for learning, or is it expected to happen outside of work?
- How often do developers work on new or unfamiliar problems?
- Do developers have a say in what they work on?
- How do you handle situations when someone wants to switch areas or try something new?
- Are there opportunities to work on different parts of the system or product?
Red flags:
- Learning is expected to happen only in personal time
- Work is highly repetitive with little variation
- No support for exploring new technologies or approaches
- Developers have little control over their work
- Focus only on delivery with no investment in long-term improvement
- Vague answers like “you can grow if you want”