Let's start with some mythbusting. Most pople focus on the company they're joining, but what they should be thinking about is the team they will be joining and that they should be really clear abous their responsibilities on the new position. See ‘Nine Lies About Work’ — are they really lies? by Andrea Daly-Dickson for a blog post or Nine Lies About Work: A Freethinking Leader’s Guide to the Real World by Marcus Buckingham and Ashley Goodall for a longer version.
- Lie # 1: People care which company they work for
- Lie # 8: Work-life balance matters most
Another great book is Accelerate: Building and Scaling High-Performing Technology Organizations by Nicole Forsgren, Jez Humble, Gene Kim
Some of my questions:
- Is there on oncall schedule?
- How often were you paged on your last schedule?
- Is there Java on the backend?
- In which languages would I need to work in?
- How many projects will I work on at the same time?
- How many repositories do you need to touch to ship a feature?
- Are you using Continuous Delivery?
- How long do you keep PR branches before you merge them?
- Are you working directly on your machines or with Docker or on the Server?
8 Questions You Should Absolutely Ask An Interviewer by Glassdoor Team
- What do the day-to-day responsibilities of the role look like?
- What are the company’s values? What characteristics do you look for in employees in order to represent those values?
- What’s your favorite part about working at the company?
- What does success look like in this position, and how do you measure it?
- Are there opportunities for professional development? If so, what do those look like?
- Who will I be working most closely with?
- What do you see as the most challenging aspect of this job?
- Is there anything about my background or resume that makes you question whether I am a good fit for this role?
6 Questions to Ask in an Interview for a Remote Job
- What percent of people work remotely?
- Do you use video or phone for meetings?
- What collaboration and workflow tools do you use?
- How frequently do you meet?
- How do you build team spirit?
- How often do you gather in person?
The Joel Test: 12 Steps to Better Code
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
The Pragmatic Engineer's Developer Culture Test
- Do people feel safe being themselves and voicing their opinions, even if they might disagree with others?
- Does your company pay a fair wage, that's more or less on par with the local market?
- Can engineers work in a flexible way that works for their team, as well as for them?
Clarity, Autonomy and Collaboration #
- Do you have a process in place to share the business reasons for work to be done with engineers?
- Do teams have a clear backlog/roadmap, making it easy to answer "what will we work on next, and why?"
- Does the top-down planning also meet a bottoms-up planning?
- So can engineers bring suggestions to the table, that end up on the team's roadmap - either as supporting the "why" or as part of the > engineering work budget?
- Do reasonable tech debt payoff suggestions get prioritized this way?
- Are developers encouraged to solve problems directly by going to developers on other teams?
- Do developers work directly with users, designers, product managers, data scientists, and other stakeholders without going having to rely on a proxy (e.g. their manager)?
- Are people taking initiatives to make things better celebrated or rewarded over this seen as unnecessary distractions?
Sustainable Engineering Culture #
- Do you differentiate between the prototype/MVP/functionally complete phase and production readiness state of code?
- Are code reviews and automated testing (unit, integration, etc) part of the everyday development process, to the extent that not having them is a rare exception, for very well understood cases?
- Do you have CI process setup that runs before committing the code?
- After the code is committed, do you have a CD process to push it straight to production - and if not, can developers push the code they own to this environment?
- For teams where developers are oncall, do you measure oncall health and the impact on developers?
- Does fixing an unhealthy oncall have priority over any product work?
- Do you follow an internal open-source model, where any developer can read and contribute to any other codebase - with appropriate code ownership in place?
Career Progression #
- Are most engineering managers technical - meaning have a background of having done software development at some point in their career?
- Do managers do regular 1:1s in a way that builds trust (e.g. listening, giving feedback, discussing career goals)?
- Do you have a career ladder, with levels, and expectations at each of the level defined, and a clear promotion process on how to get to the next level?
- Do you have parallel IC & management career paths that run a few levels above the entry-level engineering manager role?
- Do you have at least two of the following three: 360 performance reviews (where directs also give feedback to managers), a culture of peers giving feedback to each other and regular feedback collected, shared, and acted on by the company via company-wide or org-wide surveys.
- Do you have at least two of the following three: an active mentorship program with developers also mentoring other developers, professional development stipend for books/trainings, regular tech talks where people in the company learn from each other - or from outside experts.
Want to learn more?
Sign up to get a digest of my articles and interesting links via email every month.