I just finished up the lengthiest job search that I’ve done, and have just started a new job as a Software Engineer at Twitter! Thought I’d share some of the things that I learned along the way.
General Tips
Never forget that interviewing is a practiceable skill. In the case of engineering interviews, it’s typically a pretty different skill to what you practice on a day-to-day basis, and even the best engineers need to practice.
- Rejection is not rejection of you as a person. Interviewing is arbitrary, and companies get a limited amount of time with you. Don’t let it get you down! Rather, try to ask for feedback, and use it as an opportunity to learn for the next one.
- Get wireless headphones for taking phone calls if you can afford to. You’re going to have to take a lot of calls during the process, between chats with recruiters and technical phone screens, and subtracting the stress of having to hold a phone to your ear and accidentally muting yourself (happened to me a lot) will be super helpful.
- You will be asked to “Tell me about yourself” many times. It’s helpful to have a tight 90 second answer to this that you can tweak depending on the company that you are talking to.
- Read up as much as you can about companies before going into an interview, particularly before an onsite. Demonstrating knowledge about the company is really good signal about a candidate—even if it is not your top choice, you don’t want to seem like you just fired off a million applications to random companies. You want to seem like you are doing your job search in a principled way and chose the company for some particular reasons. Reading company blogs can also be a good indicator of whether you’d want to work at the company or not.
- Take time to reflect after each of your interviews. Think about what went well and what didn’t, and I’d recommend committing it to writing. Think of every interview as an opportunity to improve.
- Use Leetcode! It’s an amazing resource for both programming questions and behavioral interview questions.
Standard Processes
Many companies, especially the larger ones, have adopted a similar process when it comes to interviewing software engineers that typically follows the pattern of a technical phone screen, during which they typically ask candidates to code up a solution to a programming problem in coderpad or similar, followed by an onsite. Onsites usually consist of four interviews:
- Two programming interviews
- Systems Design Interview
- Behavioral Interview
I’ll break down the behavioral and technical portions of this:
The Behavioral Interview
During onsite interviews, most tech companies typically have at least one “behavioral interview” in which they aim to evaluate what you would be like as a coworker. This where I did the least amount of preparation before starting my process. After one of these went pretty poorly for me (I was of course, rejected by the company), I began to do some more preparation.
In these interviews, companies want to get a sense for what it would be like to work with you as a person, and to get a sense for what the previous environments have been like for you. Additionally, many companies are also looking to see that you are performing at the level that they expect you to given your years of experience.
I think that this is the right lense through which to see these interviews. Many software engineering orgs publish “leveling charts” that indicate what they expect of engineers at each level. Take a look at these:
The best way to prepare for these types of interviews is to think of experiences from previous work experiences that demonstrate you performing at a high level. Be prepared to answer questions like the following (definitely not exhaustive):
- Tell me about a time you had to make a technical decision
- Tell me about a conflict you had with a coworker
- What are your greatest strengths? (Give examples!)
- What are you biggest areas of improvement? (Give examples! Talk about steps that you’re taking to improve in those areas)
- Tell me about a time you took on a leadership role?
- What is your approach towards scoping longer term projects?
- Tell me about a time you disagreed with management
My approach towards answering these questions is to start with giving your general strategy for handling the particular situation, and then diving into the details of a particular situation. This applies whether you are talking about a personal conflict or technical project planning. And again, use these as opportunities to to take credit for the awesome work that you’ve done in past jobs.
Coding Interviews
The key here is to do realistic practice. Mock interviews are the best. In the absence of that, Leetcode is a great resource for questions, and if you do enough of these, you should be able to handle whatever algorithms questions companies throw at you. Familiarity with key data structures and algorithms is key, definitely spend the time to review these, and if you’ve never formally studied CS, it’s worth going through and learning these (there are thankfully some great free resources!). When prepping for these, it can be tempting to skip ahead to the answers for these coding problems, it feels really efficient to learn the solutions to problems! However, have the discipline to force yourself to spend at least 40 minutes - 1 hour on a problem before giving up. Even if it feels like you’re floundering, it’s probably still a good use of your time.
Conclusion
Despite the best of preparations, at the end of the day, interviews are somewhat arbitrary, so don’t be discouraged if things don’t work out immediately! Interviewing is a practiceable skill. Good luck, and feel free to reach out to me if ever have questions or need advice.