How I aced the Staff Software Engineer interviews and earned multiple offers (Spoiler — no “LeetCode” prep required)!

Photo from iMocha

TL;DR — Okay, this isn’t the best summary, as there is so much to cover and share. I’ll mention the breakdown of this article and leave it to the reader to determine if there is a section they are interested in, however, I strongly encourage you to grab a cup of coffee, and take the full ~15m to read everything. I promise it will be worth it! The article is divided into the following parts: Background, Interviews, Final Thoughts/Takeaways, Offers/Compensation, and Contact information.

Background

For the first time in my engineering career, I decided to partake in a mass interviewing spree. It had been around 3 years since I last went through heavy LeetCode-style algorithm questions. I knew I was rusty but I also didn’t have the time to sit and prep for weeks/months. I’ve seen the trending posts in the engineering community about how stressful, difficult, and complicated coding interviews have become. Despite all of this — I trusted my gut, leveraged my real-world experience, and after ~70 rounds of interviews with 9 companies, I secured 6 offers!!! I wanted to share what I learned, how I approached and answered each interview, and shed light on a different approach to interviewing for tech companies instead of placing focus on solving LeetCode problems.

• Although this role was for Android, around 90% of the interview process is general. There is typically a domain portion and this is where it most likely is swapped with one that is relative to your targeted role (iOS, Android, Backend, etc).
• I signed some “fancy“ NDAs so I won’t name the companies, but I will share the industries: Media & Entertainment, Robotics, AI and Machine Learning, Social Media, FinTech, Healthcare, Video Streaming, E-commerce, Instant messaging
• These were all for remote positions, and all interviews were conducted over zoom/google hangouts.
• The interview process across all of these companies was for more senior roles. I believe more junior roles would follow a slightly different interview process. Regardless, what I am going to share will be super helpful regardless of what level you are interviewing for! At least I think so :)

Interviews

Alright, let’s talk through the interviews, what each round entailed, and how to pass them!

Tech Screening

Initially, you will start with a short phone call with a tech recruiter or hiring manager, to learn more about the role and company, as well as go through your background. Having a well-written, polished, and up-to-date resume makes this one super easy! You should be able to communicate at a high level, a little bit about your background, and what you are looking for. Avoid tech jargon. Communicating your technical skills and background in a non-technical manner really speaks volumes!

Take-home assessment (optional)

Only some companies do this step in their interview process. The take-home assessment is either a small app project (in my case it was Android), or it was 2–3 coding questions via different platforms such as HackerRank, etc. Let’s cover each of these separately.

Take home app — If you’re a mobile developer, this should be a walk in the park. It’s your chance to be creative and showcase what you do in your typical day-to-day as a mobile engineer. Key things to remember:

• Only spend a couple of hours.
• Write code you would be proud of shipping. Focus on clean code, comments where needed, good design, and architecture. These are more important than spending all your time building elegant animations, custom views, or a pixel-perfect UI.
• Implement your preferred architecture and design. I stuck with MVVM and separated my apps into layers: App/UI/ViewModel, Domain, and Data/API. You may be asked to talk through this in follow-up interviews, so build what you are most familiar with and comfortable with.
• Write some tests! You don’t need to unit test everything. But showcasing some unit testing skills and specifically what you test, goes a long way!

Take-home coding assessment — Okay, so here are the first LeetCode-style questions. Here’s my approach:

• I took 5 minutes to cycle through all the questions first. I ranked them from easiest to hardest and tackled the easier ones first
• I didn’t concern myself with trying to “think out of the box” and use the right data structures or textbook algorithms to use. I focused on just solving the problem, no matter how badly performant my solution was or how much work I was duplicating
• Imagine you have limitless memory and CPU, just tackle the problem step-by-step and focus on the happy path solution.
• The majority of problems can be solved with Maps, ArrayList, LinkedList, and simple looping. (Most likely what you use every day!) Yes, picking the right data structure or knowledge of algorithms can make solving the problem easier. And this is where taking weeks/months to study and practice helps. But if you have a real world time constraint like I did, you can solve almost all coding problems with extra steps, in a less performant approach, with the usage of more common data structures and simple looping.
• These assessments are typically pass/fail based on a point system. The more tests you pass for each problem, the more points you get and ultimately “pass” the assessment.
• There is very very little chance you will get a super complicated problem in these take-home assessments. Those questions typically are ambiguous and require follow-up questions and clarity, and as such wouldn’t show up in a take-home.
• If you have extra time in the end, now you can revisit your solutions and improve them.

Final Rounds (4–7 rounds)

Congrats! You have reached the final round of interviews. This is where it can get a bit shaky and vary from company to company. I interviewed with well-funded startups (unicorns), top-tier companies, and also “FAANG”. Although it varied a bit, almost all of them had a common structure described below. I’ll list them out with a brief description and then deep dive into each one to share tips and strategies I used for each.

