It started as a product brief. Then became a competitor analysis. Then a slide deck outline. Then a series of emails. Then something for a completely different project.

I kept adding to it because I thought I was being efficient. Everything in one place. No need to re-explain context. Just scroll up and keep going.

I was doing the opposite of efficient.

When I finally deleted it and started over with a proper system, my outputs got better and my conversations got shorter. Both at once. That’s the thing about cleaning up how you work — the gains tend to stack.

Why long threads work against you

Every message you send, Claude re-reads the entire conversation history from the top.

That 200-message thread I had? By the end, Claude was processing weeks of context — old decisions that had been reversed, early drafts that had been replaced, questions about projects that were already finished — every single time I asked a new question.

That old context doesn’t just cost you. It competes with what you’re actually trying to do. The more unrelated history there is, the harder it is for Claude to give you a sharp, focused answer to your current question.

Starting a new conversation when topics shift isn’t starting over. It’s clearing the whiteboard so you can think clearly.

The context summary (the bridge between conversations)

The fear people have about starting fresh is losing context. And that’s fair — sometimes you’ve built up useful background over a long conversation.

The fix is simple: before you close a conversation you want to continue, ask Claude to summarize it.

Something like: “Summarize this conversation — what was the goal, what did we decide, what context I’ll need, and where we left off.”

Claude produces a tight summary. You paste it into your next conversation as the opening message. You pick up exactly where you were, with none of the noise.

Takes thirty seconds. Saves you from both the context loss problem and the bloated-thread problem at the same time.

Subscribe now

Projects: the thing most people skip

If you find yourself uploading the same document more than once, or re-explaining your role/tone/preferences at the start of conversations, you need Projects.

Here’s the difference:

In a regular conversation, every session starts from scratch. Files you upload get processed fresh each time. Instructions you give don’t carry over. Claude doesn’t remember what you told it last Tuesday.

In a Project, your files and instructions persist. Claude draws on them across every conversation in that project without you having to re-upload or re-explain anything.

If you’ve uploaded the same brand guidelines to five different chats. If you’ve typed “I’m a product manager and I need executive-ready language” more than twice. If you keep sharing the same report to ask different questions about it — that’s a Project.

Set it up once. Save yourself every time after that.

The five habits (the ones that actually stick)

After all the experimentation, this is the system:

Match the model to the task. Sonnet for most things. Haiku when it’s quick and simple. Opus when you genuinely need more.

Write prompts that specify context, task, format, and constraints. Not all four every time — but at least two of them, always.

One topic per conversation. Change topics, start fresh. Use the context summary trick to bridge conversations cleanly.

Use Projects for anything you’ve done more than twice. If you’ve re-uploaded it or re-explained it, it belongs in a Project.

Share only what’s relevant. Twenty pages when you need one section is twenty pages Claude processes for no reason. Give it what it needs, nothing more.

None of these are hard. Together, they compound into something that feels meaningfully different from the way most people use AI.

The real shift

The way most people use Claude is the same way people used Google when it first came out — type something in, see what comes back, type something else.

That’s not wrong. But it’s leaving most of the capability on the table.

Claude is a thinking partner. The better you set up the conversation, the better the thinking you get back. The cleaner your system, the more useful every session becomes.

That’s the whole thing. Tokens, models, prompts, clean conversations, projects. Five habits. None of them complicated.

Start with one this week. The rest follow naturally.

“Write me a summary of this document.”

That’s it. That’s the whole thing.

Then people are surprised when the output is... okay. Not bad. Just okay. Generic. Like something a capable intern would produce on their first day when they don’t quite understand the context yet.

The reason isn’t Claude. The reason is the prompt.

Why vague prompts produce vague answers

Claude is a language model. It works with what it’s given. When you give it nothing but a task and a document, it has to make a lot of decisions on your behalf — about tone, length, audience, focus, format, what to include, what to leave out.

Claude will make those decisions. It’s good at making them. But they’re its decisions, not yours.

And when you read the output and it’s not quite right, there’s usually a round of back-and-forth: “actually make it shorter,” “the tone is too formal,” “can you focus more on the recommendations section.” Each one of those follow-up messages costs you. And most of them could have been avoided by being clear in the first place.

There’s a four-part structure that fixes this. You don’t need all four every time — even two or three dramatically outperforms an open-ended ask.

The four parts

Context — who you are and why you’re asking. Not a biography. One line. “I’m a product manager writing for a non-technical executive audience” tells Claude more than you’d think.

Task — what you actually want. Be specific. “Summarize” is vague. “Give me the three most important takeaways in plain language” is not.

Format — how you want it delivered. Bullet points or prose? 200 words or 500? Should it start with the conclusion or build to it? Claude will default to something reasonable, but reasonable isn’t the same as right for your situation.

