Nowadays, if you want to work at big tech companies, there are two things you absolutely need to get good at: LeetCode-style problem solving and system design. People often say these skills are only useful for interviews and don’t really apply to day-to-day work. I used to think the same, but after using it on my own project, I realized that’s not entirely true.

In this article, I’ll share how my FAANG interview prep ended up being super helpful for a real-world project I built from scratch.

📩 The Backstory

Let’s start with a little backstory. In late September 2024, I got an email from a Meta recruiter inviting me to interview for an L4 Software Engineer role. We scheduled the screening interview for the end of October, which gave me a month to prepare.

I dove deep into Meta tagged LeetCode questions, and followed a simple pattern for each problem:

Propose a solution → Implement it → Test it

After a month of consistent practice, I passed the screening round.

A few days later, I was invited to a virtual onsite interview that included technical rounds, a system design interview, and behavioral interviews. I focused hard on the system design part — I watched tons of videos, studied patterns, and learned about tradeoffs in architecture.

Unfortunately, I didn’t pass the onsite round, even though I gave it my best shot. But that’s not the point of this article.

🛠️ Building My Own Project

After that experience, I decided to switch gears and focus on building something of my own — a project I’d been thinking about for a while. At first, the idea was a bit fuzzy. So I took a step back and applied some of the system design techniques I learned during prep.

I started by writing out functional and non-functional requirements, identifying core entities, and sketching out what my basic API endpoints would look like.

wish:in functional/non-function requirements

This approach helped clarify my vision and filled in a lot of the gaps I hadn’t even noticed before.

⚖️ System Design: Interview vs Real Life

As I started building features, I noticed a key difference between interview system design and real-world system design:

In interviews, you usually design the entire system in one go.

In real life, you design each feature separately, one at a time.

For example, when I worked on the OTP (one-time password) feature, I broke it down into two parts: sending OTP and verifying OTP. I made separate high-level designs for each part to make sure everything was clear before jumping into implementation.

wish:in high level design

This helped me avoid a ton of potential confusion and bugs down the line.

🧠 Where LeetCode Helped

Now, you might be thinking: okay, system design makes sense, but how does LeetCode help in real projects?

Here’s how — remember that pattern I mentioned?

Propose a solution → Implement it → Test it

I applied that to every feature I built. First, I’d write a function with comments outlining each step.

func (g *GiftsService) SubmitDecision(ctx context.Context, req *pb.SubmitDecisionRequest) (*emptypb.Empty, error) {
    // check the decision

    // remove gift_id from redis (make it not booked)

    // get gift by gift_id

    // if decision is accept and availability is single -> change gift status to unavailable

    // if decision is accept and availability is multiple -> do nothing
    // if decision is decline -> do nothing
    return &emptypb.Empty{}, nil
}

Then, I’d implement each step one by one.

func (g *GiftsService) SubmitDecision(ctx context.Context, req *pb.SubmitDecisionRequest) (*emptypb.Empty, error) {
    // check the decision
    if checkDecision(req) {
        log.Printf("Invalid decision arguments: %v", req)
        return nil, status.Errorf(codes.InvalidArgument, "wrong decision arguments")
    }
    // remove gift_id from redis (make it not booked)
    if !g.service.db.DeleteValue(req.GiftId) {
        log.Printf("Could not delete key %v from Redis", req.GiftId)
        return nil, status.Errorf(codes.Internal, "could not delete gift id")
    }
    // get gift by gift_id
    gift, err := g.service.db.GetGiftById(req.GiftId)
    if err != nil {
        log.Printf("Could not get gift by id: %v", err)
        return nil, status.Errorf(codes.NotFound, "could not get gift by id")
    }
    // if decision is accept and availability is single -> change gift status to unavailable
    if req.Decision == "accept" && gift.Availability == "single" {
        if err := g.service.db.ChangeGiftStatus(req.GiftId, "unavailable"); err != nil {
            log.Printf("Could not change status of gift: %v", err)
            return nil, status.Errorf(codes.Internal, "could not change gift status")
        }
    }
    // if decision is accept and availability is multiple -> do nothing
    // if decision is decline -> do nothing
    return &emptypb.Empty{}, nil
}

And finally, I’d write unit tests or integration tests for that function or endpoint.

This habit made my development process much smoother, more structured, and easier to debug.

✅ Final Thoughts

So yeah, all that interview prep wasn’t a waste of time after all. It gave me solid patterns and mental models that I now use in actual development. Sure, interviews don’t always perfectly mirror real-world work, but the skills you build along the way are 100% transferable.

As a result of this process, I built a website for creating and sharing wishlists — https://www.wish-in.com.

📘 What’s Next?

In the next article, I’ll dive into how I used gRPC for the web and how it compares to traditional REST APIs.