• 1–3 Technical — Either solving a coding problem with 1–2 engineers or building upon your take-home project
• 1 Systems Design & Architecture — Use some sort of “whiteboard” tool like LucidChart, GoogleDraw, and MURAL, to draw end-to-end how you would architect a feature/problem. e.g. “We want to implement a profile screen when tapping a user’s picture”
• 1 Domain/Knowledge — Given the role I was interviewing for, this was primarily Android, Kotlin, and Java questions.
• 1 Q/A Project experience — Deep dive into one of your projects where you discuss your role, responsibilities, challenges, outcomes, and any technical decisions you made.
• 1 Q/A People/Behavioral — The standard “Tell me about a time where….”
• 1–3 Chat with EMs — A less formal meet and greet with a hiring/engineering manager to learn about the role, team, and answer any questions you have.
• 1–3 Chat with Leadership — For startups, especially when you are interviewing for more senior positions, it’s more common to have multiple meet and greets with different members of leadership for culture fit, and mission alignment to get to know one another.

Technical Rounds

These were either building upon your take-home project or solving a coding question. Let’s deep dive into each.

Option 1: Take home project extensions — This one was a lot of fun and you should have little to worry about! It’s just doing what you do every day as an engineer. At previous companies — I participated in a lot of pair programming sessions with team members when tackling some type of technical task. This was no different! You won’t be given something unreasonable to do within an hour, often the task will be just building upon what you did in the take-home. Stay calm, and just go about this the way you would in a real-world setting. Just remember to shout out any decisions, trade-offs, callouts, etc as you go about implementing the feature. Here are some real examples of what I talked through:

“Although not ideal, I’m going to duplicate this code into both ViewModels and if given extra time in the end, I’ll look at improving this by moving this into a UseCase within my domain layer”

“For now I’m going to focus on just hooking up the data and displaying it all in the UI. If we have some more time in the end I can come back and demonstrate my knowledge of building more elegant UI”

“I’m going to focus on just getting the right answer, and do some less-than-ideal sorting and filtering here that can probably be improved and solved in a better way if we have time.”

“I’m choosing to store this data in a SQL table instead of Cache because….”

This type of interview is more about showing how you work with others, talking out loud while you make technical decisions and how you tackle a real-world problem in parts.

Option 2: Coding Question — Alright, here we are again with dreaded LeetCode questions. If you follow the same outline mentioned above with the take-home assessment, this is no different, except now you have a real human(s) in the room. Here are the main tips to remember:

• Read, then re-read the problem. Make sure you absolutely understand the question. The most difficult part about a coding question is first making sure you understand what is being asked. If you need clarity, ask questions, and ask for clarifying examples of: “Given some input X, the solution should output Y”
• Talk out loud about how you want to solve the problem

“I think the way I am going to solve this problem is by first doing X, then doing Y, and then I should be able to do a loop over and get Z as the final answer”

• Transform your plan into code — start implementing your solution. Shout out anything you are thinking may be a good context for your interviewer. Most people think you have to talk non-stop, or you’re not talking enough. We are humans, not robots. It’s perfectly acceptable to say “Hey can I get 2 minutes to quickly gather my thoughts here”. Shout out what you are going to do, and then do it. No need to talk non-stop because you want to avoid awkward silence.
• If you’re stuck — say it! If you’re completely stuck, it’s not the end of the world (trust me!). Your interviewer knows how stressful this is already. We all have had those moments where we completely space out, and a simple clue helps us get back on track. Just communicate with your interviewer.

“Okay so here is where I was going …. But now I’ve lost my train of thought"

“The direction I want to go in is …. any clues you can give me or something obvious I might be overlooking?”

• Shout out trade-offs, don’t over-optimize (initially) — Your interviewer doesn’t particularly care how fast you solve the problem or if you need little help getting the solution. It’s all about communication, communication, and communication. Don’t worry about solving the problem correctly. This is about understanding how you think. If everyone in the world thought the same way, we would still have flip phones (no offense to whoever still has them). Embrace your approach to thinking about and solving problems, even if it seems elementary to you. Readable, simple, easy-to-follow code is easier to write than coming up with a clever, sophisticated algorithm.

Systems Design & Architecture

This interview is most likely something you will see if applying for a more senior role. The interview is less focused on a specific domain and more focused on your overall knowledge of how end-to-end systems work and how to build scalable products/solutions.

Typically your interview will start off with introductions and then a brief intro of some drawing tool that you can optionally use. Some people prefer talking out loud, it’s completely up to you. You are given a real-world problem such as a new feature and are tasked with designing everything end-to-end.

1. Ask clarifying questions. Make sure you understand what the task/feature is.
2. Shout out any potential unknowns, trade-offs, or blockers:

What does the data payload look like? Should we support pagination?

Do we need authentication?

Do we need to persist any data and/or supporting offline user experiences?