Constraints — what to avoid. This is the most underused part. “Don’t use jargon,” “skip the background context, I already know it,” “no bullet points” — constraints narrow the space and almost always produce sharper outputs.

The edit trick most people never use

This one’s small but it changes things.

When your prompt doesn’t land the way you expected, most people add a follow-up message to clarify. That’s the natural instinct. But it means Claude now has to reconcile your original prompt with your correction — and the conversation gets longer and murkier.

Instead: click the edit icon on your original message, fix the prompt, and resubmit.

Claude sees a clean, corrected version of your ask. The conversation history stays tight. The output is almost always better.

It sounds minor. It’s not.

Subscribe now

Keeping the conversation clean

There’s a habit that costs people a lot without them realizing it: keeping one conversation open all day and adding everything to it.

It feels efficient. One place. Everything’s there.

What’s actually happening: Claude is re-reading the entire conversation history every single time you send a message. By message 50, the early context from this morning — when you were working on something completely different — is competing with what you need right now.

Long conversations don’t just cost more per message. They also produce worse outputs because Claude is processing a bunch of irrelevant history alongside your actual question.

The rule I use: one topic, one conversation. When I shift to something new, I open a fresh thread.

If I need context from the previous conversation, I ask Claude to summarize it first — “give me the key decisions and context from this conversation in a few bullets” — then paste that summary into the new thread and continue. Thirty seconds. Works every time.

The one habit from this article

Before you send your next Claude message, take ten more seconds to add one of the four parts — just one. Format, constraints, audience, specifics. Pick whichever feels most missing.

You’ll notice the difference immediately.

One task. Forty-three messages. She’d pasted the same report three separate times.

She wasn’t doing anything wrong exactly. But she was spending a lot more than she needed to — and had zero awareness of it. That’s the part that bothered me. Not the waste. The blindness.

So let me fix that for you in about five minutes.

What Claude is actually reading

When you type a message, Claude doesn’t read words. It reads tokens — basically chunks of about three-quarters of a word each.

Your message? Tokens. Claude’s response? Tokens. That document you uploaded? Tokens. Every single message from the beginning of your conversation? Also tokens, re-read from scratch every single time you hit send.

That last part is the one most people miss.

Claude doesn’t just see your latest message. It re-reads the entire conversation history on every turn. That 40-message thread you’ve been running since Tuesday morning? Every new message you send costs more than the last one, because the history keeps growing.

Here’s the practical version of this: a focused 10-message conversation about one thing is significantly cheaper and usually produces better results than a 60-message conversation that drifted across five different topics.

The model you pick matters more than you think

Most people open Claude and just... start typing. They don’t touch the model selector. That’s leaving a lot on the table.

There are three Claude models, and they’re not interchangeable. Think of them like this:

Sonnet is your everyday driver. Fast, capable, handles 90% of what you’ll throw at it. This is where you should live most of the time.

Haiku is for when you need something quick and the task is genuinely simple. A short summary. A quick reformat. Don’t overthink it.

Opus is the heavy machinery. It’s the most capable and it costs the most. Use it when you genuinely need depth — complex analysis, nuanced writing, hard problems. Not for “can you clean up this email.”

The mistake most people make isn’t using Opus when they shouldn’t. It’s defaulting to Sonnet for everything including the 30-second tasks that Haiku would handle just as well in half the time.

Match the tool to the job. Every time.

The thing nobody tells you about “just asking Claude”

When you ask a vague question, Claude tries to be helpful. That sounds fine until you realize what “trying to be helpful” actually means — Claude fills in the blanks with its best guess, which often means longer, more exhaustive answers than you needed.

Ask for “a summary” and you might get 800 words. Ask for “an analysis” and you might get a structured report with headers and subheadings and a conclusion section.

None of that is Claude being bad at its job. It’s Claude doing exactly what you asked — just not what you meant.

And here’s the frustrating part: if the output isn’t what you needed, you now have to spend more to fix it. Every regeneration, every follow-up, every “actually can you make it shorter” — that all counts.

Getting clearer upfront is the highest-leverage habit you can build. Not smarter prompts. Not better tools. Just: knowing what you want before you ask.

The short version

Three things that will immediately change how you use Claude:

Stop running marathon conversations. One topic, one thread. When you shift topics, start fresh.

Check the model selector. Sonnet for most things. Haiku for quick tasks. Opus when you genuinely need it.

Understand that vague inputs create expensive outputs. More on exactly how to fix that — next week.

Next: The exact prompt structure that cuts your back-and-forth in half — and the weird trick of editing your message instead of replying to it.

Let me say the quiet part out loud: most people don’t quit because they should. They quit because they had a bad week.

A rough sprint. A manager who snapped at them in standup. A deploy that went sideways on a Friday night. And suddenly they’re refreshing job boards at 1am, ready to throw it all away.

Don’t do that. A bad week is not a sign. A bad year is.

