If you are new to backend engineering, the world of APIs can feel overwhelming. You learn REST because it is everywhere, the de facto standard for web services. Then you hear about GraphQL and how it solves all of REST's problems. Then someone on your team mentions gRPC for a new microservice, talking about performance and protocol buffers. And then there is tRPC, which seems to be popular in the full-stack JavaScript world.

How do you decide what to use? This is not an academic question. The choice you make has long-term consequences for your system's performance, scalability, and the productivity of your team. Picking the wrong paradigm can lead to slow applications, bloated data transfers, tight coupling between teams, and a frustrating developer experience.

As engineers, we need to understand our tools deeply. This post will break down the core ideas behind REST, GraphQL, and gRPC. We will look at their strengths, weaknesses, and the specific problems they are designed to solve. By the end, you will have a clear mental model and a practical framework for choosing the right API paradigm for your next project.

Core Concepts

An Application Programming Interface (API) is a contract that allows two pieces of software to communicate. When we talk about web APIs, we are usually referring to how a client (like a web browser or mobile app) communicates with a server over a network. Let's dissect the most common paradigms.

REST

REST stands for REpresentational State Transfer. It is not a protocol or a library; it is an architectural style built on top of the HTTP protocol. It has been the dominant style for over a decade for a reason: it is simple, and it models the web itself.

The core idea of REST is to think about your system in terms of resources. A resource is any object or entity you want to expose, like a User, a Product, or an Order. Each resource has a unique identifier, which is its URL (Uniform Resource Locator).

You interact with these resources using standard HTTP methods, which map directly to CRUD (Create, Read, Update, Delete) operations:

• GET /users/1: Retrieve the user with ID 1.

• POST /users: Create a new user.

• PUT /users/1: Update the entire user with ID 1.

• PATCH /users/1: Update part of the user with ID 1.

• DELETE /users/1: Delete the user with ID 1.

A key constraint of REST is that it is stateless. Every request from a client to a server must contain all the information needed to understand and complete the request. The server does not store any client context between requests. This makes REST APIs highly scalable because any server can handle any request, which simplifies load balancing.

When to use PUT vs PATCH?

PATCH is often overlooked but important. While PUT replaces the entire resource, PATCH modifies only the fields you specify. For example, if you just want to update a user's email without changing their other data, PATCH is the correct choice. It leads to smaller payloads and more efficient updates in many real-world APIs.

Source: Hanzalah Waheed on X

Real-world Example: Most websites use REST internally for service integration. For example, authentication, billing, and notifications services often communicate via REST APIs even inside large systems.

Pros of REST:

• Simplicity and Standardization: REST is easy to understand and implement. The learning curve is low, and the vast majority of web developers are familiar with it.

• Leverages HTTP: It uses HTTP features, like caching for GET requests, to its full potential. Browsers, proxies, and CDNs can cache responses automatically, improving performance.

• Wide Adoption: The tooling and ecosystem around REST are mature and extensive. Libraries exist for every language, and tools like OpenAPI (Swagger) make documentation and code generation straightforward.

• Ideal for public APIs and service integration (e.g., Slack, Stripe, GitHub)

Cons of REST:

REST's simplicity is also its limitation. Two major problems often surface in complex applications:

1. Over-fetching: The server defines the shape of the resource. When you request /users/1, you get the entire user object, which might include their name, email, address, creation date, and more. If your mobile app's homepage just needs to display the user's name, you are still fetching all the other data. This wastes bandwidth, which is critical for mobile users.

2. Under-fetching and the N+1 Problem: Sometimes you need data from multiple resources. To show a user's profile and their last five orders, you first have to GET /users/1. Then, you have to make another request to GET /users/1/orders?limit=5. This requires multiple round trips to the server, which adds latency. It gets worse if you need to fetch a list of users and then fetch the orders for each user in that list (the N+1 query problem). These issues led to the development of GraphQL, which we will discuss next.

Example: REST with FastAPI

pip install "fastapi[standard]"

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

users = {
    "1": {"name": "Anas Khan", "email": "anas@example.com"},
    "2": {"name": "Ninad Naik", "email": "ninad@example.com"},
}

@app.get("/users/{user_id}")
def get_user(user_id: str):
    user = users.get(user_id)
    if not user:
        return JSONResponse({"error": "User not found"}, status_code=404)
    return JSONResponse(user)

Run:

fastapi dev main.py

Test:

curl http://127.0.0.1:8000/users/1

Expected Output:

{"name": "Anas Khan", "email": "anas@example.com"}

GraphQL

GraphQL is not an architectural style but a query language for your API. Developed by Facebook and open-sourced in 2015, it was created to solve the exact problems of over-fetching and under-fetching that their mobile teams were facing.

With GraphQL, the client has the power. Instead of having multiple endpoints for different resources, you typically have a single endpoint (e.g., /graphql). The client sends a POST request to this endpoint with a query that specifies exactly the data it needs, including nested relationships.

The server then returns a JSON object that mirrors the structure of the query.

Consider the user and orders example. With GraphQL, the client can get all the required data in a single request:

Example query:

query {
  user(id: "1") {
    name
    email
  }
}

The server response will be a JSON object containing only the user's name and email. Nothing more, nothing less.

GraphQL is also strongly typed. You define the capabilities of your API in a schema using the GraphQL Schema Definition Language (SDL). This schema acts as a contract between the client and the server, and it enables powerful developer tools like auto-completion and static validation of queries.

Real-world Example: LeetCode uses GraphQL. Open your browser's DevTools, switch to the Network tab, and filter for /graphql. You will see the queries being made to fetch problem lists, discussions, and submissions.

Pros of GraphQL:

• Efficient Data Fetching: It eliminates over-fetching and under-fetching, making it ideal for applications with complex data needs or for clients on slow networks, like mobile apps.

• Improved Developer Experience: Frontend developers can request the data they need without waiting for the backend team to create new endpoints. The schema provides excellent self-documentation.

• Evolving APIs without Versioning: You can add new fields to your schema without breaking existing clients. Clients only get the data they explicitly ask for, so new additions are ignored unless requested. You can deprecate old fields and use tooling to see which clients are still using them.

Cons of GraphQL:

• Complexity: GraphQL is more complex to set up and maintain than REST. You need to manage a schema, write resolvers (the functions that fetch the data for each field), and understand concepts like mutations (for writing data) and subscriptions (for real-time updates).

• Caching Challenges: Since most GraphQL queries are sent as POST requests to a single endpoint, you cannot leverage standard HTTP caching. Client-side caching libraries like Apollo Client or Relay are powerful but add their own layer of complexity.

