Red Flags to Look for in Software Engineering Interviews
Part of the Software Engineer Interviews Series, this time we're looking at things to look out for during your interviews and some of the questions you might ask
Once you’ve been offered the opportunity to interview, you’d think all you need to do is perform well, right? In an ideal scenario interviews should go both ways, you’re trying to convince them to hire you but they should also do their best to convince you to come work for them. So this is your chance to test the grounds and get a feel of the culture and what working there would be like.
But what should you look for in your next company? 5 companies and +70 interviews later, here’s a list of red flags and points to consider I now go through to help set my expectations:
The Interview Process
You only get a technical interview
As an engineer, yes, you need to know how to do your job but that’s not the only thing you need in order to succeed. If a company is interested in having only the technical interview, it might suggest that they do not value all the other non-technical but essential skills: communication, collaboration, product knowledge etc. Which means that they’ve probably hired people whose skills in those areas have not been evaluated, so you might end up working with people who are all hard skills and no soft skills. In the end there’s more to a good engineer than his technical knowledge.
You do not get any technical interviews or the interviews lack any in-depth tech questions
They’re either hiring weak engineers or that is an entry level position.
Non-technical interviewer asking technical questions
If a people person starts asking you technical questions, they are probably reading off from a script and you probably need to say exactly what is written on it. It’s like playing engineering trivia.
Did you meet any of your co-workers during the interview process? If not, ask to before making a decision.
Company Culture
Non-existent vision, purpose, or reasonable goals
What is the point of working on a new feature if it doesn’t integrate with the wider picture and it doesn’t contribute to the product’s growth? That means you’ll probably be working on anything the customer asks and in this case your team plays more of a customer support role.
No of senior people in the team/Lack of diversity
You want to be part of an engineering squad that has a mix of junior/mid-level, and senior engineers. It gives you the opportunity to be surrounded by people you can learn from and to also strengthen your knowledge by mentoring others.
Staring at interviewers who look like stressed out zombies
Are engineers excited for the projects they’re working on or do they look stressed out and overworked?
Growth opportunities
“Is a learning mentality encouraged?” “Do they have 20% time?” (time — usually a Friday off every now and then — when engineers are encouraged to learn/experiment with new things, prepare for exams etc) “Do they have demos/brown-bags sessions?” “Is the sharing of knowledge encouraged?”
“Are there any personal development plans put into place?” “And is there a clear strategy/action points for you to progress/level up in your career?”
Your interviewer uses a lot of buzz words.
“We’re using AI, social networks, cloud computing, big data, IoT. Machine learning this, machine learning that.” Buzz-words combined with the lack of explaining the tech behind it and how the company has implemented any of that, big red flag.
The work-life balance — Did they mention they look for an engineer with a “strong work ethic”?
“We want you to work insane hours and weekends but we don’t want to compensate you accordingly. We want you to work those insane hours and weekends because you want to.”
We’re all in this industry because we love what to do. Someone with a spark in their eyes will usually go the extra mile because they’re passionate about what they do and they care about the impact their work has. But everyone needs time to breath, to spend time with family, recharge, pursue other passions etc. Long hours are sometimes necessary but shouldn’t be the norm.
Do some “stalking” aka research the people you’re going to work with.
Are there any engineers who have been working at the company for some time now? If not, there might be a good reason they’ve left.
Day-to-day Work
Do they deal with a lot of tech debt?
“What state is the code base in?” and “How much documentation is there?”. Devs will generally give honest answers to this kind of questions. “How long is the onboarding expected to take? How long do you expect it will take for a new hire to become productive in your code base?” This will give you a feel of how complex their systems are. Also, if they have lots of technical debt, and they think you will be instantly productive, they have ridiculously high expectations.
Support/On-Call Rota
“How often will you have to be on call?” “Will it cover your working hours or will you have to do 24h?” “How many tier 1 systems does your team support?” Tier 1 meaning having to deal with systems that impact your customer the most if they’re down. (e.g. payment systems, authentication etc) “How busy will on call be?” “How many issues per week does the team usually have to deal with?” “Does the team put emphasis on writing proper, in-depth run-books and postmortems?” “How are incidents dealt with? Is the root caused being investigated/ is there a list of actions the team is planning to work on?”
Do you need to own your feature from start — end? From gathering requirements, design/architecture proposal, infrastructure provisioning, implementation, testing, release, maintenance?
This might depend from company to company and it’s not really a red flag if you are or not involved in every step of the SDLC but it might be a good question to ask to set your expectations of what you will be asked to do.
How are things prioritised and how much of a voice can you have?
“Are incoming tasks discussed among the team before being assigned?”
Who gets to add tasks to the team’s backlog? Are customer requests always prioritised before anything else (bug fixes, dev experience improvements)?
Ask how and who decides on estimates and deadlines. If the developers do not participate at all in how tasks are prioritised and how long the completion should take, then it is likely the leadership makes promises to customers that are next to impossible to keep and pressure you to meet these deadlines while you’ll probably have to deal with a really slow and painful dev environment/deploy/release and who knows what else is in a bad state because no one had the time to fix it.
How does the dev experience look like?
“Do you have admin access on your work computer?” “Do applications need to go through an approval process to be granted the permission to be downloaded?” “Will you need to rise a request to download an approved application?”
I worked in a company where my request to have Notepad++ was declined on the premise I don’t need it for the job. However regulated the industry you’re working in needs to be, this is a sign of how much lack of trust the company has in its employees. Any security, regulatory or compliance checks should be run on the code you put into production as part of your build/deploy pipelines. As an engineer, how can I innovate/improve/grow if I can’t even try a postman replacement on the basis that I can already do my job with postman.
“How does the deployment and release work?” “Do they have a QA/review process?” “Can you release any time or do you need to wait for the end of the sprint?” “Will your team’s releases depend on other teams’?”
Having to wait for the end of the spring to release is not great.
“What’s the split percentage between improving the dev experience/working on legacy (e.g. automating any current manual work, smooth local running and testing of systems, easy straightforward deploys etc) and implementing new features?”
It should be a good balance between the two. If the only work the team is doing is working on new features it might be that the leadership team is a customer pleaser or you’ll be working in a brilliant team that doesn’t produce any tech debt. If the management is not able to say no to the business, it will have a major impact on your workload and how tasks are being prioritised.
Other things to double check — glassdor reviews
That’s a good place to find the reasons former employees left the company.
In the end, you need to trust your gut
It’s unlikely that you’ll manage to keep track of all these red flags. The best thing you can do is trust your gut and try to find out if their working style will be a good fit for you.
Useful resources
Here’s a list of questions I use when interviewing (what I ask changes depending of the company I’m interviewing with, who I’m talking to and what stage of the interviewing process I’m in):
General/Processes
What would you change around here if you could? Or is there anything you’d like to improve?
What do you enjoy the most about working here?
What does a typical day look like for you?
What is your policy on working from home/remotely?
Culture
How would you describe the culture at your company?
is there anything that you are particularly happy/excited about when it comes to the company culture? anything that stands out to you?
Are there any particular qualities that you are looking for in new joiners?
what are some of the areas in the org that you are looking to bolster?
what about in the next 1-2 years?
Career Growth
Are there any personal development plans put into place? Is there a clear strategy/action points for you to progress/level up in your career?
Planning and Roadmaps
What does the planning and goal setting process look like at your company?
Do you use use OKRs? Are they quarterly?
How do you keep the whole organisation aligned?
How do you ensure you’re building the right thing for the customers?
How do you get feedback from the customers?
Do you have a roadmap for the next 1-2 years?
What is a recent piece of feedback that you received from the customer?
What are some of the key performance metrics or KPIs that you measure and monitor?
What are some of the recent milestones at your company?
was there anything that could have been done better/faster? (in hindsight)
was there anything that you found particularly challenging while working on this?
how were the new features/products received by customers?
What are your highest priorities right now?
What are some areas of growth that your organisation is planning to focus on in the next few year?
Any particular areas of expertise you are looking to bring/grow?
examples: data analytics, growth engineering, platform, etc.
How do you prioritise internal/technical roadmap items?
Do you have a separate internal roadmap?
How do you choose where to allocate bandwidth?
Technical/Engineering
What are the engineering challenges that the company/team is facing?
What is the most fulfilling/exciting/technically complex project that you've worked on here so far?
How do you evaluate new technologies? Who makes the final decisions?
What is your stack? What is the rationale for/story behind this specific stack?
Do you tend to roll your own solutions or rely on third party tools? What's the rationale behind it?
How often have you moved teams? What made you join the team you're on right now? If you wanted to move teams, what would need to happen?
What would I work on if I joined this team and who would I work most closely with?
How long is the onboarding expected to take? How long do you expect it will take for a new hire to become productive in your code base?
Support/On-Call
How often will you have to be on call? Will it cover your working hours or will you have to do 24h? How many tier 1 systems does your team support?
How busy will on call be? How many issues per week does the team usually have to deal with?
Does the team put emphasis on writing proper, in-depth run-books and postmortems? How are incidents dealt with? Is the root caused being investigated/is there a list of actions the team is planning to work on?
Release
How does the deployment and release work?
Do you have a QA/review process?
Can you release any time or do you need to wait for the end of the sprint?
Will your team’s releases depend on other teams’?
Dealing with legacy
How does the engineering team balance the effort between feature requests and engineering maintenance/legacy work?
What’s the split percentage between improving the dev experience/working on legacy (e.g. automating any current manual work, smooth local running and testing of systems, easy straightforward deploys etc) and implementing new features?