So before we talk about how to switch, let’s get honest about when.

When you should actually leave

You’ve stopped learning. Six months go by and you realize you haven’t picked up a single new thing. The work feels like a rerun. That’s the real alarm bell — not the salary, not the title. Growth.

You’re badly underpaid and they won’t fix it. Not “I want more.” I mean you looked at the market, you asked, and they shrugged. That shrug is your answer.

You dread it. Not on Monday morning — everybody hates Monday a little. I mean a low, constant hum of “I don’t want to be here” that doesn’t go away no matter how good the week is.

Your manager is the ceiling. If the person above you can’t grow you, protect you, or get out of your way, and that’s not changing — you’ve already hit the wall. You just haven’t admitted it yet.

If two or three of those are true at once, stop reading job advice and start applying.

When you should stay (for now)

Here’s the part nobody tells you: sometimes the smartest move is to not move.

Don’t leave right after you shipped something huge. That’s the thing you ride to a promotion. Cashing out a day before payday is foolish.

Don’t leave just because you’re bored, if you haven’t actually asked for harder work. A lot of “I’ve outgrown this” is really “I never raised my hand.” Try the conversation first. You’d be surprised.

And please — don’t run from a problem. If the issue is something you’re carrying (you’re disorganized, you avoid hard feedback, you burn out by overcommitting), it’s coming with you to the next place. New logo, same problem.

The good reason to leave is that you’re walking toward something better. The bad reason is that you’re sprinting away from something uncomfortable.

How to switch without setting yourself on fire

Okay, you’ve decided. Here’s how to do it like a professional and not like someone who watched a quit-tok video.

Interview while you’re still employed. Always. You negotiate from strength when you have a paycheck and weakness when you don’t. Never resign first and figure it out later.

Get the offer in writing before you tell a single coworker. Not your work bestie. Not anyone. Things leak, deals fall through, and you don’t want to be the person who announced a departure that didn’t happen.

Negotiate the offer. Every time. The first number is rarely the best number, and the worst they can say is “that’s our max.” You lose nothing by asking and you’ll often gain more than a year of raises would have given you.

When you do resign, keep it short and kind. No speech. No list of grievances. “I’ve accepted another opportunity, I’m grateful for my time here, and I’ll do everything I can to hand things off cleanly.” That’s it.

Then actually hand things off cleanly. Document what’s in your head. Don’t coast for two weeks. The last impression is the one people remember, and our industry is smaller than you think — your tech lead today is interviewing you somewhere in five years.

And whatever you do, don’t trash the place on your way out. Not in the exit interview, not on LinkedIn, not in the group chat. The world keeps receipts.

The one line to remember

Switch when you’ve stopped growing — not when you’ve had a bad day. And leave the way you’d want someone to leave you: warm, clean, and without burning the house down behind them.

The door you close gently is the same door you might need open again.

I’ve watched a stupid number of low-level design interviews. From both sides of the table. And the thing nobody tells you is that LLD isn’t really a knowledge test. You’re not going to get rejected because you forgot the difference between the Strategy and State patterns. You’re going to get rejected because forty minutes in, the interviewer still can’t tell whether you actually know how to think in objects, or whether you just memorized “Parking Lot Solution” off some PDF and prayed they’d ask that exact one.

So let me save you the months of confusion I went through. This is how LLD interviews actually work, and how to not blow them.

First, understand what they’re buying.

HLD asks “can you architect a system that doesn’t fall over.” LLD asks “can I trust you to write the actual classes my team will maintain for the next four years.” That’s it. The whole interview is the interviewer trying to figure out if your code would be a pleasure or a nightmare to work in. Every decision you make is read through that lens. When you make a class do six things, they’re imagining the pull request. When you hardcode a payment type instead of leaving room for new ones, they’re imagining themselves six months from now, cursing your name.

Once you internalize that, the prep gets a lot simpler, because you stop trying to memorize solutions and start building taste.

Don’t start with classes. Start with the conversation.

The single biggest mistake I see is people hearing “design a vending machine” and immediately drawing a VendingMachine class. Stop. You don’t even know what they want yet. Does it handle refunds? Multiple currencies? Is it one machine or a fleet reporting to a server? Spend the first five minutes pinning down scope out loud. “I’m going to assume single machine, cash only, no networked inventory — sound right?” This isn’t stalling. It’s the actual job. Senior engineers are the ones who ask the right questions before writing a line, and the interviewer knows it.

And here’s the part people miss: nailing scope also protects you. If you’ve explicitly agreed the design is cash-only, you can’t get ambushed twenty minutes later for not handling credit cards. You set the boundaries.

Find the nouns. Seriously, that’s the trick.

