You've reached an exciting point in the job hunting process! The interviewer called to set up a date and time, you've practiced all of your answers, and you're ready for any technical questions they could possibly throw at you. So you show up and the interview goes incredibly well.
Now it's your turn to ask questions. Here are a few questions that you should make sure you know the answers to before you leave the interview.
The answer to this question can change the way you feel about a job. A company needs to have good project management processes in place or there will be a lot of confusion. Make sure they can explain how tasks are decided on, who is responsible for handling what tasks, and anything else you can think of.
An environment with bad project management will be really vague in their description of their processes. A company with good project management should be able to give you a quick overview of who is responsible for what, where you can go to see what tasks are still up, and where you can go with questions.
This question depends on the type of company you're interviewing with. If you know that they only work on one project, you could ask how many sprints they do in a month or something similar. The reason you want to ask this question is to get an idea of the average workload you'll be under. There's really no good or bad answer to this question.
I've had someone tell me that a year of consulting work is about the equivalent of 2 - 3 years of work on a single project. That's because consultants work on multiple projects from different clients and they all have slightly different setups that give you exposure to many kinds of issues in a short amount of time.
On the other hand, I've heard people talk about how they were able to dive deep into a technology stack when they were on a single project. Because you can focus on one project at a time, you'll be able to learn more advanced techniques in that stack.
How you interpret the interviewer's answer to this question depends on what you're looking for.
You'd be surprised at the ways some places handle file management. There was one place I knew of that used their email attachments for their file backups! 😖 It's always a good idea to know what tools they use for version control. Find out if they use common tools like GitHub or Azure DevOps.
There's a chance they could use something else, like a proprietary software, but odds are strong it will be Git-related. Find out if there's any kind of formal code review practice in place, such as approving pull requests. And don't forget to ask about the deploy process! They might have automated pipelines in place or they might not.
Some places don't believe in using a formal methodology to get work done and that's fine as long as they have something in place. They will have a particular way they want you to move through the task list and there is going to be some kind of time limit placed on it. That's what you're trying to find out with this question.
Some places do weekly sprints and some do monthly sprints. The main thing you want to know is how many tasks are they expecting you to get finish within a certain timeframe. Knowing how long the sprints are will give you a good idea of the pace of the job. Shorter sprints mean you'll be cranking out code pretty fast, but longer sprints can leave you with nothing to do. 🤷♀️
You want to know how many people you'll be working with right? The size of the development team will tell you a lot. You'll be able to tell if there will be mentoring opportunities or if you will be expected to get up to speed with little help. It's just a numbers thing.
If there aren't a lot of developers on a big project, you will be a lot more focused on getting the job done. If you're on a larger team of developers, you'll probably have a chance to learn from them and to play with different tasks. Just don't think it reflects the quality of the developers. Big teams can do less efficient work than small teams.
We all spend a little of our spare time learning more stuff than we need to know for work. A lot of companies are starting to realize that it's a good idea to offer employees a bit of time to learn on the job. It's one of those little perks that tells you how much they are willing to invest in your growth.
Even a couple of hours out of the week beats nothing. Maybe they do peer programming or they have training sessions from time to time. They might even have a subscription to one of the online sites that do training.
It's another way you can get a feel for how they do work. Some projects are only a few weeks and some are a few years. This is another question that doesn't have a good or bad answer. The main thing they should be able to explain is why the projects are a certain length.
Some people like to move fast and some people don’t. You'll learn a little about the business side of things through this question because that's what typically decides the budget for the projects.
Usually web developers don't need travel for work, but there's a chance you might. Some places will contract you out to other locations and it's good to know that before you accept an offer. This is another one of those questions to get a feel for the environment at that company.
Traveling offsite means they think you are skilled enough to put in front of clients, but it could mean that you get shipped out at anytime.
This isn't a question about how much vacation time you will get, it's more about how business will function without you. Some development departments have one person that knows everything and when they are out, everyone prays nothing bad happens. That's also the time bad things seem to happen.
See if they do cross-training so that enough people are knowledgeable on the work that you could take an uninterrupted vacation. Which leads into the next question.
What happens if a server goes down, a database is corrupted, or the application gets hacked? They should have some kind of emergency processes ready for those scenarios. You shouldn't have to worry about the business going into a state of full blown panic because they don't know what to do. (you should worry for other reasons)
Ask about how often databases are backed up. Ask about what security measures they have in place. Their answers to these questions will really help you figure out how far out they've thought about the project(s).
These are just some of the questions that I like to ask. You might be looking for something completely different in a job and have a different set of questions. Do you want to share them in the comments? 🙂
I'm opening a beta group for some new features in my class. There are only 140 spots open in the beta and it's only 49/m. You'll get access to everything that's already in the class, plus the new features like peer code reviews, a weekly professional development workshop, content made based on your feedback, and more stuff.