I have attended IndiaFOSS for the past four years. It is one of the few conferences I plan to attend before I know the schedule, because the people and the conversations are reason enough to go.

This year, despite following the event and knowing that I wanted to be there, I forgot to buy a ticket.

At 12:40 am, I remembered that I still had to buy a ticket, but it was too late. The ₹1500 Late Bird tier was no longer available through the normal booking flow, and the next obvious option was a ₹3000 Regular ticket. By the time I was done, it was 1 am, hence the title "thirteenth hour" :P

Luckily, I had been experimenting with something earlier, and that gave me an idea that might work. Read on to find out what happened and, if you have not worked with payment integrations before, learn a little about them along the way. This is a case study and a practical introduction to payment orders, embedded checkout, server-side amount validation, signatures, callbacks, and fulfillment.

The Late Bird window had closed around forty minutes earlier.

A little background

I am a software engineer and tinkerer. I have worked with payment integrations before and usually get excited about that space.

At FamPay, I worked on fintech backend systems, including recharge and merchant-payment flows. At my last job at HackerRank, I worked across payments and other product areas, including subscription and checkout services using Razorpay and Stripe. I spent a fair amount of time building and debugging everything myself (a nightmare sometimes), so I had a little experience there.

I had also examined payment and webhook behavior while studying Interview Coder's source code. That allowed me to replay a webhook and get premium accounts for free. I wrote about it here: https://blog.anaskhan.me/decoding-interview-coder.

There was one more helpful coincidence. FOSS United's platform is built on Frappe, and I previously interned at Frappe Technologies. Once I found the relevant backend methods, their conventions were familiar.

None of this meant I knew the answer in advance. It meant I knew which questions to ask:

1. Had FOSS United already created a Razorpay order for ₹1500?

2. Was that order still payable after the ticket tier disappeared from the UI?

3. If payment succeeded, how did FOSS United verify and fulfill it?

The payment model: order, checkout, verification, fulfillment

Before describing what I changed, it helps to understand a standard Razorpay integration.

1. The merchant creates an order

The merchant's backend decides what the customer is buying and calculates the amount. It then asks Razorpay to create an order.

The order_id identifies a specific payment attempt. The amount is set when the backend creates the order. A customer should not be able to edit the page and turn ₹1500 into ₹15 because the trusted amount lives on the server and at Razorpay.

2. The browser opens Checkout

The frontend loads Razorpay's Checkout JavaScript and gives it the public merchant key and order ID.

const checkout = new Razorpay({
  key: "rzp_live_...",
  order_id: "order_...",
  name: "FOSS United",
});

checkout.open();

The key ID is public by design. It identifies the merchant account. The corresponding secret must remain on the server.

3. Razorpay returns a signed result

After a successful payment, Checkout returns three important fields:

{
  "razorpay_order_id": "order_...",
  "razorpay_payment_id": "pay_...",
  "razorpay_signature": "..."
}

The signature binds the order and payment together. The merchant backend verifies it using the private Razorpay secret.

4. The merchant fulfills the purchase

Only after verification should the application mark the payment as captured and provide the purchased item. For FOSS United, fulfillment means creating an event ticket, making the PDF available, and sending the confirmation email.

The order and payment move through related but separate state machines.

Stripe's PaymentIntent flow follows a similar separation, although the APIs and terminology differ.

The browser initiates the flow, but the backend and payment provider establish what was actually paid.

What the coding-agent experiment left behind

A couple of days back, I had asked my coding agent to navigate the ticket flow for fun. I wanted to see whether an agent could inspect availability, select the tier, fill attendee information, and reach checkout.

It reached the correct boundary: the Razorpay payment screen. The agent could prepare the transaction, but I still had to approve the payment.

By the time I returned after midnight, the official page no longer allowed me to select Late Bird. The unfinished flow had nevertheless created an order ID for that tier.

An order ID is not a payment link. It cannot be pasted into a browser by itself. However, it might be useful somewhere else. I just needed to figure out where. Since I had worked on similar embedded pages at HackerRank, I suspected that reconstructing the missing final screen without changing the order or its amount might work.

First, I needed to confirm how FOSS United implemented the flow.

Reading FOSS United's open source implementation

FOSS United is open sourced and its platform is hosted on GitHub. I followed the payment path through three files:

dashboard/src/pages/BuyTickets.vue
dashboard/src/components/common/RazorpayCheckout.vue
fossunited/api/dashboard.py

Server-side amount calculation

The first backend function I cared about was create_razorpay_order and the helper it used to calculate the total.