After you’ve scoped it, talk through the problem in plain English and listen for the nouns. “A user puts money into the machine to buy a product from a slot.” There are your candidate classes, sitting right there in the sentence. The verbs become your methods. This sounds almost too simple but it’s exactly how experienced people find the entities fast. You’re just turning the requirement into objects, then asking which objects own which behavior.

The mistake juniors make is putting all the behavior in one god class. The machine knows the price, the machine does the dispensing, the machine validates the money, the machine tracks inventory. Now you’ve got a 600-line class and a sad interviewer. Spread the responsibility. The Inventory knows about stock. The Product knows its own price. The machine just coordinates. That’s the whole game.

Patterns are seasoning, not the meal.

I need to be blunt because people get this so wrong: do not walk in trying to shoehorn five design patterns into your answer to look smart. It reads as exactly what it is. Patterns should emerge because the problem demanded them, and you should be able to say why.

The honest truth is that most LLD problems only ever need a handful. When behavior changes at runtime, you reach for Strategy — a vending machine that takes cash now and cards later wants a PaymentStrategy, not an if-else ladder. When something has distinct modes that change how it responds, that’s State — the vending machine literally has states (idle, money inserted, dispensing) and modeling them as a State pattern is gorgeous and the interviewer will love it. When you need to create objects without hardcoding their concrete type, Factory. When something needs to notify others when it changes, Observer. Learn those four cold and why each exists, and you’ll handle ninety percent of what’s thrown at you. Knowing twenty patterns shallowly is worse than knowing four deeply.

SOLID isn’t an acronym to recite. It’s a smell test.

You don’t need to define SOLID in the interview. You need to use it so naturally that the interviewer notices. The two that actually carry the weight are the S and the O. Single Responsibility — does each class have one reason to change? Open/Closed — when a new requirement comes in, can I add a class instead of editing existing ones? If your design means “to add Apple Pay I just write one new class and touch nothing else,” you’ve basically already won. Say that out loud. “I’m structuring it this way so adding a new payment type later is a new class, not a rewrite.” That single sentence signals more seniority than any pattern name you could drop.

Now actually write something.

Talk is cheap and at some point you have to put real classes on the board. Don’t write full method bodies for everything — nobody cares about your getters. Write the interfaces, the key class signatures, the important relationships, and then implement the one or two methods where the actual logic lives. For a vending machine, I want to see how insertMoney and dispense work and how state transitions. The rest I’ll trust you on. Show judgment about what matters. Spending ten minutes typing out a constructor is how you run out of clock with the interesting parts undone.

Think out loud the entire time, even when it feels dumb.

This is the cheat code. The interviewer cannot read your mind. If you sit silently for two minutes drawing the perfect class diagram, they have no idea if you’re a genius or stuck. Narrate the tradeoffs. “I could make this an enum but if I think these payment types will each have their own validation logic, an interface is cleaner — let me go with the interface.” Now you’ve shown you considered the alternative and had a reason. That’s the difference between someone who memorized an answer and someone who can design. They’re hiring the reasoning, not the diagram.

How to actually prepare, in order.

Don’t grind fifty problems. That’s the LeetCode brain leaking in and it doesn’t work here. Pick about eight to ten classic problems and do them properly — Parking Lot, Vending Machine, Elevator, Splitwise, BookMyShow / movie booking, an LRU cache, a logging framework, a rate limiter, maybe Snake & Ladder or a card game for the OO modeling reps. The reason this small set is enough is that they recycle the same underlying skills. Splitwise and BookMyShow are both really about entity relationships and a couple of well-placed strategies. Once you’ve felt the patterns repeat, a brand-new problem stops being scary because you recognize the shape.

For each one, don’t just look up the solution. Solve it, then go find a good solution and ask “what did they see that I didn’t?” That gap is where your taste grows. And write the code. Actually write it, compile it, feel where your own design fights you. You learn that a class has too many responsibilities only when you try to instantiate the thing and it needs nine constructor arguments.

The mindset that ties it together.

Walk in like a senior engineer pairing with a colleague on a design, not a candidate being quizzed. Ask, scope, find the nouns, assign responsibility cleanly, leave the door open for change, narrate your reasoning, and write the parts that matter. Do that and it almost doesn’t matter which problem they pick. You’re not performing a memorized solution — you’re showing them what it’d be like to have you on the team.

That’s the whole thing they’re paying for.

A design pattern isn’t a library you install or a chunk of code you paste in. It’s closer to a recipe. It’s a proven way of structuring your code to solve a problem that keeps showing up. Someone hit the wall before you, figured out a clean shape for the solution, gave it a name, and now the rest of us get to skip the painful part.

The reason they matter goes beyond “good code.” Patterns are a shared vocabulary. When a teammate says “let’s just use a Factory here” or “wrap it in an Adapter,” that’s three words doing the work of a whiteboard session. Everyone instantly knows the shape of what’s being proposed. That alone is worth learning them.