• Potential for Abusive Queries: A malicious or poorly written client query could ask for many levels of nested data, triggering a massive database load. You need to implement safeguards like query depth limiting, timeouts, or cost analysis to prevent this.

Example: GraphQL with Strawberry

pip install "fastapi[standard]" "strawberry-graphql[fastapi]"

import strawberry
from fastapi import FastAPI
from strawberry.fastapi import GraphQLRouter

@strawberry.type
class User:
    id: str
    name: str
    email: str

users = {
    "1": User(id="1", name="Anas Khan", email="anas@example.com"),
    "2": User(id="2", name="Ninad Naik", email="ninad@example.com"),
}

@strawberry.type
class Query:
    @strawberry.field
    def user(self, id: str) -> User | None:
        return users.get(id)

schema = strawberry.Schema(query=Query)

graphql_app = GraphQLRouter(schema)

app = FastAPI()
app.include_router(graphql_app, prefix="/graphql")

Run:

fastapi dev main.py

Test: Query:

{
  user(id: "2") {
    name
    email
  }
}

Send the query using curl:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ user(id: \"2\") { name email } }"}' \
  http://127.0.0.1:8000/graphql

Expected Output:

{
  "data": {
    "user": {
      "name": "Ninad Naik",
      "email": "ninad@example.com"
    }
  }
}

gRPC

gRPC stands for Google Remote Procedure Call. It is a modern, open-source framework that takes a different approach. While REST is about resources and GraphQL is about queries, gRPC is all about actions. It is based on the idea of a Remote Procedure Call (RPC), where a client can directly call a method on a server application on a different machine as if it were a local object.

With gRPC, you define your services and messages in a .proto file using Protocol Buffers (Protobuf). Protobuf is Google's language-neutral, platform-neutral mechanism for serializing structured data. Think of it like JSON, but smaller, faster, and it generates native code for you.

Here is a simple Protobuf definition:

syntax = "proto3";

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