The implementation recomputed the amount using ticket-tier prices stored in the database. It also included optional T-shirt charges where applicable. It compared that server result with the amount provided by the client and rejected mismatches.

In simplified form:

amount = compute_order_amount(ticket_tiers, attendees)
client_amount = checkout_info["amount"]

if amount != client_amount:
    raise ValidationError("Amount mismatch")

order = razorpay.order.create({
    "amount": amount_in_paise,
    "currency": "INR",
})

The backend then stored a pending payment record containing:

• the Razorpay order ID

• the calculated amount

• the buyer email and billing information

• the selected tier and attendee metadata

• a Pending status

This was important for two reasons. I could not manipulate the browser into buying the tier for a different price, and the attendee information had already been associated with the pending order.

FOSS United recalculates the amount from database-backed tier prices before creating the Razorpay order.

Embedded Razorpay Checkout

Next I read RazorpayCheckout.vue. The component loaded Razorpay's Checkout script and created a popup using the returned public key and order ID.

Its success handler sent the Razorpay response to FOSS United:

handlePaymentSuccess(response) {
  post("handle_payment_success", {
    order_id: response.razorpay_order_id,
    payment_id: response.razorpay_payment_id,
    signature: response.razorpay_signature,
  });
}

This established that FOSS United used an embedded checkout, not a permanent Razorpay payment link for each ticket.

The distinction is useful:

FOSS United's original buy page was no longer able to recreate my Late Bird selection, but the embedded checkout itself only needed the existing order ID and public merchant key.

The official frontend opens Checkout with an order ID, then posts Razorpay's signed response to FOSS United.

Signature verification

Finally, I read handle_payment_success in the backend. It passed the order ID, payment ID, and signature to Razorpay's official verification utility. Only after successful verification did it update the pending payment to Captured.

In simplified form:

razorpay_client.utility.verify_payment_signature({
    "razorpay_order_id": order_id,
    "razorpay_payment_id": payment_id,
    "razorpay_signature": signature,
})

payment.status = "Captured"
payment.payment_id = payment_id
payment.save()

This was the security boundary. Calling the endpoint without a real payment would not work because I could not generate a valid signature. The experiment still required me to pay the exact amount attached to the existing order.

The backend verifies Razorpay's signature before marking the payment as captured.

Reconstructing the checkout page

After reading the code, I asked the agent to generate the smallest possible HTML page that mirrored the official Checkout component.

The page needed:

• Razorpay's Checkout.js script

• FOSS United's public Razorpay key ID

• the existing Late Bird order ID

• a handler that displayed the payment response

The core looked like this:

<!doctype html>
<html>
  <head>
    <script src="https://checkout.razorpay.com/v1/checkout.js"></script>
  </head>
  <body>
    <button id="pay">Pay ₹1500</button>
    <pre id="result"></pre>

    <script>
      document.querySelector("#pay").onclick = () => {
        const checkout = new Razorpay({
          key: "rzp_live_...",
          order_id: "order_...",
          name: "FOSS United",
          description: "IndiaFOSS Late Bird Enthusiast",
          prefill: {
            name: "Anas Khan",
            email: "...",
          },
          handler(response) {
            document.querySelector("#result").textContent =
              JSON.stringify(response, null, 2);
          },
        });

        checkout.open();
      };
    </script>
  </body>
</html>

No private credentials were present. This page could only ask Razorpay to open an order that FOSS United had already created.

I opened it locally, waited for it to load, and clicked Pay ₹1500. The UPI QR code showed up. I thought the payment might fail or the order might have expired, but I grabbed my phone and tried anyway. Surprisingly, it went through.

That confirmed the key hypothesis: the Late Bird tier had expired in the storefront, but the existing Razorpay order was still open.

A minimal local page reproduced the embedded checkout used by the official frontend.

Razorpay still recognized the existing ₹1500 order after the ticket tier had disappeared from the UI.

Completing the payment and callback

Then I made the real ₹1500 payment.

Once Razorpay captured the payment, I still wasn't sure whether I would get the tickets. I thought I might end up with a failure, which would have been a fun little mess. But, to my surprise, it worked. Here's what happened under the hood: two independent completion paths were available, a server-to-server webhook and a browser success callback. They carry different signatures and solve different reliability problems, but both reconcile the same pending order in FOSS United's database.

The webhook path

A webhook is an asynchronous HTTP request from one service to another when an event occurs. In this case, Razorpay can send FOSS United a payment.captured event after the charge is captured. This happens between servers and does not depend on my checkout tab remaining open.

The request includes the payment entity and its order_id. It also carries an X-Razorpay-Signature header. FOSS United computes an HMAC over the raw request body using the webhook secret configured in its Razorpay settings. If the signatures do not match, the event is rejected.