Most of the classic patterns come from a 1994 book by four authors everyone calls the “Gang of Four.” They catalogued 23 of them and split them into three buckets based on what the pattern is actually doing. That grouping is still the cleanest way to think about it.

The three categories

Creational patterns are about how objects get made. Sometimes new SomeClass() is fine. But when object creation gets complicated — lots of setup, conditional logic, needing exactly one instance — these patterns give you cleaner ways to handle it.

Structural patterns are about how objects and classes fit together. They help you compose bigger structures from smaller pieces without everything turning into spaghetti.

Behavioral patterns are about how objects talk to each other and split up responsibility. This is where most of the “who’s in charge of what” questions get answered.

Here’s the full list, grouped, with what each one is actually for.

Creational (5)

• Singleton — Guarantees a class has only one instance and gives everyone a single point of access to it. Think config managers or a shared connection pool.

• Factory Method — Lets a class defer the decision of which object to create to its subclasses. You ask for a thing; the subclass decides the exact type.

• Abstract Factory — Creates whole families of related objects without you having to name their concrete classes. Useful when things need to match, like UI widgets for a specific theme.

• Builder — Constructs a complex object step by step. Great when an object has a ton of optional parameters and the constructor would otherwise look like a phone number.

• Prototype — Creates new objects by cloning an existing one instead of building from scratch. Handy when setup is expensive and you just want a copy.

Structural (7)

• Adapter — Makes two incompatible interfaces work together, like a translator sitting between old code and new code.

• Bridge — Splits an abstraction from its implementation so the two can change independently without exploding into a mess of subclasses.

• Composite — Lets you treat a single object and a group of objects the same way. This is the pattern behind tree structures like file systems.

• Decorator — Adds new behavior to an object at runtime by wrapping it, instead of cramming everything into one giant class.

• Facade — Hides a complicated subsystem behind one simple interface. The customer doesn’t need to see the kitchen.

• Flyweight — Shares common data between many similar objects to save memory. Think rendering thousands of trees in a game that all reuse the same texture.

• Proxy — Stands in for another object to control access to it — for lazy loading, caching, permission checks, that kind of thing.

Behavioral (11)

• Chain of Responsibility — Passes a request along a chain of handlers until one of them deals with it. Middleware in web frameworks works exactly like this.

• Command — Wraps a request as an object, which makes things like undo, queuing, and logging easy.

• Interpreter — Defines a grammar and a way to evaluate it. You’ll mostly see this in parsers and simple query languages.

• Iterator — Lets you walk through a collection one item at a time without caring how it’s stored underneath.

• Mediator — Puts all the messy communication between objects into one central place instead of letting everything talk to everything.

• Memento — Captures an object’s state so you can restore it later. This is your save-game / checkpoint pattern.

• Observer — Lets objects subscribe to another object and get notified when it changes. Event systems and reactive UIs live here.

• State — Lets an object change its behavior when its internal state changes, so it almost looks like it switched classes. Cleaner than a pile of if-statements.

• Strategy — Defines a family of interchangeable algorithms and lets you swap them at runtime. Different sorting or payment methods, picked on the fly.

• Template Method — Lays out the skeleton of an algorithm and lets subclasses fill in specific steps without changing the overall flow.

• Visitor — Lets you add new operations to a group of objects without modifying the objects themselves.

A quick word of caution

Here’s the thing nobody tells you early enough: patterns are tools, not trophies. The fastest way to write bad code is to learn these and then go looking for excuses to use all of them. Half the time the right answer is a plain function and no pattern at all.

The real skill isn’t memorizing the 23. It’s recognising the problem shape in front of you and remembering “oh, this is the kind of thing Strategy solves” or “this smells like an Observer situation.” The names are just the index. The judgment is the actual job.

So don’t try to swallow the whole list tonight. Pick a few you keep bumping into — Factory, Strategy, Observer, Adapter, Decorator are the everyday ones — and watch for them in the codebases you already work in. They’re hiding in there. Once you start seeing them, you can’t unsee them, and that’s when the names finally click.

Every developer hits this moment: you need two systems to talk, you open your editor, and you default to REST because that’s what you always do. Sometimes that’s right. Sometimes it quietly costs you later.

APIs aren’t one-size-fits-all. Different problems call for different types, and knowing which is which is the difference between an integration that just works and one you’re rewriting six months in. Here’s the full map — what each type is, when to use it, and a real example.

Open APIs

What it is: Publicly available APIs that any developer can integrate with, usually self-serve with an API key.

Use it for: Weather data, login systems, product catalogs — anything you want the outside world to build on top of.

Example: Google Maps, Stripe. You sign up, grab a key, and start calling. The point is discoverability and easy onboarding, not “no authentication” — you still get rate limits and billing.

Under the “open” umbrella, you’re really choosing a style:

REST API

