"Do you have any questions for me?" (2022 edition)
Questions I ask my interviewers.
When I interview for a job, these are the questions I ask at some point during
the interview process. When there are multiple rounds of interviewing I try to
cover each of the questions at least once.
I should clarify that I don't expect great answers to all these questions. I've
never worked somewhere where each of these questions has an answer that I love.
This isn't a checklist for me because I don't expect to work somewhere where
every aspect of the work is just the way I want it to be. I'm looking to get
answers that excite me for some of these questions, and answers I can tolerate
for all the others. If the excitement outweighs the disappointment, I choose to
continue with my application. If I end up getting and accepting a job offer,
it's helpful to know in advance what areas of the new team's working style will
be slightly disappointing for me so that I can brace myself and think of
mitigations. In some cases it's an opportunity for me to learn to love a new way
of working, in other cases it's an opportunity for me to share some of my
experiences with the team (maybe they'll like my preferred way of working), or
in other cases it's an opportunity for me to remember that this is a job and not
a hobby and I'm not expected to love all of it.
I'll also say that this is a personal list -- it's what matters to me. There are
lots of teams that work in totally different ways to how I want to work, and I'm
not making any comments about whether that's good or bad, effective or
ineffective. This list describes what I am personally looking for in a team, not
what I believe all teams should be like. I would be sad if every team worked
exactly the same... variation is a delightful source of innovation. That's
another reason why I would proceed with a job even if some of the answers to
these questions are not what I'm looking for. I'm keen to learn new ways of
working (if they seem to be good ways of working), so it seems good to me to
join a team that has some practices that surprise me. In asking these questions,
I'm assessing to what extent the team will have familiar practices to me, and to
what extent they will be different. I'm expecting a balance somewhere in the
middle.
With that introduction aside, here are the questions and what I'm looking for in
the answers.
Deal Breakers
- How long to compile and run a unit test?
- If I can't run one unit test in seconds I won't be able to practice TDD efficiently,
which is a deal-breaker for me.
- Can you give me a recent example of a change to team working style as the result of a team retrospective meeting?
- For me, it is essential that we have a healthy retrospective culture where
team members are comfortable raising concerns and constructive enough to
turn concerns into experiments. Almost all the other process preferences can
be addressed with concrete examples brought up in a healthy retrospective; I
am flexible on most process points as long as there is a good basis of
process change.
- I've found that teams tend to bias either towards status quo ("we only try
new things if we have evidence they are better") or to experimentation
("that idea scares me but it seems promising, let's try it out and see if we
like it"). It's important for me to be in an experimenting team
- I get so much joy from "uncovering better ways of developing software by
doing it and helping others do it". This question about retros helps me
assess if the team I'm thinking about joining is also interested in the
pursuit of better ways of developing software.
Preferences
- How do you decide what gets worked on next (this week and this quarter)
- I'm paying attention to:
- Whether work is assigned or if individuals select work
- Work in progress -- with the process that's described, will there be many
things on the go (i.e. many performance-hindering context switches) or is
the team empowered to focus on and deliver one thing before moving on to
the next
- Whether customers are discussed -- does this team care about building
things that are useful to customers, or are there different factors that
dominate the decision making instead?
- How does an idea get to customers?
- This is perhaps too open ended -- I'm expecting to provide more clarity /
follow up questions to help the interviewer answer. I'm trying to assess how
much of my job would be the satisfying work of efficiently delivering
valuable software to customers, and how much of the job is frustrating
bureaucracy. I'm looking at the ideation stage (do builders participate?),
at the build stage (does this team build iteratively or in a big bang?) and
pipelines (does this team practice continuous integration, or is it a manual
process to prepare a release candidate?).
- How do folks exchange feedback with each other?
- This is pretty open ended -- mostly I'm looking for evidence of healthy
candor (neither passive nor bullying)
- How is compensation adjusted over time?
- I'm looking for warning signs of twisted incentives. I'd like to avoid
working in an environment where we all need to choose between making the
choice that's best for customer and business or the choice that leads to
good compensation. If folks are incentivised to make strategically poor
decisions to bolster their promotion or to abstain from collaboration, it
will be hard to do good work.
- I expect compensation/promotion to be slightly misaligned with
customer/business needs, but I'm trying to find out to what extent that is
the case in this team
- How do you know your customers are happy (or unhappy)?
- I'm trying to assess whether this team cares about their customers, and if
this organization has mechanisms to keep folks focussed on the customers.
I'm not too interested in guess-driven software development if there is no
good feedback mechanism.
- What does oncall look like?
- There are two things I am looking for:
- does this team operate the software they write, or is it another team's
job? If it's another team's job, then I'll have follow-up questions
about how they get feedback about observability and operability of the
systems they're building. Do they have some way to learn (and incentive
to care) if they're building a system that's hard to operate?
- what are the expectations for outside-of-office-hours oncall work? How
stressful is it? How boring is it? How frequent is it?
- When was your last vacation?
- I'm trying to understand the team culture about vacations (which is distinct
from the vacation policy that would be negotiated in the job offer).
- When was the last time you worked more than 40 hours in the week?
- I expect some long weeks (and some short weeks to make up for it). I'm not
trying to ask "do you ever do more than 40 hours?"; I'm trying to assess
what is the culture around overtime:
- is it exceptional, or is it a predictable part of the project lifecycle?
- do you take time in lieu?
Something to add? Continue the conversation on Mastodon
Written 2022-12