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

Photo from iMocha

Background

  • 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

  • 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!
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  1. Ask clarifying questions. Make sure you understand what the task/feature is.
  2. Shout out any potential unknowns, trade-offs, or blockers:
  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

  • 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

Contact

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
crocsandcoffee

crocsandcoffee

59 Followers

Staff Android Engineer @ Block/Square | Android Tech Lead @ Flave | Android Lead @ RadioJavan | Gamer | Foodie | CodeBlooded