After verification, FOSS United's webhook handler:

1. Writes a webhook log for auditability.

2. Looks up the order_id in its Razorpay Payment table.

3. Ignores unknown orders rather than creating records from untrusted input.

4. Changes the matching payment from Pending to Captured for a payment.captured event.

5. Saves the document, triggering Frappe's on_update hook.

6. Creates the ticket only if one has not already been created for that payment.

Razorpay recommends webhooks as the reliable source of asynchronous payment state. If the customer closes the tab, loses connectivity, or never reaches the merchant's success page, the server can still reconcile the payment.

The browser callback path

Razorpay accepted it and returned the expected payload to my handler:

{
  "razorpay_payment_id": "pay_...",
  "razorpay_order_id": "order_...",
  "razorpay_signature": "..."
}

This is a separate Checkout signature, calculated from the order ID and payment ID using FOSS United's Razorpay key secret. The browser can carry the values, but it cannot generate a valid replacement signature.

Because this was a minimal page rather than the full FOSS United application, the normal post-payment experience did not complete cleanly. The popup remained visible and no ticket page appeared automatically. The payment result itself was available, though.

The official frontend would have posted those three fields to handle_payment_success, so I made the equivalent request manually:

curl 'https://fossunited.org/api/method/…handle_payment_success' \
  -H 'content-type: application/json' \
  --data-raw '{
    "order_id": "order_...",
    "payment_id": "pay_...",
    "signature": "..."
  }'

I did not manually trigger the webhook. I reproduced the browser success callback that the official FOSS United frontend normally makes after Checkout returns.

The endpoint returned HTTP 200 with an empty JSON object:

{}

That initially looked ambiguous, but it matched the Frappe method's implementation: it completed its work without returning a response object. There was no signature error, and the pending payment had been captured.

The callback and webhook can arrive in either order. A robust payment integration must expect that race. FOSS United converges both paths on the same Razorpay Payment document, and its ticket hook checks whether a ticket already exists for that payment before creating one. That makes fulfillment idempotent: replaying a valid callback or receiving the webhook later should not mint another ticket.

I then opened FOSS United's payment-success route with the order ID, payment ID, and event ID. The ticket appeared, I downloaded its PDF, and the confirmation email arrived a few minutes later.

Checkout returned the signed values needed by FOSS United's payment-success endpoint.

The request reproduced the callback made by FOSS United's official frontend.

The browser callback gives an immediate result while the signed webhook provides server-to-server reconciliation. Both converge on one idempotent fulfillment path.

After signature verification, FOSS United created the Late Bird ticket.

The regular confirmation email arrived a few minutes later.

Was this a security vulnerability?

Not in the usual payment-security sense.

Razorpay Checkout is designed to run in browser code. The merchant's key_id and a created order_id are therefore visible to the customer. Reusing those public values on another page does not expose FOSS United's private Razorpay secret, change the order amount, redirect the money, or produce a valid payment without actually paying.

The local HTML page was only another container for the same Razorpay Checkout that the official page used. Razorpay still charged the ₹1500 amount associated with FOSS United's order. FOSS United still verified cryptographic proof of the payment before creating the ticket.

It would have been a serious vulnerability if I could send an invented payment ID, forge a webhook, or call a success endpoint without paying and still receive a ticket. That was not possible here.

The part worth noting

There is still a business-rule edge case here.

FOSS United validates the tier, price, enabled status, expiry date, and inventory when it creates the pending payment record. Razorpay Orders themselves do not automatically expire. An order that was valid when created can therefore remain payable after the ticket tier disappears from the storefront.

Some organizations would accept that as an informal grace period for customers who began checkout before the deadline. Others would not want discounted inventory sold after the advertised cutoff. If FOSS United wants a strict deadline, it should add an application-level expiry to pending payments and re-check that policy before fulfillment, with a defined refund path for a late payment.

I would describe this as an order-lifecycle or business-policy gap, not a severe payment vulnerability. The important security controls still held: the amount was set server-side, the payment was real, both callback and webhook paths required valid Razorpay signatures, and fulfillment was tied to an existing order in FOSS United's database.

What about overselling?

The same stale-order behavior matters for inventory, not only deadlines.

Imagine a tier with 500 tickets. Customer A starts Checkout while ticket 500 is still available, so FOSS United creates a pending Razorpay order. Customer B completes payment first and receives ticket 500. If Customer A pays the old order afterward, the order amount and signature are still valid, but the tier no longer has capacity.

