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?

As an engineer going through the interview process, you’ll probably have to attend a product interview at some point. But why is this step necessary for software engineers? It gives a good indication that the developer can not only work on a new feature but also understand how the work they’re doing fits into the bigger picture — the product vision and roadmap, and that they’re also able to work with other non-tech people.

For the employer, it provides an insight into the person they’re going to hire: do they understand they’re “building a cathedral” or are they just another “brick layer”?

The story of three bricklayers is a parable with many different variations which is rooted in an authentic story. After the great fire of 1666 which affected London, one of the world’s most famous architect, Christopher Wren, was commissioned to rebuild St Paul’s Cathedral.

One day in 1671, Christopher Wren observed three bricklayers on a scaffold, one crouched, one half-standing and one standing tall, working very hard and fast.

To the first bricklayer, Christopher Wren asked the question, “What are you doing?” to which the bricklayer replied, “I’m a bricklayer. I’m working hard laying bricks to feed my family.”

The second bricklayer, responded, “I’m a builder. I’m building a wall.”

But the third brick layer, the most productive of the three and the future leader of the group, when asked the question, “What are you doing?” replied with a gleam in his eye, “I’m a cathedral builder. I’m building a great cathedral to The Almighty.”

(source)

What should you expect?

In this interview one or more product managers will talk to you about your experience working in different cultures and environments, how well you work in a team, how you communicate with both tech and non-tech people (your co workers, customers, stakeholders etc.), your ability to prioritise tasks, understand and contribute to the big picture. You should prepare yourself to share stories and examples of how you’ve impacted customers’ lives and why you value doing so.

These interviewers are also the best placed people to share customers’ perspective and provide insights into the challenges the company is facing, so don’t miss the opportunity to ask them questions as well.

Topics the interviewer might ask about

Your experience — Be prepared to talk about what you’re working on right now, why are you building that, what problems is that product trying to solve, what are the biggest challenges to making it successful, and what does successful mean? This section usually reveals several things about the candidate:

• How much they care about their current product.

• How well they understand it and explain it to a non-tech audience.

• What are the issues they are experiencing the most pain with.

• Did they think about solutions or simply accept that something is broken.

Your big picture thinking — Are you able to see the end result and how your work contributes to that end? How did the feature you last worked on integrated into the product vision? What’s the most customer impactful feature you have worked on and why? Give me an example of when you thought outside of the box. How did it help your users?

Your attitude — Are you proactive? Do you have the initiative to fix issues without being told to? How well do you react to setbacks? Are you transparent with your work? Typical questions might include:

• Tell me about a challenging issue you had to solve.

• Tell me about a time you had to influence someone.

• Tell us about a time you faced failure and how you bounced back.

• How do you deal with sudden shifts in priorities?

• Tell me about a group project you have worked on with many contrasting opinions involved.

• Tell me about a tough or critical piece of feedback you received. What was it and what did you do about it?

• Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way.

Your motivation to join the company and your connection to the organisation’s mission

The interviewers will want to understand why you’re considering working there. An interview is a two-way street so make sure they’re also a good fit for you. Typical questions might include:

• What would make you want to/not want to work here?

• What matters to you when you choose a place to work?

• What does this role mean to you?

The engineering cultures you’ve been exposed to, and how you see yourself growing there — Topics may include agile practices, your approach to conflict & resolution, details about the company’s organisational and engineering structure, and communication and teamwork skills.

• How was your last team structured? Was it cross-functional?

• Tell me about a recent conflict you had and how did you solve it?

Metrics — What do you value? RAM and CPU usage? Database Reads/Writes? Code commits? Pull requests? Bugs fixed? Service throughput?

Numbers are important and can be a good metric. You should come prepared with stories that share your love of numbers. How they’ve helped you and how you’ve used them to shape and make decisions around features, releases and priorities. Also include how you measured success. Did these releases make a difference, was it the right difference? Did you have to roll back? All these will inspire the product managers you speak with. They will illustrate how you approach work, prioritize for customers and measure your own overall impact. Typical questions might include:

• How do you measure the product’s success?

• You’ve just launched a feature, how do you measure its impact, user engagement etc?

• Tell us about a time you used data to influence an important stakeholder.

• Tell me about a time you used data to make a decision.

Your current knowledge of the company’s product

Typical questions might include:

• How would you improve the product?

• What’s a feature you’d like added to the product?

• How would you describe the product to someone?

• What is one improvement you would implement for our product in the next 6 months?

Your prioritisation abilities — How you organise, plan, and prioritise your work.

Typical questions might include:

• What’s your approach to prioritising tasks?

• How would you prioritise resources when you have two important things to do but can’t do them both?

• Describe a scenario which required you to say no to an idea or project.

• How do you decide what and what not to build?

• How do you make sure take debt is also prioritised?

• Let’s say you’re building Spotify, what 5 features would you implement first? This might be a good question to see how the candidate chooses to prioritise the features and might lead into other discussions such as who the customer is, how to use market data etc.

How well do you know the customer perspective?

You should be prepared to share why you believe the customers use that product. Think about the different types of customers and how the product serves their requests. Could there be other type of users whose needs are not met by the product and what solution would you provide? What might prevent the users from using the product?

How to prepare

Develop your Story Bank

To easily tackle so many situational and behavioural questions, the easiest thing to do is to develop your own Story Bank of your past experiences. Choose 5 to 10 experiences that are relevant to you — ones you’re either proud of or learnt something important from. Before the interview, it would be good to think how would you map those stories to the company values you’re interviewing for, you’ll want at last a story for each core value.

When writing down a story, think of the who, what, when, where and why. A good starting point would be following the STAR method:
Situation — set the scene and give the context.
Task — describe your involvement in that situation.
Action — explain how you solved it.
Result — what outcomes did you achieve.

Once you have a story in place, think about the main lessons you got from it and how that incident shaped the way you now approach those situations.

Research the company’s interview process

Companies tend to focus on different topics and aspects. For example:

• Amazon loves to interview candidates using their core leadership values.

• Facebook interviewers tend to ask about your people skills such as the ability to manage conflict or dealing with difficult team members.

Closing thoughts

In the end, the best way to prepare is to actually jump into the action part and interview. The more interviews you go through, the more you get better shaping your stories and talking about them.