What it is: HTTP-based, resource-oriented, stateless, usually JSON.

Use it for: Roughly 90% of modern web and mobile apps. It’s the universal default for a reason — every language and client speaks it, and it caches well.

Example: A mobile app fetching a user’s profile or a list of products.

SOAP API

What it is: XML-based, strict schemas, formal contracts, built-in standards for security and transactions.

Use it for: Banks, insurance, government — domains where rigor and guaranteed message integrity matter more than developer convenience.

Example: Processing an insurance claim or a wire transfer, where the contract can’t be ambiguous and the security model is non-negotiable.

GraphQL API

What it is: A single endpoint where the client asks for exactly the fields it needs — no more, no less.

Use it for: Complex, deeply related data, especially when multiple frontends (web, iOS, Android) each need a different slice.

Example: A social feed pulling only the posts, names, and thumbnails it needs in one request, instead of three round-trips to three REST endpoints.

Internal APIs

These never leave your own system. They’re how the pieces of your architecture talk to each other, and because they’re private, you get more freedom in how you design them.

Backend to Backend

What it is: Internal services calling each other.

Use it for: Microservice architectures, where responsibilities are split across services.

Example: Your auth service handing off to the user service, which calls the payment service. (This is also where high-throughput protocols like gRPC earn their keep — internal traffic at scale doesn’t need to be human-readable JSON.)

Frontend to Backend

What it is: Your UI requesting data from your server.

Use it for: Basically every interaction in a web or mobile app.

Example: A user logging in, running a search, or updating their profile.

Service to Database

What it is: Your backend reading from and writing to its data store.

Use it for: All your core data operations.

Example: Storing a new user record or fetching a customer’s order history. (Worth noting: this usually happens through a driver or ORM rather than a “real” API, but conceptually it’s the same layer in the stack.)

Partner APIs

What it is: Controlled access for a known set of trusted external parties — gated, contractual, and SLA-backed.

Use it for: Affiliate programs, reseller systems, B2B integrations where there’s a real relationship behind every key.

Example: Amazon’s affiliate tracking, or a travel site pulling live hotel and airline availability from partners.

B2B Integration

What it is: Direct system-to-system data exchange between businesses.

Use it for: Booking platforms, payment gateways, supply chain coordination.

Example: A travel app hitting an airline’s API for seat availability and a payment gateway to close the sale.

Data Sharing API

What it is: A partner API built specifically for the secure exchange of sensitive data, with compliance baked in.

Use it for: Health records, financial data, logistics tracking — anywhere the payload is regulated.

Example: Two hospital systems exchanging patient records under strict access controls and audit trails.

The Decision Framework

You don’t need to memorize all of this. You need two questions:

Who’s calling it?

• The public → Open API (REST by default)

• Trusted business partners → Partner API

• Your own systems → Internal API

What does the workload look like?

• Simple, universal, cacheable → REST

• Complex, relational, many clients → GraphQL

• Enterprise, legacy, high-trust → SOAP

• High-volume internal traffic → backend-to-backend (and consider gRPC)

• Sensitive, regulated data → Data Sharing API

There's no "best" API type — only the right fit for who's calling and what they need. Get those two answers straight before you write a line of code, and the choice stops being a coin flip.

The truth about ATS, the bullet formula Google itself uses, and every line that gets you shortlisted — from someone who’s been on both sides of the screen.

Your resume gets about seven seconds. That’s the entire window a recruiter gives it before deciding “interview” or “next.” Most engineers lose those seconds not because they’re unqualified, but because they wrote their resume for the wrong reader and believed a pile of myths about robots eating their PDF. Let’s fix all of it.

First, kill the ATS myth — it’s costing you

You’ve heard it: “75% of resumes are auto-rejected by an ATS before a human sees them, so stuff your resume with keywords to beat the bot.” Almost none of that is true, and chasing it makes your resume worse.

Here’s what an Applicant Tracking System actually is: a database. Nearly every large company uses one to store and organize the flood of applications. Recruiters then search that database by keyword, the way you’d search Google. The ATS doesn’t score your soul and hit reject. The only things that auto-filter you are “knockout questions” you answer in the application — visa status, minimum years, a required degree. Pass those, and a human recruiter reads your resume. The viral “auto-reject” stat is marketing from companies selling you resume-checkers.

So your real job isn’t to “beat the ATS.” It’s two things: get parsed cleanly so your info lands in the database correctly, and be relevant enough that a recruiter searching finds you and a human reading is impressed. That reframe changes everything below.

How to actually be ATS-compliant

This part is simple once you drop the fear. Make your resume easy to parse:

• One column. Multi-column layouts, tables, and text boxes are the #1 thing that scrambles parsing.

• Standard section headings: Experience, Projects, Skills, Education. Don’t get cute with “Where I’ve Made Magic.”

• Keep contact info in the body, not buried in the header/footer — some parsers skip those.

