There are many guides on how to ace job interviews, you'll find books, videos, courses on multiple subjects covering every aspect possible, including even prep that is just for specific companies (like checking questions Facebook is currently asking), but we talk very little on how you should also interview the people you're talking to make sure you do want to work at that place. Switching jobs to find that you ended up in a bad work environment on a dead-end team is demoralizing and might affect your future career prospects.
Most of the questions here assume the people you're talking to will be at least a little bit truthful in their answers. I'd also recommend exercising your network to find friends or friends of friends that work at the place to verify if the answers are accurate or if they're painting a rosy picture to make sure you accept the offer. Most businesses will have some of the problems we will be discussing next, so it's going to be up to you to decide if you do want to sign up for these issues or not, there is no perfect place, but you should go in being comfortable on what the challenges are going to be. Glassdoor, Blind, and Fishbowl are usually hit and miss, with stuff being, either too rosy or just hell, so I can't say I find them very effective.
Also, unless you're going for a director-level/decision-making position, don't trick yourself into thinking you're going to change the whole environment and make it bearable, odds are you won't and the energy you'll spend trying to fix it without having the actual power to do so would be better spent on a job that doesn't require you do pull a Sisyphus every day. The job market is red hot right now, and you should be able to give that bad-looking job a pass.
Now let's look at a couple of questions you could ask to figure out if it is a good job or a tar pit.
What is the on-call schedule like? How many incidents does the team handle every week on average?
In most sane places, the teams that build apps are also responsible for ensuring they're running as expected in production. This means that when something bad happens, someone on the team will be called/paged and get the dreaded PagerDuty alert, you have one incident phone call. Most of us have been there, and pager pain is very real. Working on a team that is firefighting all the time is the quickest path to burnout you could take as you'll be constantly worried about the next time you'll be fast asleep and the phone is going to ring, destroy your night and the next day.
What you're looking for here is a clear on-call schedule with multiple people on rotation and a secondary that also rotates. The schedules should usually be a couple of days long (I'd say a week is generally good enough), with at least two weeks off until you're on call again. Back-to-back on-call schedules are demanding, especially if incidents are frequent because there is very little time you're not worried about incidents.
How much time does the team spend firefighting or doing unplanned work? If a team spends over 30% of its time just fixing bugs and working through incidents instead of building features, there are deeper issues on the team itself. The root causes here could be lack of investment in reliability, automation, lousy planning, death marches, none of which are a good signs. You could dig deeper here with the people you're talking to as to what is going to be done to bring the team back into a more manageable schedule and lower the amount of toil/bugs/incidents if there's no plan or they think this isn't a problem (it's just how we do work), it's a pass.
What is the engineering onboarding process like? What about onboarding on the team itself?
It might sound like a first world problem thing, but having a well-defined onboarding process is critical to having employees that start contributing to the bottom line as fast as possible. Businesses that are hiring but have no plan to get the people they're hiring into actually doing the job aren't doing a good job at hiring and might not be doing an excellent job at other places.
Depending on the company's size, they might not have a general engineering and a specific team onboarding; there could just be one, that's not a problem. What you want to know is what will happen once you join and the expectations. Is there going to be a buddy taking you through the process, someone you can ask questions and get unstuck? How will you get used to the projects you'll be working on? Is there documentation? What are the first things you're going to be working on?
The expectation here is that they won't just say here's the source code, now figure it out but that there is some well-defined way for you to go along (preferably with someone else on the team as a pair) to get you used to the tooling, code, development and deployment process. If there is no onboarding process at all, be ready just to be thrown at stuff and be left to fend for yourself and hope for the best. While it's entirely possible to make this work (as I have had to make this work multiple times) I'd rather be at a place that is going to guide and help me get productive faster instead of having to ask please can you help me to multiple people that might or might not care about helping me out.
How long has the person managing the team been a manager?
It might sound a bit unfair, but, especially as you get more senior, joining a team in a new company with a manager that does not have much experience managing people is risky. While having a manager with a lot of experience isn't a guarantee that everything will be unicorns and rainbows, a new manager is more likely to lack many skills required to build and lead an effective team.
I've heard horror stories from friends that got a new job with a manager that had just been promoted after a stellar stint as an Individual Contributor, which led to a lot of clout in the business, but that couldn't manage people at all. Given the new manager's success in his previous career, he was given a lot of leeway on running the team, and most of the criticism would fall on deaf ears, making it hard to move the needle in any direction. This leads to team members not being promoted, not being assigned to important/impactful projects, and not being promoted.
Being under a bad manager is not only bad for your mental health, but it's also bad for your career as it might stall your professional development and keep you from moving at the pace you expected you'd go. So, beware, joining a team with a newly minted manager carries many risks. Make sure you know what you're signing up for if this is the case.
What is the vision for the team? What are the important projects it is taking on in the next 12 months? What would be my goals/projects if I joined?
Here what you're looking for is to make sure the team you're joining is healthy and doing important work for the business. Teams should have large, impactful projects they have planned and are working on, they should have a vision of what the team's job is, and as they're hiring new people, they need to have a reason for why they would be hiring you.
If the team doesn't have important projects to work on, odds are it might not be an essential part of the business, or the manager hasn't been able to pull important work or doesn't want to do meaningful work. It's not unusual for, in larger companies, there to be teams that are just coasting and delivering small things here and there. If that's what you're looking for, the answers to these questions might give you hints this is it.
Otherwise, if you want to do impactful and essential work, you want to make sure the folks you're talking to have good answers. They should have a clear vision for what the job is, it can't just be "deliver features", every team is working on some domain-specific work, so it has to be "improve the way warehouses are managed", "deliver code faster to production" (if they're a platform team, for instance). And on that vision, they should also have cool and exciting projects they're working on that have a tangible impact on the business, like building a new database-as-a-service product to capture a growing market. This kind of team allows you to grow into a better professional and offers challenges that will get you more experience and promotions.
And last but not least, ask why they're hiring a new person and what would be the work you'd be doing, at what level you're expected to deliver. Are you here to lead a new project? Continue an existing project? What are the opportunities available for you to grow? Having good answers for these questions means they've done their homework on why they need to hire someone else, and you'll get a feel of the expectations they're placing on you if you join.
Is there a career development plan, and what does it look like?
You might be in for the love of writing code and stuff, but we all want to be paid and eventually make more money next year than we do right now, and to do so, you have to progress on your career in some way. Ideally, you want the place to have a ladder with multiple levels and well-defined expectations for what you should be doing to get to the next level. Not knowing what you have to do to be promoted leaves you at the whims of your manager, and that is going to be the luck of the draw, the manager might work to get you promoted or not, taking most of the possibility of you influencing this out of your hands.
Having a known set of activities you have to attain to move up allows you to plan your work accordingly, ticking the boxes that need to be ticked instead of just randomly doing stuff and hoping for the best. That also allows you to decide the crucial pieces of work that need to be done and focus on them instead of over-engineering or investing too much time on stuff that won't matter that much for your career. This gives you some power to decide your path instead of leaving it all in someone else's hands.
What are the self-development benefits provided?
No tech company survives with a workforce that doesn't improve, so most of them will offer a stipend or access to education related to the work. You want to be at a place that will buy you that book you need for some new project you're working on or pay for a course or event you feel like will be essential for your productivity at work.
Places that require you to invest in yourself even when your productivity improvement goes mainly to the business aren't the best place to stay.
How long does it take for code that is feature complete to reach production in some way?
Here you're looking for minutes as the answer. In some businesses, hours would be acceptable. More than that is typically bad news unless you're applying for a job at NASA and your code will ship in a satellite. The speed code arrives in production signals maturity of the business development process. The faster it is, the more mature and uneventful shipping code is, and this is what you're looking for at your job. The scarier it is for a team to push changes, the more likely they will cause incidents and break stuff.
Teams with a well-oiled deployment process most likely practice continuous integration, have a considerable mass of automated testing (unit, integration, smoke, black box), observability tools, and ways to rollout code that doesn't update everything all at once. That's why we have the in some way there in the question, you don't have to necessarily update everything to everyone at once (it might even be impossible, given the scale of the work), but you still have a way to put that code in front of actual users and verify it is doing the job. This process should also be fully automated and executed from a CI system instead of a developer's local environment.
Most of the time, not delivering code fast to production happens because the business doesn't trust the team. New processes or steps are added, like change request approvals, manual QA steps, staging environments, so the changes are less likely to break. Unfortunately, adding more processes instead of improving the engineering practices doesn't work. You end up with a very long cycle time to get changes out, with larger changesets that are much more likely to break once deployed, and the cycle begins anew, with even more processes to try to build trust.
How do you measure and maintain code quality?
How does the team make sure the code shipped is of quality and meets the standards defined? Are there standards well defined? Is there time for code gardening, refactors, improvements, and upgrades? Are there automated tools running on the codebases to ensure standards are kept?
We expect a review process or pair programming, static code analyzers, automated formatters, test coverage requirements (at different levels, it shouldn't just be unit or integration tests), and essential documentation. Coding should also be a group exercise, and people should not be working in a vacuum. The team should be working together to deliver on its commitments.
For instance, if there is a pull request review process, how long does it usually take to review a pull request? Minutes? Hours? Days? The longer it takes, the more time wasted waiting, making conflicts more likely. Long review cycles are also a sign the team might not work very well together, and instead of being a team, it might just be a collection of people that happen to be together.
Pick your poison
No place will ever be the perfect workplace; you're going to find issues, problems, walls that can't be breached, and people that can't be reasoned with; still, getting more information allows you to make a better decision when accepting a job or not. You should always ask as many questions as you can about the company, the business, the team, and the people surrounding the team to ensure that it is the place you want to work. Don't forget your job is most likely the single thing you're going to spend most of your time in for a long while. You have to make sure this time is worth it.
Top comments (1)
Maaaan, I will keep this checklist for life.