message UserRequest {
  string id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

You use a Protobuf compiler (protoc) to generate client and server code in your language of choice (e.g., Python, Go, Java). The client then gets a "stub" that has the same methods as the server. When the client calls GetUser(), gRPC handles serializing the request into a compact binary format, sending it to the server, and deserializing the binary response.

gRPC is built on HTTP/2, which is a major upgrade over the HTTP/1.1 that most REST APIs use. HTTP/2 brings features like:

• Multiplexing: Sending multiple requests and responses over a single TCP connection, reducing latency.

• Bi-directional Streaming: The client and server can send a stream of messages to each other independently and simultaneously. This is perfect for real-time applications.

Pros of gRPC:

• Bandwidth and Efficiency: The first and biggest advantage of gRPC is its use of Protocol Buffers, which are binary and much smaller than JSON. On average, gRPC reduces payload sizes by 60–80% compared to traditional REST-based JSON APIs. It also minimizes network overhead through HTTP/2 multiplexing, which allows multiple requests and responses to share a single connection without the need for repeated handshakes. In large-scale microservice systems with continuous internal communication, these optimizations can save hundreds of megabytes per second. Because of this, gRPC is particularly well suited for performance-critical workloads such as financial trading platforms, IoT telemetry systems, and real-time streaming applications where low latency and high throughput are essential.

• Microservice Communication: This is gRPC's sweet spot. For internal, server-to-server communication where performance is critical, gRPC is unmatched. The low latency and high throughput make it ideal.

• Streaming: If you need real-time, bi-directional streaming for things like chat applications, live data feeds, or IoT devices, gRPC provides this out of the box.

Cons of gRPC:

• Limited Browser Support: You cannot call a gRPC service directly from a web browser. The browser does not give you the fine-grained control over HTTP/2 requests that gRPC requires. You need a proxy layer like gRPC-Web to translate requests.

• Less Human-Readable: The payload is a binary format. You cannot just use curl to inspect a request or response easily like you can with JSON. Debugging can be more challenging without the right tools.

• Steeper Learning Curve: It requires you to learn Protobuf, understand the code generation process, and work with a more rigid, contract-first approach.

Example: gRPC in Python

pip install grpcio grpcio-tools
python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. user.proto

user.proto

syntax = "proto3";

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

message UserRequest {
  string id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

server.py

import grpc
from concurrent import futures
import user_pb2
import user_pb2_grpc

users = {
    "1": {"name": "Anas Khan", "email": "anas@example.com"},
    "2": {"name": "Ninad Naik", "email": "ninad@example.com"}
}

class UserService(user_pb2_grpc.UserServiceServicer):
    def GetUser(self, request, context):
        user = users.get(request.id)
        if user:
            return user_pb2.UserResponse(name=user["name"], email=user["email"])
        context.abort(grpc.StatusCode.NOT_FOUND, "User not found")

def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    user_pb2_grpc.add_UserServiceServicer_to_server(UserService(), server)
    server.add_insecure_port('[::]:50051')
    print("Server running on port 50051")
    server.start()
    server.wait_for_termination()

if __name__ == "__main__":
    serve()

client.py

import grpc
import user_pb2
import user_pb2_grpc

def run():
    with grpc.insecure_channel('localhost:50051') as channel:
        stub = user_pb2_grpc.UserServiceStub(channel)

        response = stub.GetUser(user_pb2.UserRequest(id="1"))
        print(f"User: {response.name}, Email: {response.email}")

        response = stub.GetUser(user_pb2.UserRequest(id="2"))
        print(f"User: {response.name}, Email: {response.email}")

if __name__ == "__main__":
    run()

Run Server (terminal 1):

python server.py

Run Client (terminal 2):

python client.py

Output:

User: Anas Khan, Email: anas@example.com
User: Ninad Naik, Email: ninad@example.com

A Quick Note on tRPC

You might also hear about tRPC (TypeScript Remote Procedure Call). It is important to understand this is not a general-purpose paradigm like the others. tRPC is designed specifically for full-stack TypeScript applications, often in a monorepo. It allows you to share types between your backend and frontend, giving you end-to-end type safety. Your frontend can call backend functions as if they were local, with full auto-completion and type checking. It is extremely lightweight and offers an amazing developer experience, but it tightly couples your client and server and is only for the TypeScript ecosystem.

Mental Model: Ordering Food

To solidify these concepts, let's use an analogy: ordering food at a restaurant.

• REST is like ordering from a fixed menu. You go to the counter and say "I want the number 5 combo." You get exactly what the menu describes for the number 5 combo: a burger, fries, and a drink. If you do not want the drink (over-fetching), too bad, it comes with the combo. If you want an extra side of onion rings (under-fetching), you have to make a separate order.

• GraphQL is like a custom buffet where you give the chef a specific list. You go to a single counter and hand them a detailed note: "I want a burger patty, two slices of cheddar cheese, a toasted bun, a handful of lettuce, and three onion rings." The chef gets you exactly that, all in one trip. You get precisely what you need, efficiently.

• gRPC is like the high-speed, internal communication system between the restaurant's kitchens. It is not for customers. The kitchens use a special, highly efficient shorthand (Protobuf) and a pneumatic tube system (HTTP/2) to send precisely measured ingredients (binary data) to each other instantly. It is all about speed and efficiency for internal operations.

Step-by-Step: How to Choose Your Paradigm

When starting a new project, ask yourself these questions to guide your decision.

1. Who are the primary consumers of this API?

• Public / Third-Party Developers: Lean towards REST. Its simplicity, standardization, and vast ecosystem make it the easiest for external developers to adopt. The barrier to entry is low.

• Your Own Frontend Teams (Web & Mobile): GraphQL is a very strong contender. It decouples the frontend from the backend, allowing them to iterate faster. The efficiency gains are especially valuable for mobile clients.

• Internal Microservices: gRPC is the default choice here. The performance, strict contracts, and streaming capabilities are perfect for server-to-server communication.

• A Tightly Coupled Full-Stack TypeScript App: Consider tRPC for an unbeatable developer experience and end-to-end type safety.

2. What does your data look like?

• Simple, well-defined resources (CRUD-heavy): REST is a natural fit. Its resource-based model works perfectly for this.

• Complex, nested, or graph-like data: GraphQL excels. A social media feed with users, posts, comments, and likes is a classic use case.

• Actions and Commands: If your API is more about performing actions (archiveUser, calculateRisk) than managing resources, an RPC-style API like gRPC feels more natural.

3. What are your performance and network requirements?

• Standard Web Traffic: REST and GraphQL are generally sufficient.

• Critical Low Latency & High Throughput: gRPC is the clear winner. For applications like financial trading systems or real-time multiplayer game backends, every microsecond counts.

• Bandwidth Constrained Clients (Mobile/IoT): GraphQL provides fine-grained control to minimize data transfer. gRPC is also extremely efficient due to its binary format.

Trade-offs and Considerations

Key Takeaways

There is no "best" API paradigm. The right choice depends entirely on the problem you are solving.

As a developers, our job is to understand the trade-offs. Analyze your requirements and then pick the right tool. Building scalable systems starts with making these foundational architectural decisions correctly.

I'm a final-year CS engineering student, and like many of you, I've spent significant time preparing and attempting over 30+ online coding assessments on various programming websites—HackerRank, HackerEarth, SHL, et al. Over time, I’ve discovered quite a few loopholes and exploits in these platforms and even reported some of them to the respective platforms.

Later, in a series of different events that deserve its own blog post (coming soon.) I ended up interning at HackerRank! The first thing I wanted to do here? You guessed it: to work on fixing those loopholes. It was fun while I knew the various exploits and how to leverage them to game the online assessment, but it also made me the ideal person to test the platform and fix these loopholes continuously. So far, I’ve analyzed and reported over a dozen vulnerabilities while at HackerRank. Shameless plug: I'm that intern!
Lately, I started hearing the buzz around a tool called “Interview Coder”, promising to make cheating "undetectable”. I was more intrigued by the story of this 21-year-old dropout who made this tool. I immediately knew I had to check it out. So, I tested it out over a weekend on multiple online tests. Here’s what I found -

First Impressions of Interview Coder

The first thing you notice on Interview Coder’s website is the big “F*ck Leetcode” message. I thought that was pretty cheeky and frankly, I was glad that someone finally called it out given the fact that I’ve myself been very vocal about changing the traditional online assessments and have lobbied hard for having better assessments that allow the usage of AI and which simulate real-world problems instead of having candidates grind Leetcode-style problems.

However, it’s hard not to judge a tool explicitly designed to help people crack interviews while going to great lengths to stay hidden. Ethically, that doesn’t exactly fall into a “grey” area but rather a “pitch-black” area. Taking external help, whether AI or not, when the interview explicitly forbids it, is by definition, cheating. Just stating the obvious here, although I think neither the tool’s author nor the users have any disagreements or qualms about this. Yet, I’ve tried my best to be unbiased and evaluate this tool from the perspective of a candidate who wants to use this to cheat (for whatever reason) and see how effective or helpful it is.

Taking it for a spin

The installation process was relatively straightforward, requiring screen-sharing permissions. The interface seemed simple, with very few actions a user could take. I’m a big fan of minimalist design, so kudos on that. Almost all actions have keyboard shortcuts, which is also really helpful, especially to avoid raising suspicion in an interview. Pretty neat!

But then I noticed there was no "Forgot Password" flow! That’s strange. Even the most basic CRUD app tutorials cover this. If you happen to lose your hastily created password for the $60/month subscription, you’ll have to reach out to the author and wait for their reply! Hmm, this already looks more like a college undergrad’s hack than an actual product.

The UI also doesn’t display which account you're currently logged into. While this is not a deal-breaker, it is another example of the overall lack of polish and attention to detail.

I found the layout to be not very user-friendly. Most of the time, it worked, but sometimes, I had to scroll not just vertically but also horizontally, even for relatively short code snippets. A few times, I found it quite difficult to use, especially for Python one-liners, which are often truncated or require excessive scrolling. I accidentally discovered that zooming out on the overlay helps slightly, but you're still limited to viewing a certain number of lines.

Coming to the overlay, it's semi-transparent and you cannot even adjust it, it significantly blocks the view of the editor. I was forced to constantly toggle between the tool and the editor, or awkwardly position them side-by-side. This added a significant cognitive load, making it harder to focus on the actual problem.

At this point, I’m already quite disappointed by the tool. But then I realized, there's no obvious way to exit the app cleanly. This, combined with the fact that the tool hijacks your keyboard shortcuts, makes it difficult to resume normal work after the test.

Frequent updates further complicate things. Since the app isn’t visible in the dock, there's no obvious way to quit and update it, leaving you feeling stuck unless you manually kill the process.

Problem Solvability

The core of Interview Coder's functionality, the thing it's supposed to be good at, is solving coding problems. And in this, surprisingly it fails quite a lot. The reason is probably the fact that it is just a GPT wrapper, packaged in Electron, primarily utilizing (from the source code I have) Antrophic's Claude 3.5 Sonnet more specifically claude-3-5-sonnet-20241022. This means that any problem Claude struggles with, Interview Coder struggles with too.

System prompt and model found in the source code of webapp.

And that's a lot of problems in itself. Unseen questions, problems that deviate from the standard LeetCode ones, medium-to-hard problems involving trees or dynamic programming – these are all the areas where Interview Coder consistently falls short. In my testing, the only questions it reliably solved were those classic problems found in the LeetCode 150, which you would have probably known already if you were preparing for a technical interview. This is hardly surprising, given that LLMs are trained on vast datasets of - you guessed it, popular solutions readily available online. As of now, the tool doesn’t support non-coding questions. API and System Design, etc. I have noticed a shift in hiring where OAs now include SQL and API questions, and the tool falls flat in those areas.

While it allows for uploading multiple screenshots, the application froze for me each time I tried this. This happened to me repeatedly, forcing me to restart. The "debug" feature, which is supposed to help you fix your code, seems similarly broken. During my testing, it consistently caused the application to freeze, forcing me to start over and get a completely new solution, which also often didn't work.

But here's the real kicker: even when it does manage to generate a "solution," it's often presented in such a cryptic, convoluted way that it's difficult to understand, let alone explain to an interviewer. The variable names are generic, the code style is textbook-bland, and there's a heavy reliance on list comprehensions and other techniques that scream "LLM-generated." I've seen plenty of human-written code and LLM-generated code. Any interviewer (or plagiarism detection mechanism) would immediately flag this code as AI-generated and highly suspicious. No questions asked.

So, is it really worth the buck?

Now, let's talk about the pricing and boy, is this where things go from bad to worse. Interview Coder charges a whopping $60 per month for 50 credits! I think $60 is exorbitant for what is essentially a glorified GPT wrapper, one that struggles with anything beyond the most basic, well-trodden LeetCode problems. You could get far more value (and significantly better performance) by directly using newer Claude or GPT models with your own API keys, all while costing you a few dollars at most. Heck, Gemini 2.5 Pro is free – why not allow users to leverage that instead of forcing them into your expensive, server-dependent ecosystem?

Considering the number of times the tool gives incorrect answers, the credit system starts to feel like an intentionally designed “dark pattern.” Each wrong answer still costs you credits. You can burn through 10-12 credits in a single test, especially with restarts or the unreliable "debug" feature.

Additionally, there's absolutely no consumer protection:

1. No Free Trial: You can download and install but can’t log in and solve any problems until you buy it. There's no way to test the tool's effectiveness before committing to the exorbitant monthly fee.

2. No Refund Policy: If the tool doesn’t work on your machine, you can’t request a refund. There’s no clear information on which machines or OS versions are supported. In my testing, I encountered different results across various OS builds.

This doesn’t seem like a fair pricing model. Especially considering the fact that the users of this tool are primarily job seekers – often students – who are desperate to pass these interviews. It's particularly galling when you consider why it blew up because the initial builds of Interview Coder were open-source and allowed users to bring their own API keys. That approach made perfect sense: it eliminated the unnecessary server-side component, reduced costs, and gave users more control over their data and privacy. But somewhere along the way, the focus clearly shifted from providing a useful tool to maximizing ARR, resulting in this overpriced, underperforming mess.

Security Issues:

But here's where things get really interesting. The tool isn't so much built as it is “vibe-coded”, mostly using Cursor AI. Don’t get me wrong. I have nothing against “vibe-coding”. In fact, I do it a lot. But I do it mostly for building prototypes and quick hacks. I take comfort in the fact that if the auto-generated code doesn’t work, I’m fully capable of debugging and making it work. I’ll never blindly push the auto-generated code to prod and hope it works. I certainly won’t be charging people for the hacks thus created until I’ve polished them into “production-quality products”.

This is where Interview Coder differs. The security and authorization are lacking, to put it mildly. To demonstrate just how bad it is, I’ve attached a demo below – yes, the supposed $2M ARR project completely falls apart due to basic authentication failures. I can bypass the entire payment system with a few lines of code. This exploit should get patched, but I'm curious to see how long it takes the author to fix it.

The Hack:

This isn't some sophisticated exploit; it was right there in plain sight. The commit history of the project is also interesting. The author attempted to make the repository private, but couldn't due to the 2k+ stars, so he resorted to rewriting the commit history. But, he forgot about branches, pretty novice. Traces of previous versions, including API keys, were still accessible.

Other branches are still visible on the interview coder’s GitHub repo.

It's a clear demonstration of a lack of basic development skills, and security best practices. Earlier, the server component (interview-coder-webapp) was public too, and now it's not. With such major flaws, I find it hard to trust the tool with my systems’ screenshots that may contain screenshots of my interview with my face and sensitive information.

While I think it was a really cool idea and I would even have considered using the tool in some of my interviews, not because I think it’s ethically right, but just because I’m too bored to solve the problem myself, sadly it feels like a missed opportunity to build a reliable cheat tool.

The Real Cost of Shortcuts

But the problem isn't Interview Coder; it's the mindset, the idea that there's a quick fix, a way to "game the system" without actually putting in the work. And that, my friends, is a dangerous illusion.

Let's be brutally honest: using a tool like Interview Coder, even if it did work perfectly (which it emphatically does not), is a short-sighted strategy. You might, just might, manage to squeeze through an interview. But what happens next? What happens when you're faced with real-world challenges, complex codebases, and the pressure of delivering actual results? You'll be exposed. You'll be overwhelmed. And you'll have cheated yourself out of the opportunity to actually learn and grow. Simply clearing an interview doesn’t amount to much. I’m aware of many companies who have immediately fired candidates once they figured they were not as good on the job as they were in the interview.

The tech interview process is flawed, yes. We all acknowledge that. But the answer isn't to find more sophisticated ways to cheat; it's to advocate for a better system. A system that values genuine problem-solving skills, collaboration, communication, and the ability to learn and adapt.

What could better interviews look like?

So, while I agree with Roy that Leetcode-style interviews need an upgrade and I personally would enjoy a different interview setting, what could such an interview look like?

I personally appreciate companies who take the effort to dig into my existing coding chops even before the interview happens. They look at my side projects, and my GitHub activity and talk to me about those. They try to understand what I’m really passionate about. I don’t mind take-home tests, in fact, I think take-homes are much better than live pair programming since they take off the artificial time pressure from interviews and allow me to code in my natural zone.

A good interviewer would give me messy data and ambiguous requirements rather than abstract puzzles. I think the best way for companies to gauge my instant value-add to their team would be to just give me their repo and ask me to fix an actual open bug.

The most enjoyable interviews I’ve had were the ones where the interviewer acted more like my partner in solving a complex problem and brainstormed different ideas with me to arrive at a solution. If you can collaborate and communicate well with the interviewer you can be somewhat sure that you’d work well with the rest of the hiring team too when you work with them.

To Roy: A Plea for Responsibility

Roy, I won't sugarcoat it: Interview Coder is a bad product. It's poorly designed, not secure, and overpriced, and it promotes a fundamentally dishonest approach to the tech interview process. You're clearly a talented individual. You have the skills to build something genuinely useful, something that could actually improve the hiring landscape. Instead, you've created a tool that exacerbates the existing problems and preys on the anxieties of vulnerable students.

It's interesting to see the response to Interview Coder and similar tools from the community. New projects are emerging, aiming to detect and counteract these methods. It’s clear that this space is evolving rapidly. People want real solutions, not shortcuts that undermine the integrity of the interview process.

I urge you to reconsider your approach. Rethink, Interview Coder. Learn from this experience and use your skills to create something that improves the system rather than degrades it.

You've been pushing the narrative that the only way to crack interviews and land jobs at top companies is either two years of LeetCode practice or using your tool. I loved the marketing and the growth of it, but let’s not ignore the reality—your Columbia CS degree and years of LeetCode grinding played a huge role in your Big Tech offers. Selling the same dream to younger candidates is misleading, and frankly, harmful.

Final Thoughts

The tech interview process is a complex and often frustrating beast. But it's not insurmountable. And it's certainly not something to be "gamed" with shortcuts and cheating tools. The real key to success is to focus on building genuine skills, developing a deep understanding of fundamental concepts, and honing your ability to communicate and collaborate effectively. Invest your time and energy in becoming a better engineer. That's the only real shortcut to a successful career.

And as for me? I'll continue my work at HackerRank, and strive to create a fairer, more effective, and more meaningful assessment process (PS - y'all will see in some time). It's a long road, but it's a journey worth taking. Ultimately, we all benefit from a system that values genuine talent and integrity over the ability to memorize LeetCode solutions. Now, back to battling those exploits… and maybe finding a proper way to completely exit that darn Interview Coder app without restarting my machine.

Why am I sharing this? When I was preparing for the Software Engineering Internship role at Atlan, there weren’t many resources or detailed accounts available online. This gap inspired me to document my journey—both the highs and lows. So, without further ado, let’s dive in!

How It Began

Atlan’s internship wasn’t something I initially planned for. The opportunity was part of a program called the Atlan Engineering Fellowship, which they advertised on LinkedIn. I’d been following Atlan for some time because they recently had a Series C - funding round and when I looked at what it does I admired their work in data governance and engineering.

When I first came across the fellowship announcement, I was instantly intrigued. The application process was laid out neatly on their Notion-powered website (which shows how cool and organized the company is).

Every step of the process was mentioned with absolute clarity. The program included a one-week in-person onboarding in Delhi, offering opportunities to network, gain a certificate, and possibly secure an internship.

The fellowship was scheduled for October, It sounded like a great opportunity, so I filled out the application form and even reached out for referrals. Unfortunately, I couldn’t secure any referrals, but I proceeded with my application.

The Rejection (Twice!)

I applied in the first week of August. Shortly afterwards, I received an email on August 17th —a rejection. The email, though polite, was disappointing. I had spent time carefully crafting my responses, explaining why I wanted to work at Atlan, and sharing my experiences. Yet, they opted to move forward with other candidates.

Then came something unusual. On September 1st, I received another rejection email—yes, twice! This second rejection left me confused but also a little amused. I had no idea what was coming next.

A Surprise Shortlist

On September 5th, out of nowhere, I received an email from CodeJudge, congratulating me on making it to the next round. I was initially unsure about what it meant, but upon digging deeper, I realized it was related to my Atlan application.

The round involved a 30-minute coding test to be done before September 8th. It consisted of a single LeetCode medium-level question. I quickly solved the problem using a brute solution and fortunately was able to optimise it for all test cases in time.

The following day, on September 6th, I received a detailed report from Atlan with my test results. This transparency was refreshing—it’s rare for companies to share test results with candidates.

The Assignment:

Soon after, I received an email from Nanda, Atlan’s Hiring Lead, informing me that they had received my challenge and were looking into it. On September 11th, I received an email from the team asking if I needed help with the challenge. The email suggested that I was still working on it and encouraged me to reach out with any questions. This left me puzzled because I had only completed the coding test and wasn’t aware of any additional assignments. Seeking clarification, I responded, explaining that I had only received the coding test.

The next day, on September 12th, I got a reply informing me that I was supposed to have received another assessment.

However, life happened. My college exams coincided with this challenge, and the project felt overwhelming because of the timeline provided. Considering the effort required for just a four-day fellowship, I chose to step back and informed Atlan that I couldn’t complete the assignment.

The Assignment (Part 2):

After all hopes were lost, I received an email from them regarding the fellowship program. They mentioned having candidates from various examinations and asked if I could provide my availability for the program. I filled out the provided Google form where I indicated my availability. This interaction gave me the impression that they were still organizing and figuring things out on their end. Nonetheless, I promptly responded with my availability for the internship.

The Fellowship Evolves

A few days later, I received an exciting update: Atlan had restructured its program into a fellowship followed by a six-month internship, with the added benefit of full travel and accommodation for the onboarding week. This new format seemed incredibly appealing, and I was eager to dive in.

Excited about the opportunity, I reached out to request the assignment and got started right away. I dedicated all my time to designing, optimizing, and building the Personalized Travel Itinerary Generator.

I implemented a retrieval-augmented generation (RAG) model powered by Llama 3.2 LLM, ensuring the application delivered intelligent and dynamic itineraries tailored to user preferences. The RAG model had data from India’s top holiday destinations from a CSV file containing verified travel destination data sourced from Kaggle. This dataset has information about 300+ destinations, and user ratings, providing a rich source of information for generating personalized itineraries.

The process was meticulous—I focused on creating an intuitive frontend with React and backend using Python and FastAPI.

screenshot of my project landing page ^

I also prepared a comprehensive doc, detailing the application's architecture, decision-making process, and potential areas for future enhancement.

This project wasn’t just about meeting the requirements; it was about showcasing both creativity and technical skills. From design to deployment, I poured my best effort into making this application.

After completing the project, I submitted my work with high hopes. Given the effort and time I had invested, I eagerly awaited feedback.

However, days passed with no response. The lack of communication was unsettling. After dedicating so much to the project, the possibility of being ghosted was disheartening. I just wanted clarity, whether it was positive or negative.

I reached out multiple times via email every day, hoping for a reply 🫠

Despite the delays, I stayed optimistic, knowing that the effort I put into the challenge would eventually pay off.

After several days of waiting, I finally received a response. They were happy with my assignment and wanted to move things forward. After a few calls to coordinate my availability, 18th October was chosen for the next stage.

The Technical Interview: A Deep Dive

The first technical round was an intense one-hour session with Atlan’s senior engineers. The panel consisted of two engineers — one specializing in backend systems and the other in frontend development.

Backend Discussion

The interview started with a deep dive into my project. Interestingly, the interviewers hadn’t reviewed my submission beforehand, giving me the chance to explain everything in detail. They asked me questions about:

• System design: How I’d optimize the project, improve functionality, and enhance scalability.

• Database: Why I chose a particular database, how I would manage rate-limiting, and ways to cache responses efficiently.

• APIs: The logic behind my API integrations and their implementations.

While I confidently tackled most backend questions, I stumbled on a Redis-related query. My limited experience with Redis in production environments showed, but I owned up to it and did my best to answer.

Frontend Discussion

By this time, 45 minutes had passed, and they knew I was strong on the backend, so I hinted that my frontend skills weren’t as strong. The frontend interview focused on improving user experience and my design philosophy. They asked how I’d change a few things, optimize for older browsers, and enhance accessibility. While I didn’t know about concepts like polyfills and Babel at the time, I made a note to research them later. The interviewer explained these concepts well to me.

Towards the end of the interview, we discussed work-life balance at Atlan, the remote nature of the job, and how my day would look like. I loved how interns and SDE 1s are given the same exposure, responsibilities, and opportunities to explore.

The Managerial Round: A Candid Conversation

Nanda called to inform me that I had cleared the round, and he would like to schedule another half-hour interview.

Later that day, at 5:30 PM, I had a second interview — a managerial round with one of Atlan’s senior leaders, who had been with the founders even before Atlan was established when they were working on a different product. This session, which lasted over an hour, was one of the most candid and intense interviews I’ve ever experienced.

The interviewer dug into my personal and professional background, asking about:

• My family, upbringing, and values.

• My academic journey and internships.

• Feedback from previous roles and how I handled challenges.

• What I was hoping to gain from the internship at Atlan.

This round was less about technical skills and more about understanding who I was as a person. While the feedback I received was constructive, it left me feeling unsure about my chances. It was the most intense managerial behaviour round I had ever experienced, mainly because I wasn’t fully prepared for it. I would highly advise preparing thoroughly for this round. I was caught off guard in this round.

The Final Verdict

After Friday, Saturday, and Sunday, each day felt like it would never end, and I was anxiously waiting.
Finally, on Monday morning, I received a call from Nanda, congratulating me on being SHORTLISTED FOR THE INTERNSHIP!! 🥳🎉

The offer included the fellowship week in Delhi (November 4th–8th) and a six-month remote internship. I admire how Atlan, as a startup, constantly gathers feedback from its team members and acts upon it immediately. It’s not one of those situations where they say, "We'll consider it for the next batch"— they genuinely make changes right away, which is refreshing to see.

Reflecting on the entire experience, I have to say I’m impressed with Atlan. I love their website, the team, (esp. cooperative hiring manager Nanda and kind interviewers), and the fact that the company operates entirely remotely. Everything about Atlan resonates with me, from its innovative approach to its work culture. However, I had some personal commitments that prevented me from joining Atlan at that moment. While I’m disappointed that I couldn’t take part, I do not regret my decision—it was the right choice at the time. But if an opportunity arises again in the future, I would definitely consider working with Atlan. No hard feelings. This has been my fellowship and interview experience with Atlan.

Reflections and Key Takeaways

Looking back, this journey was a mix of emotions—excitement, confusion, and ultimately, gratitude. Here are some key lessons for anyone preparing for Atlan or similar opportunities:

• Persistence Pays Off: Despite initial rejections, staying engaged with the process opened new doors.

• Be Transparent: Communicate openly about challenges, such as deadlines or overlapping commitments.

• Skills Matter: They are looking for candidates with prior experience and those who have worked on relevant projects. If you lack that, come back more accomplished next time.

• Preparation is Key: Focus on both technical and behavioural aspects. Atlan values well-rounded candidates who can articulate their thought processes clearly.

  ---

fin~

If you’re considering applying, I encourage you to take the leap. Whether or not you make it, the process itself is a valuable opportunity to learn and grow. And who knows? It might just become the stepping stone to your next big adventure. At the very least, you’ll gain great experience and have an amazing story to tell, where all odds were against you.

Good luck, and feel free to reach out to me on LinkedIn.

I had planned to write a blog about this topic, but my current internship limits my time online, so I've put together this document instead.

Let me provide some context: This document is meant to give you an overview of how the interview process and shortlisting worked. It’s a quick summary based on my experience, along with some tips that might help improve your chances. Your results may vary, of course. I put this together quickly and used some language models to refine it, so if you spot any mistakes, please let me know so I can fix them. I’ve included various numbers and details that might help you evaluate your chances better.

For a different perspective, you can also check out Abhigyan's blog. He received a PPO as well and has written extensively about his experience.

I've organised this document into two sections:

• Gemini’s Version: This is a concise overview designed for a quick glance.

• The “10 Minute Version”: This section provides a more detailed, in-depth look with thorough and less polished information.

Gemini’s Version:

Timeline

• October 25th: General Mills formally reached out to our campus.

• November 9th: Pre-placement talk and online test.

• November 10th: Technical and Leadership Interviews for shortlisted candidates.

Day 1: Pre-Placement Talk and Online Assessment

Presentation

• My Experience: The Pre Placement Talk covered the company, its products, the Early Career Program (ECP), and the role after graduation.

• Actionable Items: Research the company, its products, and the ECP.

• Tips: Ask insightful questions during the Pre Placement Talk to demonstrate your interest and preparation.

Online Assessment (OA)

• My Experience: The OA was divided into technical and non-technical sections. The technical section focused on core computer science concepts, while the non-technical section covered logical reasoning, mathematics, and English grammar.

• Actionable Items:

  • Technical: Review core CS concepts, including OOPs, SQL, DBMS, OS, CN, and DSA.

  • Non-technical: Practice aptitude questions on websites like IndiaBix.

• Tips:

  • Manage your time effectively during the OA.

  • Don't spend too much time on any single question.

  • Make educated guesses if necessary.

Day 2: Interviews

Interview 1

• My Experience: This interview was heavily focused on technical and leadership skills. I was asked in-depth questions about my resume, projects, and technical knowledge.

• Actionable Items:

  • Know your resume inside out.

  • Be prepared to discuss your projects in detail, including the tech stack, architecture, and your contributions.

  • Review core CS concepts and be able to apply them to real-world scenarios.

  • Prepare examples of your leadership experiences.

• Tips:

  • Practice your communication skills.

  • Be confident and enthusiastic.

  • Demonstrate your passion for technology and your eagerness to learn.

7 were shortlisted for the second round.

Interview 2

• My Experience: This interview was conducted by a senior leader and HR. It focused on leadership, communication, and cultural fit. I was asked about my family background, interests, and ability to handle pressure.

• Actionable Items:

  • Prepare examples of your leadership and teamwork skills.

  • Articulate your career goals and how they align with General Mills' values.

  • Practice answering behavioural interview questions.

• Tips:

  • Be yourself and let your personality shine through.

  • Demonstrate your passion for the company and the role.

  • Ask thoughtful questions about the company culture and the team you'd be joining.

Results

• Out of over 300 applicants, only 2 were finally shortlisted and received offers.

• The selection process is highly competitive, so don't be discouraged if you're not selected.

• Learn from the experience and use it to improve your performance in future interviews.

Words of Wisdom

• Don't give up! There are plenty of other great opportunities out there.

• Statistically, it’s 1 in 150, a lot of you will go home disappointed, that’s part of growing up.

• Keep learning and growing. The more you invest in yourself, the better your chances of success in the future.

The “10 Minute Version”:

This section provides a more detailed, in-depth look with thorough and less polished information.

So starting off, as I can see General Mills reached out to us on campus last year on Oct 25th formally.

The email mentioned:

We are looking for:

• Strong analytical skills

• Technical Domain flexibility

• Learning agility

• Communication skills

• Ability to influence

And I can say the entire shortlisting process was very much aligned in this direction. Continue reading on to know more.

On 9th November 2023 - the pre-placement talk and online test

• Reporting Time: 1:30 pm Sharp

• Pre Placement Talk to start at 1:30 pm

• Test to start at 2:30 pm (College Campus)

10th November 2023 - Technical and Leadership Interviews for the shortlisted candidates

Pre Placement Talk

We started with a Pre-Placement Talk presentation. This covered what General Mills does and gave an overview of their Early Career Program (ECP), which is a new initiative similar to those at other Fortune 200 companies and common in Global Capability Centers (GCC).

We were part of the first pilot batch for this program. While the specifics of this program might not be relevant to you right now, I recommend paying close attention to the presentation. It will give you valuable insights into the company—its operations, the FMCG industry, its global impact, the countries it operates in, and its products. Most importantly, it will outline the ECP and what you can expect after graduation. This will help you understand whether the company and the program align with your career goals.

For me, it did make sense to get into a Fortune 200 and global leader in food company FMCG and I decided for summer it would be a good use of my time. During the presentation, I would encourage you to ask the right questions and how do you do that? Well, you should be prepared and have researched about what the company does. So a few videos on YouTube, a Wikipedia page of the company history, on top of it a few brands that they serve in the country and how they want to portray themselves on their official website. Once you see all of it, you'll get a better understanding and it will give you better judgement.

I didn’t focus on the stipend or other details because my research indicated that the overall opportunity was solid. The decision is yours.

Once the presentation talk is over, be ready for the fact that every round of the process is an elimination round. With over 300 people registered and shortlisted, we were given rooms for the subsequent stages. You’ll need to bring your laptop and complete the assignments on the Hire Pro platform within a college-proctored environment. Make sure you have the test link handy.

Carry your laptop for the exam; the lab setup will be communicated to you the day before. If you encounter issues like your Windows shutting down, battery problems, or pop-ups that disrupt your session, contact an in-charge immediately. Some candidates faced problems and left without seeking help, so it’s better to reach out and get your access reset if needed. This might be one of your first experiences with an online interview platform, and such technical issues can occur. Keep your laptop battery charged, disable notifications, and avoid changing tabs or engaging in any suspicious activity, as the platform is designed to detect and flag such actions.

Online Assessment

The assessment is divided into two main sections: technical and non-technical.

Technical Section: This part will focus on your core technical knowledge. While you’re unlikely to encounter coding problems, you should prepare for debugging problems, database management systems (DBMS), data structures and algorithms (DSA), computer networks (CN), operating systems (OS), object-oriented programming (OOP), and language syntax. Make sure you review these topics thoroughly.

Non-Technical Section: This section will cover a range of areas including logical reasoning, mathematics, permutation and combination, English grammar, and brain teasers. You’ll also find standard problems like reading comprehension, family relations, and interest calculations. Practising these areas will help you tackle the variety of questions in this part of the assessment.

You can practice aptitude-type questions on websites like IndiaBix, as recommended by my senior.

Tips :

For the technical section, having a solid grasp of the basics of a programming language is essential. If you’re familiar with C++ and understand pointers, memory addressing, and program compilation, you’ll be well-prepared. Additionally, ensure you’re comfortable with computer networks (CN), operating systems (OS), database management systems (DBMS), SQL, and data structures and algorithms (DSA).

Keep in mind that it’s impossible to master everything overnight. It’s helpful to have concise notes for quick reference. Some questions may be straightforward, like recalling a sorting algorithm, while others will require quick, critical thinking. This is where your knowledge will be most tested.

Time management is crucial during the assessment. If you’re stuck on a question, mark it and move on, then revisit it when you have more time or are able to solve it. If needed, make an educated guess. Given your background from JEE and CET, handling multiple-choice questions (MCQs) should be manageable.

In my experience, there were no coding-related DSA questions. I later learned from an ECP team member that this was intentional, and it made sense later for what they were looking for in a candidate.

Out of over 300 applicants, 29 were shortlisted for the next round.

Results were typically released by night, so be patient. The following day, you’ll be expected to come to campus for the interview rounds.

Day 2: Interviews

First Interview: Tech + Leadership

There were three panels, I was the first candidate interviewed on my panel, and my interview lasted nearly an hour. I faced two panellists who typed out everything I said, likely to evaluate and compare later. Their rapid typing might be a bit intimidating, but try to maintain eye contact with both of them to stay engaged.

The interview began with basic questions like “What do you do?” and “How are you?” and moved on to discuss the projects I had worked on. As the interview progressed, the questions became more standard and in-depth, covering various topics I will discuss next.

It was heavily focused on both technical skills and leadership qualities, as well as the attributes mentioned in the email—analytical skills, technology domain expertise, learning agility, communication skills, and leadership ability. They assessed exactly these parameters during the interview.

Here’s a golden rule of advice: know every detail of your resume inside out and be prepared to discuss each line for about ten minutes. For resume formatting, consider using popular templates like Deedy’s or Jake’s on Overleaf. If you haven’t created your resume yet, make sure to write it concisely in bullet points.

Your resume should include descriptions of your internship and project experiences. Be prepared to discuss every aspect, including tech stacks, the reasons for choosing MongoDB over SQL or relational versus non-relational databases, OOPS and Data Structures implementation in your project, the EER diagram of your project, the architecture, and your specific contributions. If you worked on only the front end of a project, and understand the entire project thoroughly, you’ll be expected to talk about it. I’ve seen candidates get eliminated for not knowing basic details about projects they claimed to have worked on because they only worked on front end and the rest is a black box to them. Don’t be that person.

There are a few key areas you should focus on:

1. Object-Oriented Programming (OOP): This is crucial, so make sure you’re comfortable with it.

2. SQL: Understand joins, different types of indexes, and views. Be solid on basic DBMS concepts and writing SQL queries.

3. Operating Systems: Know about scheduling algorithms and OS fundamentals.

4. Computer Networks: Be familiar with the OSI 7-layer model, IPv4, IPv6, and how DNS works.

5. Your Project: Know everything about the tech stack you used and the language, whether it’s compiled or interpreted, dynamic or static.

In addition to showcasing your technical skills, your resume should also highlight your leadership experience. During my interview, I focused on this aspect in the second half by discussing my hackathon wins and my role as a team leader. This demonstrated my leadership abilities.

You should be ready to talk about your learning experiences, the challenges you faced during these events, and how you solved problems under pressure. They’re interested in how you handle complicated situations, what you built, and what you achieved. Expect questions that explore these HR-type topics, as they’re keen to see how you manage real-world problems and lead effectively.

When discussing your projects, it's important to convey more than just the technical details. You should explain the motivation behind creating the project, not simply that you used a particular technology because it was taught to you or because you're familiar with it.

For example, detail why you selected a particular technology stack over another, what alternatives you considered, and why you ultimately chose this. Describe the problem you aimed to solve and the impact of your solution. Discuss how you built the project, including handling auth, the database used and how you deployed the project. It’s also valuable to explain how the application is used and what you learned from the process. This depth of understanding demonstrates not just your technical skills but also your ability to think critically and make informed decisions.

One insight I can mention is that because General Mills is an MNC, they also have a lot of legacy code. So when people come with Gen AI and more and web3 stuff, they seem to be quite fascinated, but because those are experienced people, they can easily identify if you are bluffing or you know the deal, stick to basics, but right ones. If you know fancy stuff, make sure you understand it well. One feedback I got after the hiring was done was that our college students were good with tech stuff.

Interviews for others typically lasted between 30 to 40 minutes, which was a good sign that I had a chance of moving forward.

About 20 minutes after my interview, the results were announced and updated in real time. Some candidates were put on the waitlist, some were rejected, and many were shortlisted. The second round of interviews began just 20 minutes after the first round concluded. It all happened so quickly that I didn’t even have time to call my mom and share the news before the next stage began.

7 were shortlisted for the next round.

Second Interview: Senior Management + HR

The second round of interviews is conducted by a senior leader from the DnT (Digital and Technology) team, along with an HR representative. Expect a mix of HR and technical questions.

This round will delve into various aspects, everything from tech before and now including your family background, your 10th and 12th-grade results, and your interests outside of tech. They’ll also assess your ability to handle pressure, your learning agility, and your leadership skills. You can demonstrate these through your committee work, hackathon experiences, or any other relevant activities.

Be prepared to discuss a broad range of topics, not just in-depth knowledge in one area. For example, despite my experience being primarily in web development, I was asked about Flutter and app development because it was part of my curriculum. My second-round interview lasted about an hour. The results were announced about an hour later, and it was quite tense.

After the second round of interviews, they announced the results with a small celebration. There were banners, and everyone got some gifts and goodies. It felt like a special moment as they revealed the final selections. I was thrilled to be among the chosen ones, along with Abhigyan. It really felt like a victory after all the hard work.

Some more stuff:

From what I’ve seen after talking to other interns at General Mills, the selection ratio remains consistent. Typically, around 2 or 3 people are shortlisted from each campus, and I expect that trend to continue.

For actionable advice, focus on improving your communication skills. While that’s something that takes time, you can prepare for standard questions right away. Practice your responses to questions about your introduction, hobbies, experiences, technical skills, projects, and leadership roles. Rehearse in front of a mirror, do mock interviews with friends, and reach out to others who have been through the process—they might offer valuable insights.

General Mills focused on key attributes in their hiring process, as outlined in their job description: strong analytical skills, technical domain flexibility, learning agility, communication skills, and the ability to influence. They weren't just looking for top competitive programmers; instead, they valued candidates who could make an impact, lead effectively, and contribute to a positive work culture. As a People-First organization, General Mills emphasizes these critical qualities over technical skills alone, recognizing that while technical abilities can be developed, behaviours and interpersonal skills are fundamental to their culture and success.

Believe in yourself and stay positive. Even if things don’t work out this time, remember there are always other opportunities, and they might even turn out to be better. For example, I was rooting for a guy who didn’t make it but ended up landing a fantastic position elsewhere. You never know what might come your way.

The key is to give it your best shot, learn from the experience, and prepare yourself for future interviews. Even if you make mistakes or feel like you didn’t perform well, it’s okay. Each experience will teach you something and better prepare you for the next opportunity. So stay diligent, work hard, and remember that every step in the process is valuable.

fin ~

Lastly, if you have any questions, need further advice, or want to discuss anything that I might have missed in this blog, feel free to reach out to me on LinkedIn or Twitter. Whether you need a 1:1 connect, a resume review, or just some additional insights, I'm here to help. I found that connecting with others and seeking help was beneficial in my journey, and I encourage you to do the same. Don’t hesitate to get in touch—I’m more than happy to help over the weekend!