• No images, icons, logos, or photos. They add nothing a parser can read and can break it.

• Save as a clean PDF from a normal editor (Google Docs, Word). DOCX is the safest if an application looks old or glitchy.

• Mirror the real keywords from the job description — the actual languages, frameworks, and tools — naturally in your skills and bullets. This is for findability, not stuffing. If the JD says “Kubernetes” and you’ve used it, the word should appear.

Fonts and colors don’t matter to the parser, but they matter to the human, so keep it clean and readable. That’s the whole game: clean structure plus honest relevance.

How long, and how many lines

One page. For anyone with under roughly eight years of experience, this isn’t negotiable, and even most senior FAANG candidates keep it to one. Two pages only if you genuinely have the senior scope to justify it — and most people who think they do, don’t.

Per job, write three to five bullets, each one or two lines. Your most recent and most relevant role gets the most space; older roles shrink to two or three lines. Anything from a decade ago, or unrelated, gets cut or compressed to a single line. Skills section: two to four grouped lines, not a 40-item word cloud.

The structure, in the order it should appear

• Header: your name, the role title you’re targeting (optional but helps), your city, a professional email, phone, and links to LinkedIn and GitHub. No photo, no date of birth, no marital status — those are common on resumes in India and parts of Asia, but for FAANG they only introduce bias and waste space. Cut them.

• Summary (optional): three to four lines, only if it earns its place — your title, years, core stack, and two or three quantified wins. Skip the generic “passionate engineer seeking opportunities” objective; it says nothing.

• Experience: the heart of the resume. More on bullets below.

• Projects: critical if you’re early-career or a student, and useful for anyone to show range. Real projects with links beat coursework.

• Skills: grouped — Languages, Frameworks, Tools/Cloud, Databases.

• Education: degree, institution, year. Drop high school once you’re in college.

• Achievements: this is where “open-source contributor” or “ICPC regionalist” goes. Do not list “watching movies, reading novels” under Interests. Nobody is interviewing you for that.

The bullet formula that gets you shortlisted

This is where resumes are won and lost. The format that works is the one Google’s own recruiting team popularized — often called the XYZ formula:

Accomplished [X], as measured by [Y], by doing [Z].

In plain terms: what was the impact, how big was it (numbers), and what did you actually do. Lead with the result, prove it with a metric, then explain the how.

Watch the difference:

• Weak: “Worked on the payments service and fixed performance issues.”

• Strong: “Cut checkout API latency 38% (320ms → 198ms) by adding Redis caching and eliminating N+1 queries, across ~4M monthly transactions.”

A few more, so you see the shape:

• “Reduced nightly batch failures from 12% to under 1% by rebuilding the retry pipeline with idempotent jobs and dead-letter queues.”

• “Shipped a self-serve onboarding flow that lifted activation 22% by removing three steps and adding inline validation.”

Three rules that make bullets land: start with a strong action verb (Built, Cut, Shipped, Reduced, Led — never “Responsible for”), quantify everything you honestly can (latency, %, users, dollars, scale), and put your single most impressive bullet first, as the first line of your first role. Recruiters frequently don’t read past the top few lines, so don’t bury your best work at the bottom.

If you have no formal metrics yet — fine. Quantify scope honestly: number of users, requests handled, dataset size, team size, time saved. Scale is a metric too.

Tailor every single application

A generic resume blasted to 50 companies is why people get 50 silences. Customize per role: reorder bullets so the most relevant ones rise, mirror the JD’s language, and reflect the team’s actual stack. It takes ten minutes and it’s the difference between “found in search” and “invisible.”

The actual cheat code: referrals

Here’s the thing nobody wants to hear because it’s not about your resume at all. Referrals are the single highest-leverage move in FAANG hiring. Referred candidates advance and get hired at dramatically higher rates — these companies’ own data consistently shows referred applicants are several times more likely to land an interview, and some skip the initial screen entirely. A referral pulls your resume out of the search-result haystack and puts it directly in a recruiter’s hands.

You don’t need to “know someone.” Build a small habit: engage genuinely with engineers at target companies, share your work publicly, and when you’ve built even a little rapport, ask politely if they’d be open to referring you. This is exactly where a real online presence pays off — the more people see you do good work, the more doors quietly open. Apply early in the cycle, too; spots fill fast.

The mistakes that get you cut

• Duty lists: “Responsible for backend development.” Says nothing. Show impact.

• Zero numbers. If a stranger can’t tell whether your work mattered, it didn’t (to them).

• Typos and inconsistent formatting. Instant credibility killer for an engineer — you’re supposed to be precise.

• Too dense, too long. White space is your friend.

• Photo, age, hobbies, soft-skill word salad (“hardworking team player”).

• One generic resume for everything.

• Keyword stuffing to “beat the bot.” Recruiters smell it instantly.

