posted on Feb 01, 2024
Leetcoding your ways into big tech company

Leetcoding your way into big tech companies

Disclaimer: if you are looking for shortcuts, this post may not be for you. This plan requires at least 6 months of consistent study.

word of the day:

leetcode:

(noun) an online platform for coding interview preparation.
example: Software engineers use the website leetcode to prepare for their interviews.
(verb): an act of preparing for coding interview.
example: did you leetcode today?

While big tech companies are not the only career path for software engineers. There are also a lot of benefits and fun to be at startups. However, when given a chance, I think software engineers can try to work at a big tech company. You don’t have to stay long but enough to know what it is like and to check one item off your bucket list.

The road to employment with big tech companies is not easy. But with consistent hard work, that road is walkable. I hope to walk the journey with you via this article.

    The Pros of Working at Big Tech Companies
    • The pay: big tech companies such as MAANG (Meta, Apple, Amazon, Netflix, Google) pay top of the band to attract engineering talents. My initial offer at Amazon, Bay Area location, as an entry-level software engineer, was $200k without negotiation. My colleague also joined Google with a $200k salary as his first engineering job.
    • The resources:
      • big tech companies also mean more resources. When I was working at a startup, I had to find learning resources on my own via the internet. Meanwhile, at Amazon, everything was handed to me. Want to learn more about AWS? Here is an internal boot camp that I can take. Having a problem with the Neptune graph database for my current project? Here is a help team and their office hours that I can ask.
      • Not only that, I had an onboarding buddy to help me speed up with the team. I had another buddy/manager from another team to help me learn more about the organization and Amazon in general. Of course, I also had regular 1:1 with my direct report manager. I felt so taken care of.
    • The code review process: working at a startup means there is a less defined code review process because people still figure things out as they go. Or they have to develop and ship new features as fast as possible. At big tech companies, code reviewing is more rigorous. There is infrastructure to automate the process, to check whether your codes are meeting the standard. Teammates also spend more time on code review as part of their job. The cost of letting bad code into production is more expensive than the cost of spending more time to review them.
    • Be able to proudly talk about it: The interview process for big tech companies is hard. It consists of getting an initial introduction call from a recruiter, a technical screen with a more experienced engineer, a behavioral interview with a hiring manager, and then a panel interview with topics in system design and data structures with a few other engineers. Engineers need to feel proud if they are able to go through that process and get an offer.

    The Work

    I hope knowing the pros of working at big tech companies gives you some extra boost of energy and motivation. Now, it’s time to do the work.

    To refresh, there are 4 steps in the interview process:
    1: an initial phone screen with a recruiter
    2: technical screening with a more experienced engineer
    3: panel interview with the team which includes:

    • behavioral and somewhat technical interview with a hiring manager.
    • system design.
    • another technical interview, can be data structure or your expert domain for the role.
    • a chat to debrief with the recruiter.

    4: offer and negotiation

    • if everything goes well, you would expect an offer. It’s not a done deal yet, you need to negotiate and clarify any questions you have.

    I will walk you through the details for each step and how to maximize your chances in them.

    0: Getting the initial phone call from recruiters.

    To be able to interview, you need to … first get interviews.

    If you are still in school, take project-based classes that can be used to build up a portfolio. If you are a self-taught engineer, don’t worry, just keep increasing your project visibility and scale, and then make a portfolio. After finishing the projects, spend time to publicize your code, and demos and write README.md. This is important because you need to showcase your work.

    You need to keep your resume and LinkedIn polished and up to date so they are always already for people to look at. Don’t be so discouraged if they are still empty. Just do a small project, learn small skills, and improve your LinkedIn and resume incrementally.

    Presenting yourself online well helps recruiters reach out to you. Otherwise, you can ask for referrals. I find Blind is useful when it comes to referral. Direct messaging people on LinkedIn works fine too. And of course, there are technical career fairs. I had interviews scheduled right on the spot at my university career fair.

    1: Phone screen with a recruiter

    For this round, it mostly gets to know you and the role. It does not mean you don’t need to prepare. Try to tailor your answers and skills based on the job post, and what they look for, use the STAR method if your answers are long enough.

    As a rule of thumb, at the end of any interview, or any round, I would ask logistic questions such as when I would hear back from the recruiter, what the interview process looks like, and what is the pay range. Those questions give me an idea of when I can reach out to them again for follow-up, and how much effort I want to put into the interview process. If the pay range is not within what I am looking for, I still can use the interviews as practice for my desired job.

    2: Technical screening with a more experienced engineer

    This is where things start getting hard. This round takes 45-50 minutes, then 10-15 minutes to ask any questions. Depending on the level you interview for, they can ask one or more technical questions. The questions can be about data structures and algorithms, system design, or domain expertise. I recommend taking 2 courses: course 1: Data Structure and Algorithm, and course 2: Efficient Algorithms and Intractable Problems. I include the links for UC Berkeley free classes and material but you can take any intro course that covers the same topics of essential data structures and algorithms, divide and conquer, backtracking, and dynamic programming.

    For practice questions, it is overwhelming the amount of questions they can ask. So much that there is an industry of prep material for software engineering coming out of it. The most popular one is leetcode.com, an online platform for coding interview preparation. Hence it is also the title of this article.

    With so many questions an interviewer can ask, instead of learning the questions, I suggest learning the tools to solve them. This article 14 Patterns to Ace Any Coding Interview Question covers the patterns, how to recognize and solve them with example problems. I have solved many of them with the help of leetcode.com premium. I shared the solution code in this git repo of mine https://github.com/xingvoong/14-patterns.

    By the way, I am not affiliated with Leetcode by any means (even though I would love to). I just think it is a great tool for coding interviews and worth the investment.

    3: Panel interview or onsite

    If you make it to the panel interview, or onsite, give yourself a big pat on your shoulder, you have been doing great.

    There are usually three to four of one hour interviews, similar in style to the technical screen but range in different topics. One of them is behavioral interview and culture fit with the hiring manager. This round would cover some case studies, how you act in those cases, and takeaways. The best way to prepare for this round is to look into company values and mission, then craft your answers that cover those values. Don’t forget to use the STAR method.

    Here an a note I use while preparing for Amazon’s leadership principle. This example addresses Customer Obsession and Dive Deep principles.

    picking color for a customer freelanching project using STAR method

    Situation:

    • When I was working on a project for a customer. The customer picked a color scheme that I do not think would be good and visually appealing to present their project and website
    • The Client picked blue, pink, yellow

    Task:

    • My task is to build the project with the color scheme that the customer has decided on without changing the colors.

    Action:

    • With client requests and customer obsession in mind, I mentioned my concern about the color choice to the client but still,
      Agree to go ahead and do the project with the color scheme they have
      picked.

    • In the meantime, I met with the U.I. lead to come up with a similar color scheme but with different tones and shades so the project would be
      easier and friendlier to the eyes.

    • I also told the engineering team to implement the project in a way that makes it easy to change the colors. So that I can show the differences
      Between the client’s choice and my choice of color with just a little
      change in tone and shade of the colors.

    • I meet with the customer again to show them the difference. I convinced them with the colors I had picked based on their initial
      requirements.

    Result:

    • I completed the project on time with an extra color scheme that met the customer’s request. The customer was happy with the color
      scheme that I changed for them.
    • I was able to encourage the U.I. lead to design a new color scheme based on the customer’s requests.
    • I was also able to motivate the team to implement in such a way that is easy to show the differences for the customer.
    • I completed the project in time and the customer was satisfied with it.

    Conclusion: I am obsessed with customer requirements by taking their color choice, not changing it but making it better.

    For system design, I recommend this git repo system-design-primer. In general, a system can be divided into three parts:

    Client
    Web Server
    Database

    Then there are other details you can add in between such as load balancer, DNS, CNS, memory cache, and logistics of web services.

    After completing the onsite, you would have a casual debrief chat to catch up with the recruiter about how you feel about the interview process, and when you would hear back from them.

    4: Offer and negotiation

    After all the hard work, it is very tempting to lose yourself after hearing an offer but don’t. Hold on to whatever number they give you, take a few days to sit through it, fact check to make sure it is a fair offer. Then you need to negotiate. While I am no expert in negotiation, I think this book can teach you how. If it takes too long to read the entire book, a summary would do it justice.

    Summary

    If you make it to the end of this article, congrats, you already have what it takes to make it into big tech companies. if you find this article helpful, please share it so other people can read it too. If this article help you get jobs in anyway, don’t hesitate to let me know via my email: xingvoong@gmail.com or my linkedin