Interviewing the Company

At each interview the company/interviewer has goals in mind as to what they want to learn about you to determine whether or not they should continue with the process.

You should also have a good idea of the types of things that you want to learn about the company, people and opportunity at each stage and with each type of person that you talk to. You will almost always be given a chance to ask questions. When I conduct interviews part of what I am looking for is thoughtful questions from a candidate. So, it is a must to have a general idea of what you want to ask given the interview stage.

Some Overall Things To Watch Out For

• Are they in a rush to bring you on, or are they taking a measured approach to get to know you? If they are in a rush, slow down and find out why. They might just be in panic mode and willing to get anyone on the team who can fog a mirror. If they are taking forever to bring you on that could signal that once someone gets hired there they almost never get fired which means there will be a lot of people there just punching the clock and a large number of unmotivated co-workers.
• What does their website look like? Can you get a good feel about what the company does and the value it brings to their customers by just looking at their home page?
• Do they want all, or at least most, of the other people who you will work to spend time with you, talk to you and meet you? Do you get to meet and chat with most of the people on the team? If you only get to meet with the hiring manager and do not get a good grilling by the other engineers that you will be working with that means that anyone who is deemed good enough gets thrown on the team and that the team does not get to pick who they want to work with.
• Remote Positions:
  • Cameras on during interviews: If you interviewer does not have their camera on during the interview this is a big red flag. I’ve heard the excuse “I’m on a VPN and video doesn’t work well”, but what this means is that there is not a culture of people using their cameras during meetings. Maybe that’s OK with you, but what it tends to result in a very siloed and lonesome work environment where the company culture does not encourage people to work together.

Preparing for the Interviews

First Interview

The very first interview is usually with a sourcer or internal recruiter. They want to have a conversation with you to make sure that you can string together sentences, go over the high-level points on your resume, and see if you have the basic qualifications job.

It is a good idea to do some research on them before the first call. Be careful not to say something like “I researched you and know all about you”. You will set yourself up for failure by having the recruiter ask you some detail that you likely don’t know. You should know, at a high-level, what they do and who they serve as they will likely ask you whether or not you know what they do.

Questions

• Company
  • If need be, ask further questions about what they do if the conversation brings up points that you require clarification.
  • What is the company structure?
  • How many people in the company
  • How many people on the team on which you would work?
  • To whom does this position report?
• Compensation and Benefits
  • Salary range
  • Bonus
  • Insurance
  • 401k
  • Stock/equity
• Culture
  • Tell me about the company culture?
  • What are the best things about working here?
  • Can you tell me about something that happens here that wouldn’t happen anywhere else? (This is a question that you can ask to anyone that you talk to along the way. It will help you get a better picture of what it is like working there)

First Interview with a Hiring Manager or Future Boss

You will ultimately have a meeting with a “hiring manager”; the person who you might report to if you were hired or someone else in management. In smaller organizations you might meet with the VP of engineering, and in really small companies it might be the CTO.

The purpose of this interview is for the hiring manager get an idea of whether or not they would want to work with you and whether or not they think you have enough experience to merit a more in-depth set of interviews. For you it is a chance to start learning about the company culture.

You should expect to talk more about the details of the job; the tech stack, what the team looks like, and is an opportunity for you to learn about the company culture.

• Job Specifics
  • Can you tell me about the types of projects that I’d be working on?
  • What is the most immediate project that the person who is hired for this position will be given to tackle?
  • What are the skills and characteristics do people in this position have that make them successful?
• Career
  • What is the career path for this position?
  • Do you have defined individual contributor path or is does it lead to management?
• Culture
  • Is it a “remote-first” company?
    • If so how do you foster team cohesion in a remote environment?
  • If not
    • Do they have offices, and where are they located?
    • What percentage of the team is local and what is remote?
    • Are there required in-office days?
    • How often are people in the office regardless of mandates?
• Business
  • How do they get new customers? What does their sales/pipeline look like?
• Is there anything else that we haven’t talked about yet that is important to you?

Product Manager

• How do you envision working together with a Lead/Principle Software Engineer?
• What kind of interaction do you want customers to have with Engineering?
• What SDLCs have you used in the past and which have worked well and which not so well?

VP Level Manager

Founder

• Mission
  • How did you get started?
• Business Model and Differentiator
  • Who is the ideal customer?
  • What differentiates you from <competitor>
• Growth/Exit Strategy
  • Where do you see the company in 5 years? Grow and run it, or is there an acquisition/exit-strategy? There overall strategy can be a clue as to how they are building their technology. I have seen some organizations that had a clear timeline for an acquisition and were simply trying to pile on as many feature and bring on as many customers as they could just to get a high valuation ahead of a sale. That typically leads to a technical mess. I have also seen other companies that are looking to build a business that they can grow and run for the long-run.
• What are your biggest challenges that you are hoping for someone that you will hire for this role will solve for you?

Final Interview with Hiring Manager

30, 90, 6 month benchmarks for success for this position

Technical

The questions that you ask to Engineers at the company that you are interviewing with should be broken down into two stages

1. Them interviewing you: During this stage the focus is on you with asking most of the questions. You will have an opportunity to ask some questions and the key at this stage is to ask a few, seemingly basic, questions that will hopefully uncover dysfunction, an engineering team that is moving in the right direction, or an already well sorted process.
2. You interviewing them: If you get to the point where they have finished interviewing you and they are satisfied enough that they want to extend an offer, now is when you let them know that you want to dig a little deeper and want to interview them, so to speak. This is when you ask more questions about how they are set up, how they do things, what the team is like, and where they are going.