Your 60-second pre-send checklist

• One page, single column, standard headings.

• Most impressive bullet is the very first line.

• Every bullet: action verb + result + metric.

• Keywords from the JD appear naturally.

• No photo, no objective fluff, no irrelevant hobbies.

• Links to GitHub/LinkedIn work and are professional.

• Zero typos — read it out loud once.

• Saved as a clean PDF, named FirstName_LastName_Resume.pdf.

• A referral lined up, if there’s any way to get one.

Your resume isn’t an autobiography. It’s a seven-second argument that you’ll make an impact at scale. Make every line earn its place — and go get the referral.

You don’t have a LeetCode problem. You have a method problem.

Here’s how it usually goes. You open LeetCode, 3,000+ problems stare back at you, and you start grinding. Easy ones feel good. You solve 20, then 50, then 100. Then you open a fresh problem you’ve never seen, and your mind goes completely blank. Again.

I know, because that was me — a hundred-plus problems deep and still freezing on anything I hadn’t seen before.

The issue isn’t your effort. It’s that solving random problems trains you to memorize specific solutions, not to recognize how to attack something new. And an interview will never hand you a problem you’ve already memorized. That’s the entire point of it.

So here’s what actually works: pattern-based learning.

Interviews don’t test problems. They test patterns.

The thousands of problems on LeetCode are really a small set of patterns wearing different costumes. Once you can spot the pattern underneath a problem, the solution mostly writes itself. You stop solving problems one at a time and start solving whole categories at once.

Roughly 15 patterns cover the overwhelming majority of what you’ll ever see. Learn those, and a “new” problem stops being scary. It becomes “oh, this is just a sliding window with a twist.”

The patterns worth knowing

You don’t need all of these on day one, but this is the map. For each one, the real skill is catching the signal in the problem statement:

• Two Pointers — a sorted array, or pairs/triplets, or scanning from both ends inward.

• Sliding Window — a contiguous subarray or substring, usually “longest / shortest / max / min” with a condition.

• Fast & Slow Pointers — linked lists, cycle detection, finding the middle in one pass.

• Binary Search — sorted input, or any “minimize/maximize” with a yes/no condition that flips once (searching on the answer).

• BFS — shortest path in an unweighted graph, or level-by-level traversal.

• DFS & Backtracking — explore every path; generate all subsets, permutations, or combinations.

• Dynamic Programming — overlapping subproblems and a choice at each step: “count the ways,” “min/max cost.”

• Heap / Top-K — “k largest,” “k smallest,” “k most frequent,” or merging sorted streams.

• Merge Intervals — overlapping intervals, scheduling, merging or inserting ranges.

• Monotonic Stack — “next greater / smaller element,” or histogram-style problems.

• Prefix Sum — repeated range-sum queries or subarray-sum questions.

• Union-Find (DSU) — connectivity and grouping: “how many connected components.”

• Topological Sort — ordering with dependencies: “course schedule,” build order.

• Trie — prefix lookups, autocomplete, word dictionaries.

Save this list. You’ll come back to it.

How to actually learn this way

The method is simple, and it’s the opposite of random grinding.

Pick one pattern. Just one. Start with Two Pointers or Sliding Window — they’re common, intuitive, and build fast confidence.

Learn the mental model before you touch a single problem. Understand why the pattern works and what its template looks like. Watch one good explanation (NeetCode is excellent) or read one breakdown. Five minutes of “why” saves you hours of flailing.

Then solve 6–8 problems of that same pattern, back to back. This is the part that matters. Solving eight sliding-window problems in a row burns the pattern into your head far better than eight random unrelated ones. By problem five, you’ll start seeing it before you finish reading the prompt.

Label every problem you solve. Keep a simple sheet: problem name, pattern, and the one trick that unlocked it. That becomes your personal revision doc, and it’s gold the week before an interview.

Revisit on a schedule. You will forget — that’s normal. Redo problems after a few days, then again a couple of weeks later. Spaced repetition is the difference between “I solved this once” and “I can solve this cold.”

And don’t build the path yourself. NeetCode 150, the Blind 75, and Striver’s SDE Sheet are already grouped by pattern so you cover what matters without drowning. Pick one and work through it in order.

The part most people get wrong

Volume is not the goal. I’d take someone who deeply understands 150 problems across every pattern over someone who’s “done” 600 by memorizing editorials, every single time. Interviewers can tell the difference in about ninety seconds.

Consistency beats intensity, too. An hour a day for three months takes you further than a 12-hour weekend binge you burn out on by Tuesday. Show up small, show up often.

If you’re starting today, here’s the move: pick Two Pointers, learn the template, and solve six problems with it before you close your laptop. That’s the whole first step. Tomorrow, do the next pattern.

You’re not behind. You were just using the wrong map.

If this was useful, subscribe.