Do we need to handle error and/or loading states?

3. System Architecture

Do we require a backend, or is this local only? 3rd-party dependencies?

Scalability — can we build this in a platform-agnostic way that can be shared across projects, apps, and teams?

Domain Knowledge

This is another “easy” one. This interview really just probes how much and what you know about your domain. As an Android Engineer, this revolved around Kotlin vs Java questions. Topics included Coroutines, Flows, and language features. Android topics were mainly around lifecycle, persisting data, threading, and general Android framework questions. I say this is “easy” because you don’t know what you don’t know. Just answer to the best of your ability, talk through your thinking, and most likely all of your answers will come from your real past experience.

QA Project and Behavioral

I bucketed these two types of interviews together because they really go hand in hand. One is more focused on a technical deep dive of a project of your choice. The other is around the challenges and situations you faced working in a real team setting on a project of your choice. There is honestly no prepping needed here. Just answer truthfully, with real-world examples, and you should be good to go. Again, you don’t know what you don’t know, and you can’t be faulted for that. If a certain situation doesn’t apply to you or you haven’t had the opportunity to experience it — just call that out. Your interviewer is more interested in real-world examples than hypotheticals. Before you start interviewing anywhere, just pick a project on your resume at an existing or previous company that you are most familiar with and you’re good to go.

Chatting with Hiring/Engineering Managers

Typically this interview is your last interview — and should be really stress-free. Most likely you are meeting your potential future manager. This is now your time to ask as many questions about the team and role and get to know your future manager. One of the most critical aspects of a successful career is having a great manager. And it’s honestly sometimes like “dating”. You want to find someone that you “click” with, who shares similar interests, and whose management style meshes well with what you are looking for to grow in your career! Easy prep for this one — be yourself and ask whatever you need to put to rest any doubt you may have about the team or role!

Chatting with Leadership

Some people find this to be stressful and intimidating. Remember — you reached this point because you are a prime candidate and the company really wants to invest in you! It’s equally important for you to meet who is leading your team, department, and company. This is a great chance to learn more about work culture, company pain points, and values. All things that you should heavily consider when deciding on what offer to accept!

Additional:

I wanted to share the questions I asked at the end of every single interview round, no matter who I met with and what the interview covered. These questions that I asked seemed to really get my interviewer engaged and they all seemed to genuinely enjoy them. It also gave me a lot of insight into the current state of things.

1. If you had a magic wand that you could wave, to make a single technical or non-technical problem disappear at your company or team, what would it be? (Spoiler — the most popular answer I got was build-times *facepalm*)
2. What does your company/team do exceptionally well?
3. What is the most challenging problem your team has had to solve?

Final Thoughts/Takeaways

Although I had great success overall with multiple offers, there were some companies where I did poorly in the interviews. After each interview, I quickly jotted down my thoughts on what I thought I did poorly and what I thought did really well.
Here are my key takeaways:

• GET GOOD SLEEP — In the rounds that I did really poorly, I either had a lack of sleep or wasn’t feeling well. At the end of the day we are human, and looking back I realized I should have just rescheduled my interviews to a different day. Companies will understand and if they don’t, you probably dodged a bullet there.
• COMMUNICATION — Great, you’re the smartest engineer in the room but can’t work well with others, can’t communicate effectively, and are difficult to collaborate with… well… it’s not all about coding. An average or slightly above-average engineer with exceptional communication skills will produce a much larger blast radius than an exceptional engineer with poor communication skills. Effective communication is key in acing interviews!
• COLLABORATE — Not only is it fun, a change of pace, and a way to learn outside of your domain, but paired programming is a great way to improve talking through your thoughts and communication, share knowledge, and elevate yourself and your teammates as well. If you partake in this in the real world, you will perform very well in technical interviews.
• LOW EGO — Even the brightest most experienced engineer makes mistakes and has room for growth. Contrary to what you read and believe — interviewers aren’t as interested in how fast you solve a problem, getting the solution right by yourself, or you proving them wrong during the coding interviews. Even if they show ego, listen to their feedback and comments, ask questions if you’re not sure, and trust their advice as they are really trying to help steer you to the solution. Be open to feedback!

Offers/Compensation

I know there are already good resources out there that give more transparency into offers and how you can negotiate. For that reason, I won’t get into the specifics but I will just confirm that yes, having multiple offers allows you to negotiate a more competitive offer. However, the relationships you make throughout your interviews in combination with your performance are the biggest driver for being able to get higher compensation. Have a positive and friendly attitude, give it your maximum effort, and you will get a great offer regardless. When a company comes across a strong candidate, regardless if they have offers or not, they will do what it takes to get them on board.

Contact

I would be more than happy to connect with anyone who is interested and take a look at their resume (happy to share mine), carry out mock interviewers, or deep dive into any parts of this article. Please shoot me a DM on Twitter @crocsandcoffee!