During an interview you should not only try to sell yourself as the best candidate for the job. You should also make sure that the company is somewhere you want to work. Listed below are some questions to ask during your job interview so that you can make sure working at the company is going to be an enjoyable experience that allows you to grow.
What project methodology does the company use?
Does the team you’d be in use waterfall, scrum, kanban, or some other methodology? Knowing what methodology the team uses will let you know what you can expect from a planning side. You should also have follow up questions that are aimed at finding out how well they follow the methodology. The interviewer may say they follow scrum, but additional questions can help you figure out if they actually follow scrum, or just say they do. Some follow up questions could be:
- How successful have you found the methodology to be?
- What are problems you’ve faced or are currently facing with the methodology?
- If they follow scrum, the do they have a scrum master?
- How long is each sprint?
- Do they track metrics, like velocity, capacity, or burndown? How do they use those metrics for planning for the future?
Does the company use Devops?
Having a CICD/devops pipeline set up allows for teams to work faster and produce higher quality code. The company’s use of devops can give you an idea of what the company values the most (speed, quality, long-term planning, automation).
You should ask for details to get an idea of how far along they are with devops. The company may have a build server who’s only function is to build the code, or the company may have an pipeline set up that takes the code a developer commits, runs tests against it, pushes it out to multiple environments, versions it, and/or makes the package ready for end-user consumption. If the interview says they have devops set up and they only have the former but you are expecting the latter, then you’ll be very disappointed when you start the job. Here are some more detailed questions you can ask.
- What kind of build server do you use? Jenkins, TeamCity, Bamboo, Azure Devops?
- Have the interviewer walk you through the pipeline. How does a commit from a developer make it to the end-user?
- What can still be automated?
- How has the pipeline helped your team?
- Do developers maintain the pipeline or do you have a separate Devops team?
- Do you use an artifact repository?
How is the code kept clean?
If the code isn’t clean, it’s hard to work with. No developer wants to work with spaghetti code. To that end, you should find out how they keep their code clean.
- Are unit tests required? What about integration tests?
- Is code coverage tracked?
- Do they follow good coding principles, like SRP and DRY?
- Do they use design patterns?
- Do they have code reviews? What stops low-quality code from making it into the main branch?
How is developer input used for planning?
As a developer, you want to know how much influence you have on the planning process. Ask how deadlines are set. For example, if a client wants some feature, will your boss ask you and the other developers how long you think it will take? Or will he just set an arbitrary deadline? You should find out what factors are used to plan a feature’s deadline and priority.
How are efforts that don’t directly benefit the customer planned? If you and your team really want to start setting up a CICD pipeline, or refactor a part of the code, or write more automated tests, how is time for those efforts planned?
Questions like these don’t only let you know how your input influences planning. They can also give you some insight into how much your opinion in general matters. Will your boss listen to you if you explain the benefits of automation and testing? Will he listen when you explain how a feature is more complicated than he thinks? Your boss should not only listen to you, but also take action.
How do developers stay up-to-date?
The company you work for should help you continue to grow and learn as a developer. Not only you, but your coworkers should be open to continually learning. A coworker who is set in his ways and refuses to learn new technologies can be very difficult to deal with. You should ask how the company facilitates growth as a developer.
- Will the company send you to conferences and/or workshops if you ask?
- What websites or books does the interviewer and/or coworkers already working there recommend? They should be able to name a few.
- How are new technologies and processes viewed in the company? Ask for specific examples.
What’s the career path for a developer?
Ask the interviewer what a developer’s advancement opportunities are. If you want to code for your whole career, but the company only offers advancement into management, then you may want to look elsewhere.
- Do they have senior developer or architecture roles? What are the specific requirements for these roles?
- If you want to advance into management, what are your options. If you want to stay technical, what are your options?
What’s the company’s view on work-life balance?
You should ask how many hours someone in the position you’re applying for works a week. Some companies expect their developers to work way more than 40 hours a week on average. Even if you’ll normally be working only 40 hours a week, crunch times happen. How often do they happen and how many hours does someone in your position work when they happen?
Are you free to work on hobby projects?
If you have hobby projects, such as an app, library, blog, or invention, then you’ll want to make sure that while you work at that company you maintain ownership over them. Some companies will have you sign an agreement that says anything you produce the company owns, even if it’s outside of working hours and doesn’t use any company resources.
Conclusion
The point of all these questions is to find out what your day-to-day experience will be like working at the company. You want to make sure you’ll be happy and respected while working there. Asking these questions can also demonstrate that you’ll be a valuable asset to the company.