I've beenÂ on both sides of interviewing for a while now. As a candidate - for 9 years, and as an interviewer - for 90 interviews. (What a beautiful round number!)
So I decided to write down questions which IÂ usually ask the company when consideringÂ their position.
These questions help me to understand the company culture, their approach to doing things, and the level of "maturity" of people, if you will. These questions I usually ask to a technical person - for example, to a lead developer, CTO, or a team leader. They are much closer to the position I am going to have, so they willÂ give me more detailed answersÂ than an HR person.
It is important to watch not only what they tell you, but also how. Look at the body language, watch out for people not telling the truth, or withholding some facts. For example, if they say "yeah, the code quality is very important for us", but they hesitate a bit and avoid looking in your eyes - maybe this is not exactly the case.
I also make sure to ask more open questions. An example would be:
- "Do you fix bugs?" is a closed question. It is easy to say "yes, sure we do" - this answer is not very detailed.
- But "how do you fix bugs?" is an open question. It requires people to tell you more than just "yes" or "no".Â YouÂ mayÂ learn that the company has QA's, or doesn't have them, writes tests, or doesn't, or prefers monitoring over testing, or values development speed over quality, or the other way around. All of this is valuable and important knowledge, useful to have before starting in the company.
I marked some questions with the little red flag icon:Â ðŸš©. These questions, in my opinion, can lead to deal-breaking answers: I may decide I don't want to work with them if they give a certain answer.
Of course, youÂ can ask your own questions, based on what's most important for you. And of course, you may have your own flags, tailored to your wishes. This is the recipe that works for me really well, but by all means you can tweak it as you like.
So, here is a list of questions I usually ask, loosely split by the topic.
What's the general working process? Can you describe one day or one week of the team's work?
WhatÂ does a team look like? How many people, which positions?
What technology stack do you use? Why did you pick this one over similar ones?
Here IÂ expect the interviewer to say something sensible, for example: we knew this technology very well already; we used it before and it works; we thoroughly compared it to other ones, and it suited well. If they say "because it is so cool right now", it's a flagÂ ðŸš©.
In case they say "we only use latest technology" - what are "latest technologies" and whatÂ are their advantages?
How would you describe code quality of your product?Â ðŸš©
I was told once: "our code is perfect, because I wrote it"! While it's nice to be confident, it also told me something about the team work in the company.
Do you have code reviews?
I know, it's a closed question. But if it hasn't come up in the code quality discussion, you might as well ask directly.
How so you take care of technical debt?
Do you value speed of development over quality of the product or the other way around?Â ðŸš©
Of course, it depends on what you expect from the company. If you're more of a quick-prototypingÂ type of a person, you'll expect them to be the same. If you're a quality-means-everything type, you'll want a different answer.
How do you make sure your product works as expected?
Read: how do you test? How do you monitor? How do you communicate with customers? Do you do business analysis before starting to code?
How does your release process look like?
What product am I going to work on?
More me-centered questions are in the end.
Who are your customers?
How do you communicate with them? Who does that? How do you collect customer requirements?Â ðŸš©
The company should have customers, or at least a plan to get them. Otherwise, you might risk to build a thing no one will use.
How do you prioritize tasks?
How do you work with customer feedback?
They have to listen to the customers! They must strive to make the customers happy! They must think not only about the customers' money! If they only talk about technical stuff, or if they disrespect their customers, that would be a flag ðŸš©: the person you're talking with is, perhaps, not so mature.
What are company values?
How do you define and measure success?Â ðŸš©
They must haveÂ it defined, mustn't they? Otherwise, how would they understand if the company is doing the right thing?
What are your long-term plans?
Looking backwards, what mistakes did you make as a company/department/team, and what did you learn from them?
This one may seem a bit too invasive, but you'll learn a lot about the company and about theÂ interviewer as well. It's even more valuable if you're going to work with them or report to them.
How do you, as a company/team, make sure you're working on the right things?
Who makes business decisions?Â ðŸš©
Who makes technical decisions?Â ðŸš©
Also possible to rephrase to: if I and another developer disagree on an implementation, what is going to happen?
These decision-making questions areÂ becoming more and more important the more senior you become. As a lead developer, you wouldn't want to have no power over decision-making - whyÂ would they want to hire you at all then?
Generally speaking, if all decisions are made by one person, it's probably not the best. On the other hand, if all decisions are always made by everyone, what is going to happen if people disagree? Better to clear this up.
How diverse is your team? Do you have a diversity commitment?Â ðŸš©
If the interviewer has no idea what you are talking about, that's a really bad sign for me!
Do ask this question if you belong to the majority as well. You will help theÂ minorities by doing so. Also you will help companies to start thinking in the right direction. A well-balanced team will benefit everyone: the business, the team, the majorities and the minorities.
How is the work-life balance?Â ðŸš©ðŸš©
Do people work overtime? How often? For what reasons? Is it paid?
In these answers watch out for toxic culture! "We are one big family" may sound heart-warming, but in reality you have your own family, hobbies,Â and otherÂ commitments outside of work. Don't give them up forÂ a job!
How do people collaborate? On the same position (e.g. several developers), or on different positions (e.g. developers and QA's).
I prefer companies in which asking questions is endorsed, not punished for. I also think that team work creates healthier environment: when you can freely discuss a particularly complex task with someone, it is really helping to push things forward; and in general, two heads are better than one.
On the other hand, if people are having too manyÂ meetings and discussions,Â they may become less productive.
How does the company helpÂ junior people to grow?
Sometimes they don't have any junior people at all - that's usually not a good sign. InvestingÂ in them and helping them grow benefits everyone: senior people acquire mentoring skills and spread the knowledge, reducing the bus factor; junior people learn domain-specific skills faster.
If I andÂ someone else disagree on something, or if they pick on me, or bully me, what am I going to do?
In other words, how do you solve conflicts?Â ðŸš©
Especially interesting to ask to a person who is going to be your direct manager. You'd expect a certain level of maturity from them. They should be able to understand there is conflict, to listen to all sides, and do their best to solve it.
Is it a challenging environment?
Or, if they sayÂ "we like to challenge each other", what does it mean?Â ðŸš©
Try to dig deeper: is it a healthy challenging and respectful discussions aimed at improvement of the product and the process? Examples may be: "is it the best for the team right now", "is this what our customers want", "how can we improve the process".
Maybe they mean only technical challenges: "how do we scale this better", "how many requests can we process", or "how to make it work faster on smartphones".
But sometimes "challenging" can mean there are people who are constantly going to question your professionalism and make you feel bad. "Your code is so bad"Â or "your designs are ugly" are some gruesome examples.
How do you handle critical feedback?
In some companies it is forbidden to question their practices at all. Some other companies are full of constantlyÂ complaining people. There has to be a healthy balance.
What team and product are you working on?
How do you like working here?
Of course,Â you can't expect them to tell you that they hate working here andÂ are just waiting for the right offer. But you can see the special light in their eyes if they do.
What is the most interesting or challenging task you've done in the last 3 months?Â ðŸš©
They probably asked you this question; now it's your turn!Â See what they considerÂ interesting.
What would you like the company to invest more time in?
Interesting to see if they mentionÂ technology, product, or people. You can then ask them about the missing parts.
What am I going to work on?
Some companies hire for the team - in this case they will tell you. Other companies hire for the company - you may end up anywhere, working on something you don't have any previous experience with, or simply dislike.
What level of autonomy am I going to have? What decisions am I allowed to make?
Again, the more senior you are, the more important it is.
What are your expectations of meÂ in 3 months? In a year?
This question shows if the company is prepared to hire people at all. The company should know how to use the new hires. Do they have an onboarding plan, for example? A list of responsibilities?
Also it will tell you if they would hire just about anyone to grow the staffÂ andÂ look more interesting for investors.
How do you assess people's performance? My performance?
Who is going to be my manager?
This may yield some interesting answers. For example, once the CTO who was interviewing me told me my manager will be the CEO. After that I had a lot of questions about what a CTO does. Turned out, that person didn't execute responsibilities beyond a regular developer would have, and they made decisions based on the code, and not always on business needs. In my opinion, they were too junior to be the CTO.
What are my professional perspectives? Career and compensation ones?
What is the salary range for this position? Bonuses, stock options, relocation packages, signing bonuses, vacation days, etc.
This question may seem the most important. Perhaps, it is! But the stuff you're going to work on, and the people you're going to work with, also need to be considered.
Asking good questions will help you to solve several tasks.
First of all, it will show you if it is the company you want to work for. For example, if they are a big company and don't care about diversity or solving conflicts between people, you can assume there is quite a toxic atmosphere. If they care only about speed of delivery, and don't have any quality control, this will tell you something about the product, the codebase, and the management.
Of course,Â you know better which company you want to work for. Collect your own set of questions, and evaluate companies based on what you want the most.
Second, asking questions will show them you are a professional who isn't going to accept just about any offer. They will see you as a person who values their time.
Third, it will show that you are interested inÂ the position and the interview. I once interviewed a person who only had one question: if we know the best time to visit the Anne Frank House museum. (I don't know, sorry - it's always crazy crowded.) After all interview rounds we got together with other interviewers, and found out the same question has been asked to all of us. Needless to say, we decided that person wasn't so interested in the company, but more - in a free trip to Amsterdam (we fly people to Amsterdam for the last round of face-to-face interviews).
Ask as many questions as you can. The more data points you have, the more informed decision will you make.
Good luck on your next interview!