Them Interviewing You Questions

You will hopefully talk to a number of different engineers who are attempting to evaluate your technical knowledge, each of which will be focusing on a different technical aspect. At each of those interviews the focus will be on extracting information from you as they try to figure out how much you know and if they want to work with you. In most cases you will be asked if be given a chance to ask questions. Following is a list of starter questions to ask. You will need to figure out which to ask to whom during the process. The idea is that you will hopefully get to ask all of these during the “them first” stage.

• Tell me about your SDLC? Scrum or Kanban? In my opinion, Scrum is a faulty methodology for developing software. See this article for details
• Automation
  • How is code deployed to production and who does it?
  • Do you have a “no deployments on Fridays” policy? The answer to this question can be varied and it is not cut and dry as to whether or not to disqualify a potential employer. The idea is to lead the conversation towards how well their deployments and rollbacks are automated. Ideally, they say, “We deploy code whenever it passes all of the tests. Doesn’t matter what day of week or what time of day.” However, if that isn’t the answer and the discussion goes in the direction of a team that is working towards more automated deployments and rollbacks that works too. The question is attempting to guage their experience regarding deployment automation and their willingness to learn and/or move in that direction.
• Observability, Monitoring, and Alerting
  • How is monitoring and alerting setup?
  • How is the code instrumented for observability?
  • What is the on-call strategy? Is there a tier-1 on-call that uses a knowledge-base to do the first level of trouble-shooting with increasing levels of escalation until it gets to calling you?
• Testing
  • What is the philosophy and policies around automated testing?
  • What is the ballpark code coverage percentage?
  • Are there dedicated QA Engineers? This is a big hint as to what the overall SDLC looks like and what the philosophy is regarding automated testing. In my opinion, there should not be any dedicated QA roles in Engineering. All of the SWEs should be expected to build complete unit and integration tests for any software that they write. There are some that argument that for some things tests should be done manually but in my opinion there is a very small slice of things cannot be automated at this point.
• How do developers run the code? The answer to this question can be a huge smell. The correct answer is, “by running the unit and integration tests“. They might also have a docker-compose.yml file that they use to stand up a bunch of dependent services to run locally, or run minikube or something else locally. However, the way that you “run” code while developing is to do it in the context of unit and integration tests.
• Collaboration
  • What is an overview of the design process?
  • How does the team work together to design, architect, build, and deploy new features?
  • Do people use video on calls?
  • Are their daily meeting?

You Interviewing Them Questions

If you get a job offer, now is your opportunity to ask if you can have another meeting or two with some of the other Engineers and/or technical leadership.

General

• What does a typical week look like?

SDLC

You want to get a good idea of what their Software Development Life Cycle process looks like.

Agile?

Talking about Agile is like talking about what oil to use. Lots of flame wars and heated discussions start out talking about Agile methodologies.

• Scrum or Kanban? In my opinion, Scrum is a faulty methodology for developing software. See this article for details.
• What is the definition of done?

Requirements Analysis

• How are requirements for new features, gathered, documented, discussed?
• How much time and/or consideration is put towards R&D where necessary? Quite often an new feature involves new technologies or a new way to use what is already there that require doing some research and developing a POC.
• How does the team work to fail-fast and address the riskiest things first? Often there are ideas that just don’t work in the current context, either existing data is not available or the technology isn’t feasible in the time-frame, or there are other factors for which great ideas will just not come to fruition. Ideally, the team will attempt to identify the riskiest, least understood parts of a feature or project first and either address them or determine if a project is doomed from the start – the sooner the better.

Design

• Can you walk me through the process of designing a new product or feature?
• Where are design documents stored?
• Do multiple engineers collaborate on the design? If so, how do they work together?

Coding and Testing

In my opinion these two typically described separate parts of SDLC are one in the same. Whenever you are writing code you should be writing tests right along with it. Following are some “smell” questions that I’ll denote with an *.

• What types of workstation options are there? What do the Engineers on the team/department/company typically use?
• What are the policies, procedures, and tools regarding unit and integration tests?
• Are testing the stats emitted by the code also included in the tests?
• Are there automated system tests? If so, what are the details about how they work?
• Are their code coverage policies and is this tracked anywhere?
• If there is a dev environment, how it is kept in sync with production?
• Is there a standard IDE that the team uses?
• Is there a default auto-formatter that everyone uses? This might seem like a minute and pedantic point but it speaks volumes about how technical leadership sees the stewardship of source code in the organization. All source code should follow the same formatting rules. SWEs should not waste any time trying to format their code. It saves time and standardizes it so that it all looks the same and makes it easier to read for everyone.
• Are there defined rules for comments? Good code contains comments. It explains the why about some section of code and makes it easier to jump in and make changes.
• Are there any documentation requirements? If so, what are they? Where is the documentation kept? How is it kept up to date? Who is responsible for it?
• Does the team develop any of their own internal libraries? If so, how are managed?
• How is the company managing dependency, component libraries? Is there some company-wide policy for vetting and keeping dependencies up to date and secure?

Deployment

• Is there any CI/CD infrastructure in place? If so, what does it look like?
• How is it rolled back when problems are identified?
• How are configurations managed and maintained?

Operations, Monitoring, and Alerting

• How is observability implemented?
• What are the metrics/stats that are emitted from the production system

Maintenance and Updates

• What is the high-level process for identifying and fixing bugs
• What is the high-level process for adding new features?

Roles and Responsibilities

• Do Software Engineers deploy to production? Do they operate what they write?
• Are there separate DevOps or SRE roles?