8 Questions I Ask When I’m Being Interviewed
Interview is the time when the interviewers find out about the candidates, but it is also the time when the candidates find out about the interviewers, the teams, and the company. It should go both ways. At the end, the expectations from both sides should meet.
Expectations change as our life advances. For young, single adults, maybe the they are simply “getting the most money possible and work life balance is not as important.” For people who have families, they can change to “only want to work 9–5 and do not want to be on-call. Salary expectation can drop a bit because of that.” For other people, it can be “no coding and only management because I’ve been the IC for way too long.”
Everyone has different requirements, and we need to let the company or the interviewers know that so our expectations meet. On top of that, interview sessions are also great time to get a feel of the team. Are they all workaholic? Do they not have an SDLC? What are their expected timeline for you to ramp up? Things like these should all be communicated during interviews.
Here are questions I would ask during an interview as an interviewee and why I ask them:
- What is the daily routine for a typical engineer?
I want to know what my day will look like most of the days? Should I be expecting a lot of meetings? Am I only needing to attend standups? Who am I working with on the team? This question tells me a lot about the company and if I’m going to see a hectic life.
2. What is the proportion of meetings vs. coding time?
I want to know if I’m going to be developing or be in meetings more. It really depends on people’s preference, but I want to know this.
I personally hate meetings and have trouble multi-tasking between meetings and developing, so I try to make sure the developing time >> meeting time.
Normally, daily standups, 1 sprint meeting, 1 sprint retro, and maybe 1 on 1 meetings with manager should be the only routine meetings I’m willing to accept.
Spontaneous meetings like design or PoC discussions from time to time are acceptable, but if these become routine and I don’t have anything to add half of the time, I would love to skip these meetings.
What’s worse is if those meetings that can totally be replaced with a simple discussion with Slack or an email. I want to make sure up front that there’s nothing like those. No one wants to waste time on meaningless meetings.
3. What’s a typical sprint look like for the company?
This can tell me several things.
Is the company even using agile? If not, what’s the system. Is there even a system?
What’s the length and what is expected to be done in a sprint?
What is the SDLC? How are time /story points allocated in a sprint?
Are tests included when we estimate story points / time needed?
Is there code-freeze so we don’t squeeze bad code into the release branch last minute?
What’s the QA process?
With a good sprint planning and SDLC, we can minimize the number of production errors thus no fire-fighting. Fewer production bugs == fewer hair loss, and you can best estimate the time needed to work on actual stories instead of constantly being pulled to work on production issues.
4. What’s my responsibility on the team?
Every company expects different things for a developer. Especially for smaller companies, developers often have to wear multiple hats. Some developing time might need to be set aside to perform QA tasks if there’s no QA. Some time might be needed for prod monitoring. Some even need to be pulled for doing PM and design work (yes, I’ve been in a company like this.)
Knowing what the company expects you to do is important so you don’t get blindsided by additional tasks you didn’t expect. Surprises like this is no fun at all.
5. Are we expected to work overtime? What’s a typical work hour for every one? Any on call duty?
If you work in a team where everyone works overtime, you would feel bad or afraid to look bad if you don’t do the same. Some people are okay with it, some are not. Knowing this upfront is important to know what your life style will be like if you work here.
In addition, be aware of on call duty or production support. No one likes it, but most likely someone has to do it at some point, so it’s better if there’s already a rotation. You then need to make sure you’re okay with the rotation. For me, one day every other week is acceptable as long as I know ahead of time (though I don’t mind not having it). However, everyone is different though.
6. What happens in crunch time? How often does it happen?
“Crunch time” refers to the time period right before a (big) release when everyone just tries to shove the code in to make it semi-complete. This again happens more often in smaller companies when delivering the product is the top priority. This is the time when messy code gets into production and (way) less testing coverage is implemented.
Of course this leads to more potential of production issues, which equal to stress.
Crunch time happens, but we need to make sure it doesn’t happen every sprint. Otherwise our tech debt will skyrocket.
This also shows poor sprint planning. More crunch time means we are not allocating the time correctly, most likely taking on too much for a sprint.
However, no one is perfect. We do overestimate our ability to work on stories, We do face issues that take a long time to figure out, and of course we do get blocked because of something that’s not our own issues.
Shit happens, and crunch time happens. We just want to minimize it. Knowing how the company deals with crunch time is very important.
7. What happens if there’s conflict among teams?
For a given story, PM would have their ideals and developers would have their own. Sometimes they don’t match. What happens then? How do people at this company deal with it?
Different teams have different schedules. For a task some team might see as urgent might not get the same urgency from another team. When multiple teams have to collaborate, how do they communicate?
If there’s just no way to resolve this conflict between two teams, who makes the final judgment?
These are things you want to know before joining to avoid having to fight for getting things done every sprint. This also shows the company culture as in how they communicate. Even if you work as an IC, most of the time you work with other people in order to get something done (this is especially the case in bigger companies when each team only handles a small portion of the product.)
8. Salary?
I personally don’t think salary should only be discussed at the end. It’s actually better to discuss this upfront so we don’t waste each other’s time. Be sure to know how much you’re worth. You can compare each company’s salary to set your expectation. Otherwise I would use websites like levels.fyi to get a feel what you should be looking for. Be aware that the data is entered by the great internet mob and people who make less sometimes don’t want to enter the data after seeing some ridiculous numbers at the same position.
Salary is a tricky topic sometimes, but the more frank you are about it, the more chance you have to adjust your expectation, and the more you will know how much you’re worth.
These are the questions I would ask when I’m the candidate. Of course there are more topics we can elaborate based on the answers from these questions, but I believe these questions give me a good sense of what a company/team looks like. Hope this will help you, too.
Buy my a coffee: https://www.buymeacoffee.com/jonathanckz