FOSS United currently checks maximum_tickets when it creates the pending payment. After each ticket insert, it counts sold tickets and disables the tier when the limit is reached. Those checks protect the ordinary path, but a pending payment does not reserve inventory. At capture time, ticket creation does not repeat the tier-capacity check before inserting the ticket. Disabling the tier after the count reaches its maximum also does not undo an insertion that has already happened.

There are two related cases:

A stale pending order after sellout

One order sits unpaid while other buyers consume the remaining inventory. A fulfillment-time validation can catch this: lock the event, count committed tickets, compare the requested quantity with maximum_tickets, and avoid issuing tickets if capacity is gone.

Concurrent captures for the last seat

Two payments can complete at nearly the same time. A simple implementation like this is not sufficient:

if count_existing_tickets() + requested <= maximum_tickets:
    create_tickets()

Both transactions might read 499, both decide that one seat remains, and both insert ticket 500. This is a classic time-of-check to time-of-use race.

The check and insertion need serialization. For example, fulfillment can acquire a database row lock on the ticket tier (or its parent event), then count and insert while holding that lock:

With serialization, the second transaction observes the first ticket before deciding. Another valid design is an atomic inventory counter or a short-lived reservation table, but both require more schema and lifecycle management.

The practical rule is: a Razorpay order reserves a payment amount, not a conference seat. Inventory reservation belongs in the merchant application.

A fulfillment-time capacity check must be serialized; otherwise two captures can both observe the same final seat.

Four ways to handle expired or stale orders

1. Rely on Razorpay order expiry

This is not available for Razorpay Orders. Razorpay documents that Orders are immutable and do not automatically expire. Its Checkout timeout option only closes a particular modal session; it does not invalidate the order. Payment Links support expire_by, but FOSS United uses Orders with embedded Checkout.

This can improve the user experience but cannot enforce a ticket deadline or inventory policy.

2. Reject fulfillment and refund manually

FOSS United could revalidate the tier after payment and refuse to create a ticket if it is expired or full. An operator could later refund the captured payment.

This is small, but it leaves the customer charged with no ticket until somebody handles the case. That is poor failure handling and creates unnecessary support work.

3. Store an application-level expires_at

When creating the pending payment, FOSS United could store an immutable expires_at value. It could be the tier deadline or a shorter checkout window, depending on policy. Fulfillment would reject and refund payments received after that timestamp.

This makes the policy explicit and avoids relying on a tier record that may be edited later. It requires a schema change, migration, and compatibility behavior for older payment records. It also does not reserve inventory by itself.

4. Revalidate at fulfillment and handle failures manually

Both the browser callback and Razorpay webhook already converge on the same Razorpay Payment.on_update hook before ticket creation. That is the smallest central place to revalidate:

• event ticket sales are still live

• every tier still belongs to the event

• tiers remain enabled and within valid_till

• enough inventory remains for the entire payment

• no ticket has already been created for this payment

For inventory, this validation must hold a database lock across the capacity check and ticket inserts. If any rule fails, FOSS United should not create tickets. The accepted patch leaves the payment captured, logs the failure, and lets the team handle the case manually under its transfer-only policy.

This fourth approach covers both expired orders and stale orders paid after sellout. With the event lock, it also closes the concurrent-capture race. Without the lock, it only narrows the window and does not guarantee that inventory cannot be oversold.

Before publishing this write-up, I sent the payment-flow fix upstream as FOSS United pull request #1698. My first version revalidated fulfillment, serialized capacity allocation, and automatically refunded captured payments that could no longer receive tickets.

The review changed that last part. FOSS United has a transfer-only policy and does not normally issue refunds, so the automatic refund worker and retry scheduler were removed. We also considered a 30-minute expire_by value, then dropped it after checking Razorpay's documentation: expire_by belongs to Payment Links and is rejected by the Orders API.

The parts that mattered most still merged on August 19:

• callback, webhook, and manual reconciliation use the same locked capture transition

• fulfillment locks the parent event row before rechecking event status, tier validity, and capacity

• replayed callbacks do not create duplicate tickets

• a late successful capture can recover a locally failed payment

• a failure callback cannot overwrite a payment that was already captured

• unfulfillable captures are logged and left for manual resolution under the transfer policy

That is the useful part of open-source review. I proposed one complete flow; the maintainers supplied operational context I did not have; we removed the pieces that did not fit their policy and kept the narrower fix.

A separate security review produced pull request #1704, merged on August 21. That PR was not the stale-order fix and it was not my code. It restricted guest ticket responses to an explicit safe field list, reduced data returned by ticket-transfer and tier endpoints, constrained accepted check-in filters, and sanitized IndiaFOSS speaker descriptions before rendering them as HTML.

Both merged changes are now in the FOSS United project and running in production, so it is safe to write about this publicly. Also, none of y'all can try the same thing and cause a headache for the team anymore. Please don't treat that as a challenge.

How far could this have gone?

My ₹1500 Late Bird order was not even the cheapest version of this. IndiaFOSS also had an ₹800 Enthusiast tier that closed on 30 June, according to the live stats. So, in theory, somebody could have opened checkout back then, paid nothing, kept the pending Razorpay order around, and completed the ₹800 payment much closer to the event, esentailly hoarding it until you feel comforatable or make plans to attend closer to the event dates.

To be clear, this would not turn a new ₹3000 order into an ₹800 one. The amount was fixed when FOSS United created the order. The trick, if you want to call it that, was simply keeping an old valid order alive after the website stopped selling that tier.

It could get messier with sold-out tickets. The pending order did not reserve a seat, but the old fulfillment path also did not recheck whether the tier had expired, been disabled, or run out of capacity. An old order could therefore have been paid after sellout and still created a ticket. Two payments landing together could even take the number of issued tickets beyond the limit.

The merged fix now locks the event and rechecks the ticket sale, tier, expiry, and available capacity before creating anything. If an old order no longer qualifies, no ticket is issued and the case is logged for the team to handle manually. So yes, no more fun for y'all.

Both payment-completion paths converge on one serialized validation step, followed by ticket creation or manual handling.

What made this possible

Three systems had related but distinct states:

The ticket-page deadline controlled whether a customer could create a new selection through the UI. It did not invalidate the payment order that had already been created.

Once I paid that order, the rest of the process remained valid:

1. Razorpay charged the amount already attached to the order.

2. Razorpay returned a signed payment result.

3. FOSS United verified the signature with its private secret.

4. FOSS United marked the pending payment as captured.

5. The stored attendee metadata was used to issue the ticket.

This was not a way to change the ticket price or create a ticket without payment. FOSS United's server-side amount calculation prevented the former, and Razorpay's signature verification prevented the latter.

It was an edge case in order expiry: the storefront stopped offering the tier before an already-created payment order stopped being usable.

Lessons for payment integrations

Treat the server-calculated amount as authoritative

The client can display a total, but the backend should derive the final amount from trusted products, tiers, discounts, and quantities. FOSS United did this correctly.

Define what happens to pending orders at a deadline

If a ticket tier expires at midnight, decide whether existing orders receive a grace period. If they should not remain payable, cancel or invalidate them and handle any delayed successful payments safely.

Verify payment results before fulfillment

A browser saying "payment succeeded" is not enough. Verify Razorpay's signature or consume a trusted webhook before creating tickets or entitlements.

Make success endpoints idempotent

Payment callbacks and webhooks can be retried. Repeating a valid callback for the same order should confirm the existing purchase, not create duplicate fulfillment.

Return useful completion data

An HTTP 200 with {} was valid but unclear. Returning a status and ticket identifier would make the integration easier to operate:

{
  "status": "captured",
  "ticket_id": "..."
}

Keep callbacks and webhooks conceptually separate

The browser callback improves the immediate user experience. The webhook provides server-to-server reliability if the browser closes or loses connectivity. A robust integration usually accounts for both.

Where the coding agent helped

The agent was useful for the mechanical parts of the investigation:

• querying the event API and reading ticket-tier data

• locating the relevant FOSS United source files

• generating the minimal HTML checkout page

• making and inspecting HTTP requests

• opening the success route and confirming the resulting ticket

The important reasoning still came from understanding the payment model. I knew why an order ID could outlive the page that created it, why embedding a public key was normal, why the private secret must remain on FOSS United's server, and why the signed result still had to be verified.

That combination worked well: prior experience supplied the hypothesis, open source supplied the exact implementation, and the coding agent reduced the time needed to test it.

Closing

I started with a simple mistake: after four years of attending IndiaFOSS, I forgot to buy this year's ticket on time. But I learnt an important lesson: do not give up, and keep tinkering around. In the process, I learnt a few things and contributed to open source in its truest fashion.

I have hidden all personal details, PII, and IDs, and used generic screenshots to stop people from recreating this on the platform. I tried to make sure the organizers would not have a bad time dealing with any of that, and I waited until the PRs were merged too. Please be nice to them, okay?

If this was useful and you are interested in open source, payment systems, or the people building both, come to IndiaFOSS 2026 in Bengaluru. I will be there.

Come say hi.

Anas Khan anaskhan.me

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!