One gets a useful first draft in five minutes, makes a few improvements and moves on. The other spends twenty minutes refining prompts, correcting responses and trying again. Eventually, they end up with something they could probably have produced themselves.

The difference is not the tool. It’s how each person approached the problem before using it.

The first knew what they wanted, who the output was for and what a good result looked like. The second was still figuring these things out while interacting with AI.

This highlights an important reality.

Access to AI doesn’t automatically make someone better at their work. How they think and behave while using it makes the difference.

Why knowing the tool isn’t enough

It is relatively easy to develop basic AI skills. Most people will be able to create prompts, include context and improve their results using the tool in just a few weeks. But building expertise takes longer.

Once you’ve got a response from your AI, you will need to consider whether it is accurate, relevant and appropriate. You may need to explain it to a colleague, or give reasoning as to why you would recommend it, or make a decision.

While AI can speed up delivery, it does not absolve you of the responsibility.

The real question you should be asking is not “Can I use AI?” It’s “Can I be trusted with what AI produces?”

There are 4 behavioral skills that can help you answer this question.

1. Clear thinking: Understand the problem before asking AI to solve it

One common mistake is asking AI to solve a problem that hasn’t been properly defined.

Ask the AI to create a presentation on the performance of your team.

Do you want to cover the positives, explain a drop in productivity, find out what issues exist within operations or suggest improvements?

Depending on what you want it to do, it will approach the task in a different way. If you don’t have clarity, the AI will make assumptions which may produce a very polished result, but not actually solve any issues in your business.

Thinking clearly is key. Understand what the goal is, who it is for, any limitations and what a successful outcome looks like.

This is the same skill set that helps professionals create great project briefs, define requirements and ask the right questions in meetings. AI simply exposes unclear thinking much faster.

How to develop it: Before your next three AI-assisted tasks, write down the goal, audience, constraints and definition of done. If you cannot explain these clearly to a capable colleague, you’re probably not ready to delegate the task to AI either.

Sometimes, this exercise will reveal that you don’t need AI at all. That’s also effective adoption.

2. Judgment: Know when to trust and when to question

AI can sound equally confident when it’s right, partially right or completely wrong.

Some professionals accept its output because it looks convincing. Others distrust everything and spend so much time checking and rewriting that they lose the productivity benefit.

Both approaches reflect a lack of calibrated judgment.

Good judgment means understanding where verification matters most. An AI-generated meeting agenda may need relatively little checking. Financial figures, customer-facing recommendations, security-related code and legal interpretations deserve considerably more scrutiny.

This is where professional experience becomes valuable. An experienced finance professional can recognize questionable financial assumptions. A software engineer can identify generated code that works but introduces design or security problems.

AI doesn’t make domain expertise less important. It makes applying that expertise more important.

This is also where Human-in-the-Loop (HITL) becomes relevant. It emphasizes keeping human oversight and judgment involved in AI-assisted processes, particularly when decisions have significant consequences. AI can generate, analyze and recommend, but humans still need to review important outputs, challenge assumptions and make informed decisions.

How to develop it: Don’t just correct AI-generated mistakes. Understand why they happened. Was the information outdated? Did the AI make an assumption? Did you provide insufficient context? Or did you overlook something because the answer sounded convincing?

Before relying on an important AI-generated output, practice asking three questions:

• What assumptions is this based on?

• What could make this answer wrong?

• What should I independently verify?

Over time, this reflection helps you recognize patterns and develop better judgment about when to trust AI and when to intervene.

The objective isn’t to question everything. It’s to question the right things.

3. Accountability: Take responsibility for the quality of AI-assisted work

Imagine presenting an AI-assisted business recommendation to your manager. When asked why you recommended a particular course of action, you respond, “That’s what the AI suggested.”

It’s unlikely to be a satisfying answer.

Using AI doesn’t transfer responsibility for the work to the tool. Whether you’re submitting code, preparing an analysis or presenting a recommendation, you remain accountable for the accuracy, quality and suitability of what you deliver.

AI makes producing work easier and faster. But generating something is not the same as understanding it.

Accountability also involves transparency. Explaining that AI helped structure an analysis and that you independently verified the figures demonstrates responsible use. Presenting unchecked output as your own thinking can damage trust when errors emerge.

How to develop it: Before sharing AI-assisted work, conduct a final quality check. Verify important facts, review assumptions and make sure the output meets the original requirements.

For code, understand what the solution does. For analysis, know the sources and assumptions. For recommendations, understand the reasoning, limitations and alternatives.

Ask yourself whether you could put your name to this work and be able to answer questions about how this was done. If not, you still have some work before sharing it.

4. Collaborative learning: Make AI adoption a shared effort

AI adoption is as much a team activity as an individual one.

Imagine someone discovers an AI workflow that saves several hours each week. If they keep it to themselves, the benefit remains individual. But if they share what worked, explain its limitations and encourage colleagues to experiment, the learning can spread across the team.

This requires more than a willingness to try new tools. It requires a willingness to learn from others, share experiences and accept that someone else’s approach may be better than your own.

Collaborative learning doesn’t mean everyone has to enthusiastically adopt every new tool. It means creating an environment where people can experiment, question, share mistakes and learn from one another.

It also means listening when colleagues raise concerns. Someone questioning whether customer information should be entered into an AI tool may be identifying an important privacy risk, not resisting change.

How to develop it: Make AI learning a two-way conversation with your team.

Share one practical observation each week: a workflow that saved time, an AI-generated mistake you caught or a task where you deliberately chose not to use AI.

But don’t stop at sharing your own experiences. Ask colleagues what they have discovered, what hasn’t worked for them and where they have concerns. Invite feedback on your own approach and be willing to change it when someone offers a better solution.

Small, honest exchanges of experience are often more useful than polished demonstrations.

The four skills work together

Consider two professionals with similar experience who are asked to prepare an analysis using AI.

The first accepts the AI-generated findings, uses the suggested recommendations and submits the report. The second clarifies the business question, checks the assumptions behind the analysis, verifies important figures and considers whether the recommendations make sense in the actual business context.

Both have used the same technology. Both may have completed the task faster.

But the second professional has done something more valuable: used AI to support their thinking rather than replace it.

The quality of the outcome depends on all four skills working together.

What this means for your career

As AI becomes part of everyday work, simply knowing which tools to use may become less useful as a way to distinguish yourself professionally. The bigger difference will be how effectively you combine technology with your own expertise.

Think about what organizations value in their people. They need professionals who can identify the right problems, make sound decisions, deliver reliable work and help others improve.

AI can support all these activities, but it cannot automatically develop these capabilities in the people using it.

A professional who uses AI to prepare an analysis, questions its assumptions, verifies the findings and communicates the implications clearly brings more value than someone who simply produces the analysis faster.

This also matters in interviews and career discussions. Instead of simply listing AI tools on your resume, think about situations where you used them responsibly: catching an error before it influenced a decision, questioning an AI-generated recommendation or helping a colleague adopt a useful workflow.

These examples demonstrate how you think, exercise judgment, take responsibility and work with others. Those capabilities matter regardless of which AI tool becomes popular next.

A question worth thinking about

In our previous newsletter, Critical Thinking Skills for Better AI-Powered Decisions, we discussed how critical thinking and decision-making can help us use AI more effectively. In this newsletter, we will take that a step further.

Knowing how to question AI and evaluate its answers is important. But effective adoption also depends on how clearly we define problems, how accountable we are for the work we deliver and how willing we are to learn with others.

Think about the last piece of work you completed using AI.

Did you define the problem clearly? Did you question the output? Could you explain and take responsibility for the result? Did you share anything useful with your colleagues?

Most of us are stronger in some of these areas than others. Recognizing that gap is a better starting point than chasing another tool or learning increasingly elaborate prompting techniques.

The real opportunity isn’t simply to get AI to do more of your work. It’s to become better at the work that still requires you.

Which of these four skills do you think professionals struggle with most: clear thinking, judgment, accountability or collaborative learning?

Share your thoughts in the comments. I read every response, and the discussion could be just as useful as the article itself.

See you next Thursday,

Prasad Rao

Hey, Prasad here. I’m the voice behind the weekly newsletter Big Tech Careers. I share practical strategies for Big Tech interviews, behavioral storytelling, technical careers, and professional growth every Thursday.

New to Big Tech Careers? Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

The question is how you’d know.

That’s where critical thinking comes in: the habit of asking what an answer is based on, what it assumes, and what it leaves out before you rely on it. Decision-making is the step after that: choosing what to do when the information is incomplete and the trade-offs are real, and owning the result. Both skills were always part of good work.

AI hasn't replaced the need for critical thinking and decision-making. It has made these skills easier to skip and more costly to ignore.

To understand why these skills matter more now, it helps to look at what AI has actually changed about the way we work.

What AI changed, and what it didn’t

Before AI tools, thinking was built into the effort of finding things out. You chose your sources, noticed when they disagreed, and built analyses by hand, so you knew every assumption because you made it yourself. The hard part was getting enough information to decide.

AI has flipped that. Information and analysis are now instant.

What’s scarce is judgment to tell a good answer from a plausible one.

The thinking that used to happen during the work now has to happen on purpose, afterward. And sometimes, that thinking gets lost in the volume of information AI produces.

What hasn’t changed is who carries the outcome. When a decision goes wrong, nobody asks the AI to explain it in the retrospective.

How much should you trust an AI answer?

Checking everything defeats the purpose of using AI. Checking nothing is how mistakes slip through.

The skill is knowing where to spend your attention. Verify harder when the answer involves:

• Specific numbers, limits, or prices. They’re easy to get slightly wrong and they change often.

• Recent events or current facts. The tool’s information may be out of date.

• Named features, settings, or sources. AI can describe things that don’t exist with complete confidence.

• Your own organization. It only knows what you told it.

• A decision that’s hard to reverse. The cost of being wrong is higher.

You can relax when the task is low-stakes and easy to undo, when you’ll see the result immediately (code either runs or it doesn’t), or when you’re using AI to brainstorm rather than to decide.

One habit covers most cases: before acting, find the single claim that, if false, would make the whole recommendation wrong. Check that one.

Five prompts that make AI check its own work

AI tools can reinforce the assumptions and framing built into your questions. You can counter that with questions that force the tool to expose weaknesses. These work in any assistant:

1. “List the assumptions behind this recommendation.” Then decide which ones are true for you.

2. “What would make this answer wrong?” This surfaces the risks the first answer glossed over.

3. “Make the strongest case for the opposite choice.” If your preferred option survives, you can proceed with more confidence.

4. “What information would change your answer?” This tells you what to go and find out.

5. “Which parts of this are you least certain about?” Treat the reply as a pointer to where you should check, not as a reliable confidence score.

A worked example

Here’s a hypothetical scenario that brings these together.

A team lead is deciding whether to replace a self-hosted job scheduler with a managed cloud service. Two other teams depend on it. Her AI assistant recommends migrating: less maintenance, built-in monitoring, easier scaling.

Question the answer. She asks it to list its assumptions. One stands out: that existing jobs use only standard scheduling features. She asks what would make the recommendation wrong, and the tool notes that custom scheduling logic may not be supported.

Check what matters. That’s the claim the decision depends on, so she asks the two dependent teams directly. One of them has three jobs with exactly that kind of custom logic. She also checks the provider’s current pricing page, since cost figures from the AI could be out of date.

Add context. She knows something the tool doesn’t: her team is short-staffed this quarter, so less maintenance work has real value right now.

Decide. Migrate everything except the three custom jobs now, and revisit those next quarter. That option was never on the AI’s list. It’s the “smaller version” from the traps above, and it came from her, not the tool.

AI did most of the research. The decision came from a few minutes of questioning, one conversation, and context only she had.

Four traps to watch for

Checking the answer is half the job. Even with good information, decisions go wrong in a few predictable ways when AI is involve.

Good decisions don’t always come from having the most information. They come from identifying what matters, understanding the trade-offs, and knowing when you have enough evidence to act.

Deciding by default. The first recommendation arrives, sounds reasonable, and quietly becomes the decision. The fix: if your final choice is exactly what the tool suggested first, check whether you actually weighed anything.

Letting AI set the menu. AI chooses among the options it was given or generated. The best option may not be on the list, such as doing nothing, doing half now, or running a small trial first. The fix: always add “do nothing” and “a smaller version” to the options before comparing.

Endless analysis. Because more analysis is free, it’s tempting to keep asking for one more comparison. At some point, gathering information becomes a way to avoid committing. The fix: set a decision date before you start researching.

Borrowed confidence. A decision feels safer because the AI agreed. But AI tools tend to go along with the framing you give them. The fix: ask for the strongest case against your preferred option before you commit.

Make the call, then write it down

Not every decision deserves the same effort. The most useful question is how easy it would be to reverse. If a decision is cheap to undo, decide quickly and learn from the result. If it’s expensive to undo, invest more time in checking, gathering input, and evaluating the options. AI can help with either kind, but recognizing which one you’re facing is your job.

For decisions that matter, keep a short note:

• Decision: what you were deciding, in one sentence

• Choice: the option you picked

• Why: the main reason

• Key assumption: what must hold true

• Revisit if: the signal that would make you reconsider

It takes two minutes and makes your reasoning easy to share. If the decision goes badly, it shows you which assumption broke, so you learn something instead of guessing.

Applying the same skills beyond work

This can be applied to personal decisions. For example, if you’re faced with two job offers and decide to use AI to help you choose between them, it can quickly lay out the differences in salary, career progression, and commute. However, it will not know how much you would value working with certain people, what your family require at the moment or how you felt about meeting the manager.

By asking what assumptions have been made, looking at key facts within the offer letters and using your own priorities.

You are applying the same skill whether the decision is personal or professional. Using data to guide your decision.

Why this matters for your career

As more and more of the implementation is done by AI, you will be doing more of the critical thinking to decide what problems to solve, what compromises to make and what to say no to.

The ability is also demonstrated in interviews. Interviewers often like to ask tricky questions about decisions you’ve made. They want to know how you have approached the problem, what options have you considered, how you have weighed up the compromises and why you decided to take a certain approach.

Most scenario based interview questions and job simulations revolve around these scenarios. If you keep notes about your decisions then you already have the information ready to explain how you think, analyze and decide.

Start this week

Choose one decision to work with. Use two of the prompts above to confirm the 1 main fact. Write your 5 line note. Notice that you feel much more positive towards your decision when you can clearly explain why you made it.

See you next Thursday,

Prasad Rao

Hey, Prasad here. I’m the voice behind the weekly newsletter Big Tech Careers. I share practical strategies for Big Tech interviews, behavioral storytelling, technical careers, and professional growth every Thursday.

New to Big Tech Careers? Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

Alex has a very strong opinion on the caching layer and wants to debate it on the whiteboard right now. Sam barely says a word. Two days later, she shares a four-page document in the team channel, carefully taking apart three assumptions nobody questioned in the meeting.

Alex thinks Sam was disengaged. Sam thinks Alex steamrolled the discussion. Their manager thinks both of them are difficult to work with.

But what if neither of them is actually the problem?

Alex likes to talk through ideas as they come to him. Sam prefers to take some time to think things over before sharing her thoughts in writing. Both have good ideas to contribute, but they’re approaching things differently. Alex sees Sam’s silence as a lack of interest, while Sam feels she doesn’t get enough time to think.

This happens more often than we realise. A colleague who takes time to decide might seem indecisive, even though they're just being thorough. Someone who asks lots of questions might come across as negative, while someone who makes quick decisions might seem reckless.

The trouble isn’t always that people can’t work together. Sometimes, it’s that they don’t understand how the other person works.

And learning to recognize that difference is a surprisingly useful skill, especially as your career progresses.

Why this matters more as you grow

Early in your career, much of your success depends on what you can deliver yourself: a piece of code, a resolved bug, a working feature. As you move into senior engineering, staff, or architect roles, the work changes. You spend more time influencing decisions, aligning teams, reviewing designs, and getting people on board with ideas.

You might have a technically sound proposal that goes nowhere because you haven’t addressed a stakeholder’s concerns. A dependency team might push back on your timeline because you’ve underestimated their constraints. A design review might turn into a debate because two people are approaching the same problem from different angles.

In these situations, being technically right isn’t always enough. You also need to understand how other people think, what they need to make a decision, and how they prefer to work through disagreements.

You won’t always get to choose your teammates, stakeholders, or reviewers. But you can get better at working with them.

Before you label someone, look at their behavior

When a colleague repeatedly frustrates you, it’s tempting to explain them with a label.

They’re introverts. They’re perfectionists. They’re too aggressive. They’re just difficult.

Whilst this can be helpful in providing a quick reason for why they’re acting like this, it can also cause you to stop looking further into why they are acting like this.

Personality research does offer useful ways to understand individual differences. The Big Five model, for example, describes personality through five broad traits: openness, conscientiousness, extraversion, agreeableness, and neuroticism, often discussed in terms of emotional stability. It has a stronger research foundation than many popular personality-type systems.

The Myers-Briggs Type Indicator (MBTI) is another familiar framework, but its ability to consistently assign people to distinct types and predict workplace outcomes has been questioned by researchers. It’s worth being cautious about treating a personality test as a definitive explanation of how someone will behave at work.

Even a well-established personality framework has its limits. Knowing that someone scores high on conscientiousness doesn’t tell you exactly how they’ll handle a disagreement over a production release.

You’re better off starting with what you can actually observe.

Instead of saying, “She’s difficult to work with,” try being more specific: “She raises concerns late in the review process, often after the team thinks a decision has been made.”

That gives you something to investigate and address. The label doesn’t.

Four differences that often create friction

Not every conflict between individuals is due to personality differences. In many cases it can be due to differences in how you work. Here are four common differences that can cause issues when working with capable colleagues. They’re patterns to recognize, not labels to put people in.

1. Thinking out loud vs. thinking things through first

Some people work through a problem by talking. They throw out ideas, test assumptions, and change their minds as the conversation develops. Others prefer to process information privately and speak once they’ve had time to think things through.

In a meeting, one may interpret silence as disengagement, while the other may feel rushed by a discussion that moves too quickly.

If you think out loud, share proposals beforehand and leave room for others to respond. If you prefer time to reflect, let colleagues know you’ll follow up after considering the discussion. After all, the person who speaks first doesn’t necessarily have the best idea.

Research by Adam Grant, Francesca Gino, and David Hofmann found that leadership effectiveness depended partly on how proactive employees were. Introverted leaders tended to perform better with proactive employees, while extraverted leaders did better with less proactive employees in the settings studied.

The takeaway? Neither style is inherently better; effectiveness depends partly on the people and the situation.

Read the research summary from Knowledge at Wharton.

2. Big-picture thinking vs. attention to detail

Imagine proposing a major change to a service architecture.

You start with the big picture: the current system won’t scale, the proposed design reduces operational complexity, and the team needs to make the change before traffic increases.

Your colleague’s first questions are about backward compatibility, failure modes, database migrations, and what happens if the rollout needs to be reversed.

You might think they’re missing the point. They might think you’ve skipped the hard part.

In reality, these are just two different aspects of the same issue.

Some people want to understand the why and the big picture before getting into the details. Others want to know that the details have been considered.

When explaining your idea, think about what the other person needs to hear. If they’re focused on the big picture, start with the business or technical goal. If they want to understand how it’ll be implemented, be prepared to discuss trade-offs, risks, and edge cases.

You don’t have to choose one approach over the other. Good technical decisions require both.

3. Quick decisions vs. wanting more evidence

This difference can be particularly frustrating when you’re working towards a deadline.

One engineer wants to make a decision, ship it, and iterate as needed. Another wants to explore the options, gather more information, and make sure the team hasn’t overlooked any risks.

The second sees the first as an obstacle, while the first sees the second as someone willing to take risks with the system.

However, before jumping to conclusions, think about the decision that needs to be made.

If a decision is easy to reverse, spending a long time analyzing it may not be worthwhile. However, if it involves a complex migration, a security risk, or significant costs to reverse, taking more time makes sense.

Rather than arguing about who is being too cautious or too impatient, agree on a few things upfront:

• When does the decision need to be made?

• What evidence do we actually need?

• What risks would justify delaying the decision?

• Can we reverse the choice if it doesn’t work out?

These questions shift the discussion away from individual preferences and towards the problem the team needs to solve.

4. Direct feedback vs. a more diplomatic approach

Some colleagues prefer feedback that’s short and direct: “This approach won’t work because it creates a race condition.”

Others are more comfortable when the feedback includes context: “I see what you’re trying to achieve here. I’m concerned that this approach could create a race condition. Could we look at another option?”

The underlying concern is the same. The delivery is different.

Rather than assuming blunt feedback is rude or diplomatic feedback is unclear, ask: “When I have concerns about your design, would you prefer that I raise them directly in the review or discuss them with you beforehand?”

You can also explain what works for you. The goal isn’t to avoid honest feedback or make every conversation comfortable. It’s to make sure the feedback is understood and the discussion stays productive.

A few small changes that can make working together easier

You don’t have to become an expert in personality psychology to improve a working relationship. Often, a few simple changes are enough to make a difference.

While adapting to different working styles can help, it doesn’t mean overlooking repeated disrespect, broken commitments, or other behaviors that need to be addressed directly.

Describe the behavior, not the person.

Instead of deciding that someone is careless, negative, or controlling, identify what they’re doing and how it’s affecting the work. “We keep revisiting decisions because the acceptance criteria aren’t agreed upfront” is a much more useful observation than “He never makes up his mind.”

Ask how they prefer to work.

A simple question can save a surprising amount of frustration: “Would you rather review this in a meeting or have some time to go through the document first?” You can ask the same about feedback, decision-making, and project updates. Share your own preferences, too. Working together gets easier when neither person has to guess.

Adjust your approach without lowering your standards.

You might need to share information earlier, allow more time for discussion, or explain your reasoning in greater detail. That’s not the same as compromising on quality or accepting missed commitments.

You’re changing how you work together, not what the work needs to achieve.

Make expectations explicit.

A lot of disagreements come down to differences in expectations. One person might expect a brainstorming session, while another expects a decision to be made. One person might expect a reply within an hour, while another assumes they can respond the following day.

Align on the basics. Share documents a day in advance. Set deadlines for decisions. Clarify who owns the next step. Getting everyone aligned upfront can prevent a lot of unnecessary friction later.

For more on navigating challenging workplace relationships, see Amy Gallo’s Getting Along: How to Work with Anyone (Even Difficult People) or listen to her Harvard Business Review’s IdeaCast episode, Strategies for Dealing with Difficult Coworkers.

This can also make a good interview story

If you’re preparing for a senior engineering or leadership role, there’s another reason to think about these experiences.

Interviewers often ask some version of: “Tell me about a time you worked with someone whose style was different from yours.”

It’s tempting to tell a story about a difficult colleague and finish by saying you stayed patient and professional. That’s a start, but it doesn’t reveal much about how you approach collaboration.

A stronger example shows how you recognized the difference, what you did to address it, and what changed as a result.

You could structure your answer using the STAR method:

• Situation: What was happening, and why was the working relationship challenging?

• Task: What did you need to accomplish together?

• Action: What did you notice about the other person’s approach, and how did you adapt your own?

• Result: Did the team make a better decision, resolve a disagreement, or deliver more effectively?

The most important part is the action. Show that you didn’t simply tolerate the difference; you found a practical way to work through it.

That demonstrates a skill that becomes increasingly important in senior roles: getting good work done with people who don’t necessarily approach problems the way you do.

One thing to try this week

Think of a person you find difficult to work with. This could be anyone that does not agree with your ideas, rarely contributes in meetings or wants everything decided straight away.

Do not focus on why they are tricky to work with but rather write down exactly what they are doing that is causing frustration.

Try to think of why they are doing this. Are you working in a different way? Do you require different levels of detail? Do you have different expectations about when decisions should be made? Or are they really being unreasonable?

Although you may not be able to change how they work, you may find a way to work with them more effectively.

If you do then take note of what has changed. These little things can be just as valuable as any technical skills you gain throughout your career.

What type of difference in working style have you found most challenging?

If you are reading this then comment below or talk to a colleague about your experience. Chances are you are not alone!

Sources and further reading

1. Grant, A. M. Goodbye to MBTI, the Fad That Won’t Die. Psychology Today. Find the article.

2. Grant, A. M., Gino, F., & Hofmann, D. A. (2011). Reversing the Extraverted Leadership Advantage: The Role of Employee Proactivity. Academy of Management Journal. Research paper.

3. Knowledge at Wharton. (2010, November 23). Analyzing Effective Leaders: Why Extraverts Are Not Always the Most Successful Bosses. Read the article.

4. Gallo, A. (2022). Getting Along: How to Work with Anyone (Even Difficult People). Harvard Business Review Press. Book details.

5. HBR IdeaCast. (2022, August 16). Strategies for Dealing with Difficult Coworkers. Listen to the podcast .

See you next Thursday,

Prasad Rao

Hey, Prasad here. I’m the voice behind the weekly newsletter Big Tech Careers. I share practical strategies for Big Tech interviews, behavioral storytelling, technical careers, and professional growth every Thursday.

New to Big Tech Careers? Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

She spent the whole quarter working on her team's deployment pipeline. Before that, about every fifth deployment was failing and required someone to take care of it. After she did her part, the number of failing deploys decreased to about 2%, and her team started deploying twice as often as before.

When I asked how her manager had described that work during the review discussion, she sighed.

“He said I did some solid infra work this quarter.”

Some solid infra work. That’s what a quarter of high-impact effort had been reduced to by the time it reached the room where decisions were made.

Meanwhile, a peer who launched a visible customer feature got the strong rating. Anna wasn’t angry with him. She was confused.

“I thought good work was supposed to speak for itself.”

I understood her frustration; She has been working on the project for months, and her hard work has paid off. It was significant, so why was it not enough?

But there’s a gap between doing valuable work and helping others understand its value. That gap can shape how your contributions are remembered, discussed, and rewarded.

Let’s look at what you can do to make your contributions easier to understand and recognize. We’ll explore practical ways to communicate your work, demonstrate its impact, and build habits that help others see the value you bring. Along the way, we’ll cover:

Why good work goes unnoticed: Understand why valuable contributions can get overlooked, even when the results are measurable.

Give people the context they need: Learn how to communicate your achievements without feeling like you’re bragging or taking credit away from others.

Describe the work at the right level: See how to move beyond describing tasks and explain the outcomes and impact of your work.

What this looks like in everyday situations: Explore practical examples of communicating your contributions in 1:1s, team updates, conversations with senior leaders, and performance reviews.

Keeping your updates grounded and credible: Learn how to use evidence, acknowledge others’ contributions, and communicate your impact without overstating it.

Build a simple habit around it: Discover small, consistent practices that help you keep track of your achievements and make performance conversations easier.

We’ll also return to Anna’s story to see how these changes helped her manager better understand and communicate her contributions, before ending with a simple exercise you can try before your next 1:1.

Why good work goes unnoticed

In my experience, when strong people get overlooked, it’s often because the people making decisions don’t have enough context to understand the value of their contributions.

A few things contribute to this.

Your manager only sees a fraction of what you do. He or she is juggling many projects and people, and there is always a priority. Your manager's managers see even less. By the time your promotion gets discussed in some review committee, there may not be more than a summary and a few notes left.

Some valuable work is difficult to see. Things like preventing outages, eliminating bottlenecks, unblocking other teams, and generally making the world a better place (but for a system that no one really cared about) are rarely celebrated. If they're done right, nothing really changes. There's no big release or flashy feature. The systems just run better. It doesn't cause an incident, so it's not talked about, and the other teams barely notice it happening.

The results can take time to show up. Anna’s pipeline fix didn’t produce one dramatic moment. It made hundreds of deployments more reliable. Unless someone connects those everyday improvements to the work behind them, the impact can go unnoticed.

People are busy. Your manager probably likes your work but might not be able to recall every nuance of what you have done. They will not have the time to go through each ticket, commit, or project note.

That is why it can be helpful to give context for your work. Your manager will need specific examples and evidence to explain your contributions in conversations that you are not part of.

Give people the context they need

Many thoughtful professionals feel uncomfortable talking about their achievements. They picture someone who dominates meetings, takes credit for team wins, or turns every small task into an announcement.

That isn’t what I’m suggesting.

The aim is to help people understand what your work involved, what changed as a result, and why that change matters.

Consider Anna’s deployment fix. She could have said:

❌ “I spent the quarter fixing the deployment pipeline and improving the retry logic.”

That’s a fair description of her work, but it leaves the listener to figure out the outcome.

She could instead say:

✅ “I fixed the deployment pipeline, bringing deployment failures down from about 20% to 2%. The team can now ship twice as often, with far less time spent babysitting releases.”

The second explanation gives her manager something concrete to remember and share. It shows the improvement, gives a sense of scale, and explains how the team benefited.

That’s the kind of information that helps your work stand out in a review discussion.

It also makes your manager’s job easier. They have to represent your work in rooms you’ll never be in. When they have clear examples and measurable results, they can explain your contribution with confidence.

Here’s a useful question to ask yourself: If my manager had to describe my last quarter in two sentences, what would they say? Would those sentences reflect the most important things I accomplished?

If the answer is unclear, you have an opportunity to help them fill in the gaps.

Describe the work at the right level

Most people are comfortable explaining what they worked on. The harder part is connecting that work to its results.

Think about Anna’s project at three levels:

• Activity: “I worked on the deployment pipeline.”

• Output: “I rebuilt the retry logic and added automated rollback.”

• Impact: “Deployment failures dropped from about 20% to 2%, and the team now ships twice as often.”

Each level adds useful information. The activity explains where she spent her time. The output describes what she built. The impact shows why the work mattered.

When you share an update, start with what changed. Add the technical details that help your audience understand the result, and explain who benefited.

A simple structure can help:

1. What changed? Describe the result, using numbers where possible.

2. Why does it matter? Explain the benefit to customers, the team, or the business.

3. What’s next? Share the next step, an outstanding risk, or a decision you need.

You don’t need to turn every update into a formal presentation. Often, one or two clear sentences are enough.

What this looks like in everyday situations

Here are five situations where a little context can make your work easier to understand.

1. During your weekly 1:1

Instead of saying:

❌ “Busy week. Mostly pipeline stuff.”

Try:

✅ “Quick update on the pipeline. Since the retry change went in, failures have dropped from about one in five deployments to one in fifty. The payments team says they’ve stopped babysitting releases. Next, I want to look at the test suite because it’s now the slowest part of the process.”

This takes about twenty seconds. Your manager gets the result, hears how another team benefited, and knows what you’re planning next.

2. Sharing a team win in a public channel

You could write:

✅ “We shipped the new onboarding flow today. Big thanks to Riya for the API changes and Sam for testing on low-end devices. Early numbers look good: completion is up from 62% to 71% in the first 48 hours. I’ll share a fuller readout next Friday.”

This update celebrates the team’s work and gives people something specific to take away from it.

Giving credit to colleagues also helps others understand how the work came together. It shows that you can collaborate across teams and recognize the contributions that made a result possible.

3. When a senior leader asks, “What are you working on?”

It can be tempting to answer with details about what you're actually doing. However, a senior leader usually wants to hear the outcome first and anything that they need to be made aware of.

For example:

✅ “The main focus is reducing our cloud spend. We’ve cut costs by about 18% so far, mostly through right-sizing batch jobs. Storage is the next big opportunity, and I’ll need a decision from the data team on retention policy by the end of the month.”

This gives the leader a clear picture of progress and identifies where their help may be needed. You can go into the implementation details if they ask.

4. Explaining work that prevented a problem

Some of the most valuable work is difficult to notice because success means a problem never occurs.

You might share an update like this:

✅ “During last week’s sale, traffic reached three times normal levels and checkout stayed under 300 milliseconds. The caching work we did in August helped us handle that load. Our tests had suggested we’d start seeing timeouts at around twice normal traffic without those changes.”

This connects an otherwise quiet engineering improvement to a result the wider business can understand. It also gives your team credit for preparing ahead of time.

5. Writing your self-review or promotion document

Consider this example:

❌ “Led the queue migration project.”

✅ “Led the migration of 40 services off our legacy queue, coordinating across three teams, with zero customer-facing incidents. The change removed the system responsible for about 30% of our on-call pages, giving each engineer back roughly a day per sprint.”

The description explains the scale of the project, the coordination involved, and the benefit to the team. These details help reviewers understand the scope of your contribution and the problems you can take on.

Keeping your updates grounded and credible

If talking about your achievements feels uncomfortable, a few simple practices can help.

Use evidence. Words like “huge,” “massive,” and “game-changing” don’t tell people much on their own. Explain what improved, how much it improved, or what became possible as a result.

Give credit where it’s due. If others contributed, name them. You can describe your own role clearly while recognizing the people who helped deliver the result.

Choose what to share. You don’t need to announce every task you complete. Focus on work that improved a process, helped a customer, reduced a risk, saved time, or moved a project forward.

Adjust the detail for your audience. Your manager may want to understand the technical approach. A director may care more about the outcome, the cost, the risk, or a decision that needs to be made.

Be clear about your contribution. If you led the work, explain what you led. If you contributed to a team effort, describe your part and the shared result. Specific details make your account easier to trust.

You don’t need a grand announcement to communicate your work well. A calm, factual update is often enough.

Build a simple habit around it

The people who do this well tend to keep track of their work as they go. They don’t have to reconstruct an entire quarter from memory when review season arrives.

Here are a few ways to make that easier.

Keep a short impact log. Spend five minutes every Friday noting what changed that week, any useful numbers, and who benefited. By review season, you’ll have a record of specific contributions rather than a vague recollection of being busy.

Capture the starting point. Before fixing a slow page, a flaky process, or an expensive system, record how it performs today. That gives you a meaningful comparison when the work is done.

Share updates regularly. A short note during your weekly 1:1 and a brief summary at the end of a project are often enough. Regular updates help people remember the work while the details are still fresh.

Ask others to share their experience. If a partner team benefited from your work, ask whether they’d be comfortable sharing that feedback with your manager. Their perspective can help explain the impact in ways your own update might miss.

These habits take very little time, and they make performance conversations much easier for everyone involved.

What happened with Anna

Anna started applying these ideas in real life (nothing revolutionary, just these ideas). There was no significant change in her work process; she started giving a two-line update in each 1:1, sharing a quick note with her manager after a successful release, and keeping an impact log each Friday.

Two review cycles later, her manager described her in the calibration conversation as ‘the person who made our whole team faster.’

She continued to be the same brilliant engineer as before, delivering the same high-quality code. However, her manager now had real-life examples and could effectively communicate her impact and value to the leaders.

As you can see, impactful work requires your time and effort. At the same time, explaining your contributions benefits everyone, including you, in terms of recognition and rewards. Therefore, practicing explaining what, how, and for whom you do what you do will undoubtedly make you a more valuable team member.

Try this before your next 1:1

Pick one piece of work from the past month and write down three things:

What changed: What did you improve, build, or resolve?

Why it matters: What difference did it make? Include a number if you have one.

Who benefited: Which customers, colleagues, or teams are better off because of it?

Share those points with your manager this week. It should take less than a minute.

One clear example can give your manager a much better understanding of your work, and give you a useful starting point for the next conversation about your growth.

See you next Thursday,

Prasad Rao

New to Big Tech Careers? Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

You’ve prepared for weeks. You’ve shortlisted the common behavioral questions, written your answers using the STAR method, and rehearsed your stories until they sound polished.

The interviewer asks: “Tell me about a time you had a disagreement with a teammate”

You deliver your answer with confidence. You explain the situation, the actions you took to resolve the disagreement, and the positive outcome. It goes exactly the way you practiced it.

Then the interviewer asks

“How do you think your teammate would describe that disagreement?”

You’ve only ever told it from your side. You offer a vague line about how they probably saw it differently.

“What evidence did you have that your approach was right?”

You reach for “I felt strongly about it” and realize how thin that sounds. A benchmark, a customer complaint, or a past incident helps

“What did you get wrong?”

You pause. Your story had no mistakes in it. That’s the problem.

“What did the disagreement cost the team? Days lost, work redone?”

You said it ended with “we aligned.” They want to understand the impact.

“At what point would you have taken it to your manager?”

You never had to, so you’ve never decided where that line sits.

“And how was the working relationship afterward?”

Somewhere around the third question, the story you rehearsed ran out. You prepared what happened, and the interviewer has been asking how you think.

If this sounds familiar, you are not alone. It is one of the most common problems with behavioral interviews. Preparing your answer is not the same as being prepared to talk about your experience.

This is exactly why I created Big Tech Interviews: Build Your Story Bank in 4 Weeks. The cohort helps you turn your real work experiences into structured, compelling stories and prepare to discuss the decisions, trade-offs, and lessons behind them. Through guided practice, mock interviews, and feedback, you’ll learn to go beyond rehearsed STAR answers and handle follow-up questions with greater confidence.

The cohort starts October 16.

Build Your Story Bank With Me in 4 Weeks

Big Tech Interviews: Build Your Story Bank in 4 Weeks

📅 October 16 to November 8, 2026

👉 Explore the October Cohort [Starts tomorrow 16th Oct]

Have questions? Email prasad@bigtechcareers.com

Why STAR Alone Isn’t Enough

STAR is the right technique to prepare for behavioral interviews. It helps you structure your answer in a way that would help the interviewer to follow your story:

• Situation: What was happening?

• Task: What were you responsible for?

• Action: What did you do?

• Result: What happened as a result?

STAR allows you to tell about your experience correctly, but just responding to it properly does not always show that you can demonstrate an example. It is evident when the interview asks additional clarifying questions; thus, thinking about the possible additional questions that an interviewer might ask is also significant.

Follow-up questions go after the thinking behind your story:

• Why did you choose that action?

• What alternatives did you consider?

• What was your specific contribution?

• What did you learn from the experience?

Imagine a candidate telling a compelling story about leading a cross-functional team through an enterprise migration. The STAR version of the story is probably right there, told with a good pace and clarity. However, once the interviewer gets to probing, he or she may ask about conflict resolution within the team, underlying reasons for certain decisions, or lessons learned that the candidate would apply next time. The answers to these questions are not in the two-minute story told in the STAR format.

The way to prepare oneself for such challenges is by developing answers that are authentic, specific, and grounded in reality. To do that, it’s important to have a good grasp of one’s story, examine it from various angles as one expects an interviewer to do when asking clarifying questions, rather than simply rote-learning it.

Six Types of Follow-Up Questions to Prepare For

Every interviewer has their own style, and there are no hard-and-fast rules that every Big Tech interviewer follow. But many common probing questions fall into a few recognizable categories. By preparing answers to these six broad types of questions, you’ll have prepared yourself for the vast majority of follow-up questions you’re likely to face.

You won’t face all six types for every story. But any story you plan to rely on should hold up against most of them.

Stress-Test Your Story

Here’s a simple way to see where your preparation stands.

Choose one story from your own experience, one you’d feel comfortable using in an interview tomorrow. Then go through the statements below and check only the ones you can confidently support with a real example from that story.

Is your story follow-up ready?

• ☐ I can explain why I chose my approach.

• ☐ I can clearly separate my contribution from the team’s work.

• ☐ I can describe a real challenge, mistake, or trade-off.

• ☐ I can explain the outcome and how I know it mattered.

• ☐ I can discuss what I learned and what I would change.

• ☐ I can answer follow-ups without relying on a memorized script.

If you checked all six, that story is in good shape. If you hesitated on any of them, you’ve found exactly where the story needs more work. Revisit the decisions, actions, and outcomes behind it before you rely on it in an interview.

This is a self-reflection exercise, not a validated measure of interview readiness. Its value is in showing you where to focus next.

A Quick Challenge

Go back to the opening question: “Tell me about a time you disagreed with a teammate.”

You share your STAR answer. Then the interviewer asks:

• “Why did you believe your approach was better?”

• “What would your teammate say about how you handled the situation?”

• “Knowing what you know now, would you make the same decision?”

Could you answer all three naturally without getting defensive, using what actually happened?

If not, the story probably needs to be developed further. Rehearsing it again won’t close that gap.

Having Ten Stories Isn’t the Same as Being Ready

You have tested one story against three challenging follow-up questions. But what if you had ten behavioral stories? Is that all it takes to prepare for an interview?

Not unless you know the story in such detail that you can talk about it backwards and forwards. Otherwise, your confidence will be unjustified, and you will stumble when asked to discuss decisions, contributions, or learnings not anticipated in your story.

A good story bank is not only a set of STAR answers but a set of experiences that you understand in sufficient detail to be able to discuss their different aspects. In each of your stories, you should be able to describe:

• Why you made the decisions you did and what alternatives you considered.

• What you personally contributed and how it affected the outcome.

• What challenges you faced, what you learned, and what you might do differently.

• Which other behavioral questions the experience can authentically address.

The goal isn’t to memorize multiple answers for every possible question. It’s to understand your experiences well enough to respond clearly, consistently, and honestly, even when the conversation takes an unexpected turn.

STAR gives your stories structure. Understanding the decisions, trade-offs, and lessons behind them helps you handle follow-up questions with confidence.

Don’t Stop at Your First Answer

Your next behavioral interview may start with the same set of familiar questions. What happens next, based on your first response, may depend on just how much you know about the experience itself.

Preparation for follow-up questions can not be done by simply preparing your STAR response to the question. You need to understand what led to your decisions, explain how and why you took a specific part of each story, while analyzing the trade-offs and lessons learned.

If you have been preparing by gathering commonly asked questions, practicing STAR responses, or simply wondering which experiences are worthy of discussion, then this is a great opportunity to improve your preparations.

That’s what Big Tech Interviews: Build Your Story Bank in 4 Weeks is designed to help you do.

The cohort starts October 16.

Build Your Story Bank With Me in 4 Weeks

Big Tech Interviews: Build Your Story Bank in 4 Weeks

📅 October 16 to November 8, 2026

👉 Explore the October Cohort [Starts tomorrow 16th Oct]

Have questions? Email prasad@bigtechcareers.com

Over four weeks, you’ll build your story bank using STAR as the foundation. Then you’ll strengthen each story by exploring the details behind it and preparing for the follow-up questions interviewers are likely to ask.

A central part of the cohort is the mock interviews. You’ll practice answering probing follow-up questions in a realistic setting and receive feedback on how you respond. It’s one of the most effective ways to find the weak spots in your stories before an interviewer does.

The goal is to move beyond a set of memorized answers and build stories you can explain and discuss in depth.

See you next Thursday,

Prasad Rao

Hey, Prasad here. I’m the voice behind the weekly newsletter Big Tech Careers. I share practical strategies for Big Tech interviews, behavioral storytelling, technical careers, and professional growth every Thursday.

Both can leave a candidate with suboptimal results.

While AI can certainly help you excavate relevant experience from your resume, organize your thoughts, ask pertinent follow-up questions in order to root out any missing STAR components and give you the repetitions needed to prepare for an interview, it does so without the benefit of knowing which stories reflect your experience level, impact, or contribution most effectively, or if the story is authentic to you.

A human coach or recruiter can identify stories that demonstrate the right scope, challenge, contribution, and impact, help you reposition if you’re overestimating your role, and advise you on when a given story isn’t reflective of the experience level you’re attempting to convey.

The faster and better path is to combine the two.

Use human expertise where judgment matters. Use AI where volume and repetition matter.

That’s the approach behind my next cohort, Big Tech Interviews: Build Your Story Bank in 4 Weeks, starting October 16. Over four weeks, we’ll work on the stories themselves with direct feedback from me, then use AI to help you build, refine, and rehearse those stories between sessions.

The goal isn’t to choose between a human coach and AI. It’s to use each for what it does best: human expertise for judgment, and AI for scale and repetition.

Build Your Story Bank With Me in 4 Weeks

Big Tech Interviews: Build Your Story Bank in 4 Weeks

📅 October 16 to November 8, 2026

Explore the October Cohort

🚀 Have questions before you enroll in the cohort?

Book a Free Discovery Call

Why your stories still need human expertise

Crafting a compelling behavioral narrative is partially a matter of structure, but mostly of judgment.

You have hundreds of hours of experience to choose from, but what matters is the judgment to decide what to talk about, what to reveal and conceal about your role and responsibility in each, what the interviewer will want to hear, and how much detail a Big Tech interviewer would expect to hear from you at your level.

This is where human judgment is of the essence.

A good coach can help you:

• Choose the right experiences. I build story banks around eight behavioral themes: Customer / User Focus, Success, Failure, Conflict, Problem-Solving, Learning / Growth Mindset, Leadership, and Time Management. Most people have strong material for three or four of these and very thin material for the rest.

• Move from “We” to “I.” Interviewers want to understand your decisions and your contribution. A coach will keep asking what you did until it’s visible in the story.

• Get the STAR structure right. Situation and Task set the context. Action and Result carry the weight, and they’re usually where first drafts are weakest.

• Tell the story at the right level. A story can be factually strong and still undersell your scope. Someone who has been on the other side of the table can often spot this quickly.

AI can help with many of these tasks, it can mine your resume for potential stories, ask you clarifying questions, push you to recall further details on a given STAR element, and structure your response.

But judgment about what to include and what to omit is still a human task.

Why AI changes how you build and practice

Once you’ve got direction, AI is incredibly valuable. The thing is, AI can help you earlier in your preparation than just doing mock interviews.

You could start with your resume and ask your AI to flag potential story candidates. Then you can walk through the stories out loud, with your AI coach digging into the fine details: What did you specifically do? What decision did you make? What did you achieve? What did you learn?

This process could take a vague memory from your past, and help you to shape it a story for your interview, while maintaining the details to your experience.

The important thing about that process is that you’re starting with your actual experience, not asking AI to make up a story for you. You can also rely on AI to flag opportunities you may not have thought of, dig into the detail required for a good STAR response, and organize your stories into a categorized library for later use. That’s all a big difference from just asking a chatbot to “write me a STAR answer.”

Another element of preparation is rehearsal. Having developed your stories, you need to actually practice them out loud. You need to become comfortable with the setup, learn how to handle follow-up questions, and identify when you become too preoccupied with the Situation and not focused enough on the Action or Result.

That takes time and practice. That’s where AI can help you to get the repetition and practice you need without using up too much of your time.

You can run mock interviews, repeat the same story, work on the same follow-up questions, and practice what to say without worrying about “how good” your response is. You can experiment and fail and try again without needing to get feedback from coaching each time.

But repetition doesn’t replace the value of practicing with a human. The mock interview process, with real humans, can help you to get comfortable telling your stories in different ways depending on how the conversation goes, how comfortable you are, and how much the interviewer is probing.

That’s why I think the two things complement each other: AI gives you the opportunity for practice and repetition, but a coach can give you valuable judgment and perspective, as well as the experience of an actual human interviewer. You need both.

Human judgment + AI repetition

The best way to think about the combination is not Human vs. AI. It’s Human judgment + AI scale.

The best preparation cycle would look something like this:

1. Use AI assistance to uncover your own raw material. Start with your resume and experiences. Identify potential stories across the eight behavioral themes.

2. Use human expertise to select and shape the strongest stories. Decide which experiences demonstrate the right level of ownership, impact, leadership, judgment, and growth.

3. Use AI to build depth. Talk through each story out loud. Let the AI probe for missing STAR elements, weak actions, unclear decisions, and measurable results.

4. Use AI and human practice to rehearse. AI can give you the repetition you need to practice different questions, follow-ups, and variations of your stories. Human mock interviews add something different: the experience of answering a real person who can react to your answer, notice what you’re emphasizing or avoiding, and push you in unexpected directions.

5. Bring your stories back to a human expert. A final human perspective can tell you whether the story actually lands, whether you’re demonstrating the right level, and where an experienced interviewer is likely to push harder.

The human time goes where judgment matters most. The AI time goes where volume matters most. That’s the combination that makes preparation both more effective and more scalable.

The fastest path to better interview preparation isn’t Human vs. AI. It’s human judgment + AI repetition.

Build Your Story Bank With Me in 4 Weeks

Big Tech Interviews: Build Your Story Bank in 4 Weeks

📅 October 16 to November 8, 2026

Explore the October Cohort

🚀 Have questions before you enroll in the cohort?

Book a Free Discovery Call

The cohort brings the human side of this approach into a structured four-week program. We’ll collaboratively work on the stories that matter most, with direct feedback from me, while you use AI between sessions to build depth and get the repetitions that are difficult to fit into limited coaching time.

The idea isn’t to replace coaching with AI. It’s to make the coaching more valuable by using AI for the work that benefits from repetition.

Over four weeks, you’ll build your story bank, practice delivering it, and get feedback along the way.

By the end of 4 weeks, you’ll have:

• 8 to 12 stories covering all 8 behavioral themes, including Customer / User Focus, Success, Failure, Conflict, Problem-Solving, Learning & Growth, Leadership, and Time Management.

• Senior-level STAR stories that showcase your contributions, decisions, scope, and impact.

• Technical achievements positioned as business-impact and leadership stories to demonstrate the power of your technical skills.

• Practiced “Tell Me About Yourself” and stronger delivery, including vocal and non-verbal communication.

• The resume optimized for Big Tech, communicating your achievements to both ATS systems and recruiters.

• A custom AI-powered tool to prepare for interviews between our sessions, practicing stories, addressing gaps, and answering common behavioral questions.

The goal isn’t to memorize eight answers. It’s to build a flexible story bank that becomes your interview playbook.

What this is and What it isn’t

This is a behavioral and leadership interview preparation course.

We will focus on your story bank for behavioral and leadership interviews, senior-level positioning, resume, communication, delivery, and mock interviews.

As a result, you will have 8-12 stories for each of the 8 behavioral themes to demonstrate your leadership qualities in big tech behavioral and leadership interviews.

It is a behavioral interview preparation course, and it is NOT about DSA or system design. If you are looking to master coding challenges or system design interviews, this is not the right course for you.

If you want to learn how to tell your success story to Big Tech recruiters and interviewers confidently and credibly, this is the right course for you.

Before your next interview

AI has changed interview preparation in a meaningful way. You can now turn your resume into potential story candidates, talk through experiences with an AI coach, get probed for missing STAR details, organize your stories into a library, and run repeated mock interviews. It gives you a powerful way to develop and practice your stories between coaching sessions.

But AI doesn’t eliminate the need for judgment.

You still need to know which stories best represent you, whether your contribution demonstrates the right level, whether your examples show the leadership and impact you’re capable of, and whether the story sounds authentic when you’re sitting across from an interviewer.

That’s why I don’t see this as human expertise vs. AI. I see it as human expertise + AI.

Use a human expert for judgment, perspective, and feedback. Use AI for story development, practice, and repetition. And use the combination to build a story bank you can actually trust when the interview starts.

I’d like to hear how you’re using AI in your preparation right now. What’s working, and where has it let you down? Leave a comment.

See you next Thursday,

Prasad Rao

Hey, Prasad here 👋 I’m the voice behind the weekly newsletter Big Tech Careers. I share practical strategies for Big Tech interviews, behavioral storytelling, technical careers, and professional growth every Thursday.

New to Big Tech Careers?
Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

Every candidate that I coach asks a version of the same question early on: Should I prepare for the Big Tech company I’m interviewing with or prepare in a way that’ll apply to any company?

It seems like a binary you have to resolve before you start. It isn’t. I’ve seen candidates who spent three weeks reading Meta’s culture deck before writing a single story and candidates who built a story bank before figuring out what angle to take an interview at any company. The second group walked into interviews more prepared every time. Let me explain why and how they did it.

They prepared based on common themes rather than predicting every question they might get. They built a bank of stories that they could use for different questions. This way, when an interviewer asked them a question that they didn’t have a prepared answer for, they had a real-life example they could use instead of panicking and making something up.

Having a story bank is better preparation than company research. Company research will tell you what an interviewer is looking for, but it won’t give you anything to say. Three weeks spent poring over a culture deck leaves you knowing which qualities an interviewer is looking for but without any prepared experiences to cite. A story bank organized by theme gives you the proof and applies to whichever company you’re interviewing with. If that interview falls through and another company reaches out, nothing is wasted.

Before you start building those stories, though, take a few minutes to figure out where you stand and what you should work on first.

🚀 Already know where you stand?

Then the cohort may be your next step. Big Tech Interviews: Build Your Story Bank in 4 Weeks starts October 16.

Over four weeks you’ll build your story bank, practice delivering it, and get feedback along the way.

Explore the October Cohort

🚀 Have questions before you enroll in the cohort?

Book a Free Discovery Call

Why prepare by theme

There are hundreds of behavioral questions a Big Tech interviewer could ask you.

Preparation for all of them is impossible, in my experience, and leads to memorizing a stack of answers that are inevitably forgotten in the middle of an interview.

There is another approach, which is based on the fact that many questions in the Big Tech world have a common theme. If you have a solid answer for each theme, you can address any question that falls under it and get the interviewer to accept your response, even if they asked a question you’ve never prepared for. This is why the questionnaire is grouped by themes.

“Tell me about a time you disagreed with a teammate.” “Describe a difficult working relationship.” “How did you handle a colleague who wasn’t pulling their weight?” These three questions may sound different, but they’re getting at a similar skill: how you work through challenging situations with other people. One well-prepared answer to a seemingly random question can potentially serve as a response to all three.

These are the Past Experience / STAR (Situation, Task, Action, Result) stories from the three types of stories you should prepare before a Big Tech interview.

Organizing those stories by theme is what turns them into a useful story bank. It also helps with what happens after your first answer. As I covered in the last article on behavioral consistency, interviewers aren’t just listening to one story in isolation. They’re looking for patterns across your answers. That’s much easier to demonstrate when you have more than one strong story behind each theme.

The 8 behavioral themes and STAR response strategy

If you’ve read the earlier newsletters, these will be familiar. Here they are in one place for quick reference. The focus areas also work as prompts when you map your own experiences in the next step.

How to use the themes in your preparation

Build a story before a call

Start by mapping what you already have. Write down the eight themes, and next to them note the experiences you could turn into a story for today. One line per experience at this stage. Want a structure for the exercise? The questionnaire above guides you through for each theme.

The gaps will reveal themselves. An empty theme represents a story you need to prepare (or revisit). A theme with just one line is thin, since a follow-up question can always ask for another example.

Write each of these stories in STAR form: the Situation, the Task you were responsible for, the Action you personally took, and the Result. Most of the detail belongs in the Action. That’s where the interviewer learns how you think, and it’s often what candidates rush through.

Weigh all of that to your career stage, your role, and your level. Some themes will matter more to interviewers than others, and will need to have more stories attached. A staff engineer’s Leadership stories should be substantially different from someone two years into their first role. Keep at least one story for each theme, but put more depth into the ones that will be tested.

When Big Tech calls, calibrate. Don’t start over.

Once an interview with a specific company is confirmed, your story bank is your point of departure. Start with what the company has publicly said about how it thinks about its hiring and priorities. Match up those areas with your eight themes, decide which stories you’ll lead with, and deepen where the company is likely to press.

Say a company’s published values put a premium on the customer. Your Customer/User Focus stories move to the front of the queue, and if you only have one, finding a second becomes your priority in the coming week. The rest of the story bank remains as it is, since you can always be asked about any of the eight themes.

Since every theme already has at least one story behind it, you’re calibrating emphasis rather than starting from scratch. That’s a much calmer place to be in the final days before an interview, and it’s the advantage the second group had when they walked in.

Tell me in the comments: Which theme did you assume you had covered, until you tried to name a real experience for it? And which one feels hardest for your current role?

The best interviews feel more like conversations than interrogations. When you have thoughtful stories ready for each of these themes, you can have that conversation, whatever question opens it and whichever company is asking.

🚀 Already know where you stand?

Then the cohort may be your next step. Big Tech Interviews: Build Your Story Bank in 4 Weeks starts October 16.

Over four weeks you’ll build your story bank, practice delivering it, and get feedback along the way.

Explore the October Cohort

🚀 Have questions before you enroll in the cohort?

Book a Free Discovery Call

Helpful Resources:

• Templates to Customer Focus, Success and Failure Stories

• Templates for Conflict, Problem-Solving and Learning/Growth Mindset Stories

• Templates for Leadership and Time Management Stories

See you next Thursday,

Prasad Rao

New to Big Tech Careers?
Subscribe to join a tribe of 37k+ and level up alongside engineers and architects.

Subscribe now

“I haven’t worked at a Big Tech company.”

“My current company isn’t well known.”

“I don’t have enough experience.”

These are the reasons people tell me why they cannot apply. I understand all of them because I, too, once believed these were the obstacles preventing me from applying to my own Big Tech interview. Before my interview, I hadn't applied anywhere. I had decided I didn't belong there.

What I’ve learned is that these objections are all about background, and most of the interview actually looks at something else. The questions asked are about decisions I had made, problems I have had to workaround, people I have had to disagree with, and things that had not turned out the way I wanted.

Your resume gets you in the door. What happens next is a conversation about your experience.

📄 Free resource: Big Tech Behavioral Interview Story Questionnaire

Before you continue, it’s worth knowing where you are on the road to a Big Tech interview. Based on similar eight behavioral story categories and STAR templates I’ve shared in previous newsletters, I‘ve put together a short questionnaire to show you where your story bank is currently prepared and where you may need to prepare before your next interview.

Get the free resource

Readiness is not a feeling

Here is the bit where I want to get your attention as I was not ready myself during my interview process. Neither before, during nor after the interview.

The feeling will never arrive, and waiting for it to arrive can waste years of your life.

One has to ask another question. And that is, given the example, can you come up with a good one on your own? Well, you can test it yourself this week.

Imposter syndrome and the fear of not having enough years of experience are the two most common interview questions.

The imposter syndrome will remain with you no matter how many years you have been dealing with it. Documentation is your friend. Assemble the projects you have been working on, the decisions you have made, and the outcomes you have witnessed. The feeling can remain, but you will have something to return to.

Years of experience do not matter as much as one may think because the behavioral part of the interview tests your mind, and not your years of service. A candidate with six years of experience, who can speak of the trade-offs they have had to make, will appear more qualified than another candidate with twelve years, who can tell you precisely what happened without passing judgment.

What readiness actually looks like

Interviewers tend to ask behavioral questions around a predictable set of themes: Customer/User Focus, Success, Failure, Conflict, Problem-Solving, Learning/Growth Mindset, Leadership, and Time Management.

Once you see the themes, preparation is no longer a guessing game. Instead of guessing at the exact wording of a question, you make sure you’ve got experiences that cover each one and are well structured to withstand someone asking deeper questions.

That collection is your story bank. I’ve talked about the three types of stories needed to come into these interviews prepared: your Elevator Pitch, your Technical Stories, and your Past Experience / STAR Stories. The last is often the largest weight, because one story per theme is rarely enough. The same skill shows up across multiple interview rounds, and a deep story bank lets you choose the experience that best matches what’s actually been asked.

Use STAR to organize each one. Situation and Task establish the context, Action makes your own decisions and contributions visible, and Result show what‘s changed because of what you did.

The largest problem most candidates have is that they get their Situation and Task right but miss the Action. They tell you what the team decided to do, rather than what you decided to do. The interviewer is building a profile of you, and the pronouns are more important than you realize.

The introduction is worth more attention than most folks give it. One candidate, who worked through this with me, later told me that the one-minute elevator pitch determined three of his four interview rounds because it established a tone that the others followed.

You have more influence over where an interview goes than you think.

A quick test of your own story bank

Pick a theme you think you’ll be asked about. A failure story is a good place to start because it’s the one people tend to avoid preparing for.

• Can you name a real experience within a few seconds?

• Can you lay it out in STAR without having to dig for details?

• Can you say clearly what you personally decided and did, rather than what the team did?

Now take a look at how an interviewer would probe you. Say you told a story about a project that was late. A good follow up sequence would be, why that approach, why other approaches didn’t work, who was against you and how you overcame it, when you realized it was going to be late, and what would you do differently. That last question is what trips up a lot of people who think they’ve prepared a decent story but have no idea how to reflect on the experience.

Go through that same process for the other seven themes and suddenly those gaps become obvious, along with exactly how specific they need to be. You’ll even know that you need two more examples for Leadership and your story for Conflict doesn’t stand up to a second question. That means you can now take a preparation checklist and work off of it, rather than an unease that you’re not prepared.

If you prefer to work this out more systematically, the questionnaire at the top of the page covers all eight themes.

Give it a shot and let me know how it went. What’s the weakest of the eight themes for you right now? What was the one that seemed most obvious to you before you had to lay it out and look for the weaknesses? Leave a comment. I read them all, and the answers tend to lead to what I write next.

You’re also interviewing them

The questions you ask at the end of the interview process are another part of this. Ask about the challenges of the position, how the team interacts with each other, and how the position will allow you to grow professionally. When you ask these types of questions, you send a clear message to the interviewer that you are taking the potential job offer seriously.

Additionally, asking these kinds of questions can assist you in determining if the position is a good match for your career goals once you receive the job offer. All of the top candidates I’ve seen share one common thread. Each candidate knows exactly what they did, why it mattered, and what they learned from that experience. I had to look through hundreds of job postings on a large tech company website before I found a single posting that fit my background. There’s no getting away from this; you simply need to invest time into preparing your “story.” You can begin preparing your “story” immediately.

🎓 Preparing for a Big Tech interview?

My next cohort, Big Tech Interviews: Build Your Story Bank in 4 Weeks, is running from October 16 to November 8.

You build 8 to 12 stories across all eight behavioral themes, and then test them under pressure through live mock interviews organized theme by theme. We also cover how long an answer should be, how to handle follow-ups, and what to do with scenario questions where you don’t have direct experience.

In week three, hiring managers and Principal-level professionals from Big Tech and AI labs join us for a panel on what they actually look for in behavioral rounds.

See what we cover →

I’ll share more on how to strengthen these stories in the coming newsletters.

See you next Thursday,

Prasad Rao

Here’s what I’ve noticed: the strongest candidates reveal something real through their stories. AI has made it easy to memorize STAR answers and coding interviews can be studied. But behavioral patterns can’t be faked. They show whether you’ve actually learned and genuinely collaborate.

That’s why interviewers now rely more on behavioral consistency. It separates candidates who sound prepared from those who actually are.

These questions take you back to situations that have already happened because a real experience gives the interviewer something concrete to examine. They can look at the decision you made, how you worked with other people, what you personally did, and what happened afterward.

This idea is often described as behavioral consistency. Your past experiences give interviewers evidence of how you have handled similar situations before, and across several answers, they can start to see patterns in how you operate.

Preparing for a Big Tech interview?

I spend more time on helping participants choose, structure, and practice these stories inside the cohort. The same approach applies across Big Tech roles because every role requires candidates to explain their decisions, collaboration, and impact.

If a more structured approach would be useful for your preparation, you can see what we cover here.

See what we cover →

How interviewers build a pattern from your multiple stories

Suppose you share a strong conflict story. The interviewer can see how you handled one disagreement, but they are still learning about the broader way you work.

A leadership story may show how you influence people when you do not have formal authority. A failure story can reveal how you respond when your decisions do not produce the expected result, while a problem-solving story can show how you evaluate alternatives and make a decision.

Across those examples, the interviewer has more evidence to work with. They can begin to see whether qualities such as ownership, judgment, collaboration or adaptability appear consistently in your work.

This connects directly to something I covered in my previous article on the three types of stories you should prepare before a Big Tech interview.

In that article, I talked about three types of stories: your Elevator Pitch, your Technical Stories, and your Past Experience / STAR Stories. I also shared the eight behavioral themes I use to build a stronger story bank.

The important part is building a story bank with enough relevant experiences. You need different examples that allow you to answer different questions naturally.

Behavioral consistency includes showing growth through your experiences

Behavioral consistency does not mean that every story should show you responding in exactly the same way throughout your career. Your experience should change how you work.

An earlier project might have taught you to involve stakeholders sooner. A difficult customer situation may have changed how you gather requirements, while a failed initiative may have changed the way you identify risks before execution begins.

A useful interview story can therefore show both what you did and what the experience changed. Later examples give the interviewer a chance to see whether you actually applied what you learned.

Build a Story Bank Strong Enough for Interviewer Follow-Ups

Start with experiences you genuinely know well. You should remember the situation, who was involved, the constraints you were working with and the decisions you made. When an interviewer starts probing, those details become important.

Use STAR to organize the answer. Situation and Task establish the context, Action should make your own decisions and contribution visible, and Result should show what changed because of what you did.

Prepare more than one strong example. The same behavioral skill may appear in several questions, and a deeper story bank gives you room to choose the experience that actually fits the question.

Prepare for follow-up questions. An interviewer may ask why you chose one option, what alternatives you considered, whether someone disagreed, what you learned or what you would do differently today. Your preparation should go deep enough that those follow-up questions feel natural.

STAR remains the structure across Prasad’s behavioral templates, while the details change depending on the theme being tested. The three-part series covers Customer/User Focus, Success, Failure, Conflict, Problem-Solving, Learning/Growth Mindset, Leadership and Time Management.

How ready is your current story bank?

Take one behavioral theme you expect to be tested on and try a simple check.

Can you identify a real experience quickly? Can you structure it using STAR, explain your individual contribution and answer a deeper follow-up without searching for details?

Then run the same check across the other behavioral themes.

That is where gaps usually become easier to see.

Free Resource: Big Tech Behavioral Interview Story Questionnaire

I have put together a short Big Tech Behavioral Interview Story Questionnaire based on the same eight behavioral story categories and STAR templates I have shared across previous newsletter.

The questions are designed to help you identify which parts of your story bank are already prepared and which areas need more work before your next interview.

Get Free Resource

The goal is to leave with something specific to work on.

If Leadership is an area you need to strengthen, you will know which stories to develop next. If Failure is an area where you need more preparation, you can focus on building stronger examples.

I’ll share more on how to strengthen these stories in the coming newsletters.

See you next Thursday,

Prasad Rao

Why?

Because interviewers aren’t only evaluating what you know.

They’re also trying to understand:

How do you actually operate at work?

How do you make decisions?

How do you handle trade-offs?

How do you work with others?

What do you take ownership of?

And what changed because of your contribution?

Before your next Big Tech interview, prepare 3 types of stories:

1. Your Elevator Pitch

Why you’re relevant.

2. Your Technical Stories

How you apply what you know.

3. Your Past Experience Stories

How you operate when the work gets difficult.

One important distinction:

I mean three types of stories not three stories in total.

Your elevator pitch may be one prepared introduction.

But you should build multiple technical stories across your career and a bank of past-experience stories that you can adapt to different behavioral questions.

That’s what we’re going to look at today.

Hey, Prasad here 👋

In my experience, some of the strongest candidates struggle in Big Tech interviews for a reason they don’t expect.

It’s not always because they lack technical knowledge.

They know the concepts.

They’ve worked on complex projects.

They may even give the technically correct answer.

But when the interview ends, the interviewer can still be trying to understand:

How does this person actually operate at work?

That’s the gap many technically strong professionals underestimate.

And it matters even more in today’s market.

Why This Matters in September 2026

Nearly 60% of active IT-services hiring demand across the world is concentrated in mid-senior and senior roles, while employers are increasingly prioritizing professionals who can apply AI, cloud and digital skills to real business problems.

So knowing the technology is important.

But demonstrating how you used it, why you made certain decisions, and what impact you created is what helps differentiate you.

Your stories provide that evidence.

Let’s look at each type.

1. Your Elevator Pitch: Don’t Tell Your Entire Career Story

Almost every interview starts with:

“Tell me about yourself.”

It’s predictable.

Yet many candidates still improvise it.

A common answer sounds like:

“I started at Company A, then moved to Company B, became a senior developer, and now I’m a tech lead…”

There may be nothing wrong with that information.

The problem is that the interviewer has to figure out what matters.

Your elevator pitch should do that work for them.

Think of it in three parts:

1. Who are you?

“I’m a tech lead with eight years of experience building cloud platforms.”

2. What’s the most relevant evidence?

“I currently lead a team focused on reliability and scalability of a customer-facing platform.”

3. What’s the impact and where are you heading?

“Recently, I helped redesign a critical service that improved uptime from 98.5% to 99.9%. I’m now looking to take on larger architecture and cross-functional leadership responsibilities.”

Notice what’s happening here.

The candidate hasn’t told me everything.

They’ve told me what I need to know to decide:

“I want to learn more about this person.”

Before your next interview, ask yourself one question:

If the interviewer remembers only one thing from my introduction, what do I want it to be?

Build your pitch around that.

2. Your Technical Stories: A Correct Answer Is Only the Starting Point

Imagine ten candidates interviewing for the same engineering role.

Seven answer the technical question correctly.

You’re one of those seven.

Why should the interviewer choose you?

Let’s say the question is:

“What is a load balancer?”

You might answer:

“A load balancer distributes network traffic across multiple servers to prevent one server from becoming overloaded. It improves availability and reliability by routing traffic to healthy servers.”

Correct.

But now imagine you’re the interviewer.

What did you learn about this candidate?

You know they understand load balancing.

That’s about it.

Now add real experience.

“In my previous role, our e-commerce platform experienced slowdowns during peak shopping periods. I worked with the infrastructure team to implement an Elastic Load Balancer using a least-connections approach.

This helped distribute traffic more effectively, allowed maintenance without disrupting users, and improved uptime from 98.5% to 99.9%.”

Now the answer is doing something different.

The interviewer can see:

• Technical knowledge

• Real-world application

• Collaboration

• Customer impact

• Measurable results

But for an experienced candidate, I would still want to know more.

Why least-connections?

What did you personally own?

What alternatives did you consider?

What constraint affected the decision?

Did anyone disagree?

Those answers reveal something a definition never can:

Your judgment.

That’s the level you should be aiming for and multiple such technical stories for the strongest projects you’ve in your careers.

A Simple Way to Prepare Your Technical Stories

For one technical topic you expect in your next interview, answer:

The problem was: ______

My role was: ______

We decided to: ______

Because: ______

The alternatives or trade-offs were: ______

I personally owned: ______

I worked with: ______

The result was: ______

You don’t need to say every one of these lines during the interview.

The exercise simply forces you to understand your own story.

And that’s usually where candidates discover the real gap.

They often have enough experience.

They just haven’t identified which parts of that experience demonstrate ownership, judgment, collaboration and impact.

If You Want More Structure

This is also part of what I work on with candidates in my Big Tech Interviews: Build Your Story Bank in 4 Weeks cohort on Maven.

We work on turning real experience into interview-ready stories, using STAR effectively, translating technical wins into business impact, and pressure-testing those stories through practice.

But you don’t need to join a cohort to start doing this.

Use the exercise above and begin with one experience.

Then another.

The principle stays the same:

Don’t stop at what you know. Prepare the evidence of how you’ve used it.

3. Your Past Experience Stories: Show How You Operate

Most candidates already know STAR:

Situation → Task → Action → Result

So knowing the acronym isn’t the real problem.

The problem is how candidates use it.

A common behavioral answer spends most of the time explaining:

the project…

the company…

the team…

the technology…

the deadline…

And three minutes later, the interviewer still doesn’t know:

What did YOU actually do?

Your behavioral story isn’t a project summary.

It’s evidence of how you operate.

And STAR remains the core structure.

The important part is what you put inside that structure.

STAR gives you the structure.

Your context, decisions, judgment, collaboration and impact give the answer depth.

For example, saying:

“There was a disagreement in the team, but eventually we resolved it.”

doesn’t demonstrate much.

The interviewer wants to understand:

What was the disagreement?

What was your position?

What did the other person believe?

How did you approach the conversation?

Did you change your mind?

Did they?

What was the eventual result?

That’s where behavioral skills become visible.

Build your Story Bank

There are hundreds of behavioral interview questions.

You don’t need hundreds of memorized answers.

Instead, build your story bank around the 8 behavioral themes:

1. Customer / User Focus

2. Success

3. Failure

4. Conflict

5. Problem-Solving

6. Learning / Growth Mindset

7. Leadership

8. Time Management

I have five questions for each of these eight themes.

That’s 40 questions you can use to test whether your preparation is strong enough.

But answering 40 questions does not mean memorising 40 different stories.

The goal is to build a smaller bank of strong experiences that you understand deeply enough to adapt naturally.

A strong story may help you answer more than one question depending on what the interviewer is evaluating.

For every story, ask:

What does this story prove about me?

If you can’t answer that clearly, the story probably needs more work.

The 3 Types of Stories Work Together

Your interview isn’t a collection of isolated questions.

The three types of stories build a picture of you.

Your Elevator Pitch says:

“Here’s why my background is relevant.”

Your Technical Stories say:

“Here’s proof that I can apply what I know, make decisions and create impact.”

Your Past Experience / STAR Stories say:

“Here’s how I operate when the work becomes difficult.”

Together, they help move the interviewer from:

“This candidate knows the material.”

to:

“I understand how this person could operate on our team.”

That’s the shift you’re trying to create.

So before your next Big Tech Interview, start preparing these 3 types of stories. Identify gaps in your stories and fill them as you prepare to ensure you get ace your interviews.

If you’re preparing for Big Tech interviews and want a more structured way to build and practice your story bank, I cover this in depth in Big Tech Interviews: Build Your Story Bank in 4 Weeks on Maven.

It’s there if you want the additional structure, practice and feedback.

Explore the Program

See you next Thursday,

Prasad Rao

Welcome to this week’s article, in which I share the real reason people are unable to clear big tech interviews. I’m also opening enrollment for my next live cohort, running October 16 to November 8. The first 10 people who enroll get 10% off with the code FIRST10. First 5 people will get a 30 mins 1:1 session with me during the cohort. Details are here, or keep reading to see why this matters first.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

Were you rejected at a big tech interview? Even after you felt your interview went well.

You’re not alone. Every year, thousands of talented professionals face rejection from big tech companies.

The frustrating part? Most of you have the technical or functional domain skills to excel at these companies.

🔍 The Hidden Truth About Big Tech Rejections

As someone who frequently conducts interviews at a big tech company, I’ve noticed that many candidates come to their interviews significantly underprepared.

I’m not talking technical interviews or your functional domain knowledge interview. Candidates ace those!

The real issue? Behavioral interviews.

The part most people dismiss as ‘the easy stuff.’

Ask any experienced interviewer at big tech why candidates fail their interviews.

Their #1 reason is consistent:

💡 Smart technical professionals who can’t clearly articulate their past work. They ramble too much, miss the main points, and can’t explain their decision-making process.

I see it all the time.

Most people have impressive resumes and experiences, but they struggle to communicate their impact effectively.

I took six weeks to prepare for my loop interview. Everyone I know who works at big tech invested significant time in interview preparation.

This isn’t a coincidence. It’s a pattern of success.

If you want to clear big tech interviews, TAKE TIME TO PREPARE!

⚠️ Why Even Strong Technical Candidates Fail

Let’s break down the common patterns that sink otherwise qualified candidates:

1. The “Wing It” Mentality

Many people think their technical expertise will carry them through.

They spend weeks preparing for technical and functional fit interviews but zero time preparing for behavioral questions.

Big mistake.

Big tech companies put equal (sometimes more) weight on behavioral assessments.

2. Scattered Storytelling

When asked about past experiences, candidates often:

• Ramble without structure

• Miss crucial details while including irrelevant ones

• Fail to highlight their specific contributions

• Cannot articulate the impact of their work

3. Leadership Blindspots

Technical excellence alone isn’t enough. Big tech companies seek people who can:

• Drive initiatives beyond their immediate scope

• Handle conflicts professionally

• Influence without authority

• Make data-driven decisions

4. Interview Anxiety

Even seasoned professionals freeze up when facing big tech interviewers. This leads to:

• Blanking on well-prepared stories

• Speaking too fast or too slow

• Missing important context

• Failing to build rapport with interviewers

🕰️ The Real Cost of Failed Interviews

Every failed big tech interview costs you more than just time:

• Lost compensation (often $100K+ difference annually)

• Missed stock appreciation opportunities

• Career growth setbacks

• 6+ month cooling period before reapplying

• Damaged confidence

💡 What Successful Candidates Do Differently

The candidates who consistently land big tech offers share one thing.

They have a story bank.

A story bank is a set of 8 to 12 prepared stories that cover every theme a big tech interviewer can draw from:

1. Customer focus

2. Success

3. Failure

4. Conflict

5. Problem-solving

6. Learning and growth

7. Leadership

8. Time management

Whatever the question, one of your stories fits. No blanking. No rambling. No “let me think of an example.”

But a story bank alone isn’t the full picture. Successful candidates also:

• Deliver every story in STAR format with senior-level depth, so they get hired at the right level

• Translate technical wins into business impact

• Pressure-test their stories in mock interviews before the real thing

• Build interview stamina for 4-8 round marathons

This isn’t luck or talent. It’s a learned skill anyone can build with the right structure and practice.

I share most of this for free in this newsletter, one article at a time. Subscribe and follow along.

Subscribe now

🎯 Build Your Story Bank With Me in 4 Weeks

If you want to build your story bank with direct feedback rather than alone, I’m running my next live cohort on Maven:

Big Tech Interviews: Build Your Story Bank in 4 Weeks

📅 October 16 to November 8, 2026

⭐ Rated 4.9 out of 5 by past students

If you're targeting a big tech role in 2026 or early 2027, this October cohort is the one to grab.

Over 4 weeks, we work together to build your complete story bank and pressure-test it until it’s second nature.

🧠 What you’ll walk away with

✅ 8 to 12 stories across all 8 behavioral themes

✅ Every story in STAR format with senior-level depth, so you get hired at the right level, avoiding a down-level offer

✅ Technical wins told as business impact, and leadership stories that show ownership

✅ A practiced “tell me about yourself” and confident delivery: voice, pacing, body language

✅ Mock interviews with me, with direct feedback on your stories

✅ Access to a custom AI tool to build and rehearse your stories out loud between sessions, with instant feedback on structure, depth, and delivery

🚫 What this cohort does NOT cover

❌ DSA (Data structures and algorithms) interview preparation

❌ System design interview preparation

❌ Technical interview preparation

❌ Product/Project management interview preparation

I won’t be diving into technical concepts here. You’ve already got those skills.

Instead, I’ll focus on helping you tell your professional story in a way that resonates with hiring managers and increases your chances of landing your desired role at the right level.

🙋🏻‍♂️ Who is this cohort for?

• Tech ICs and leaders targeting their first big tech role

• Strong performers who freeze or ramble when asked “tell me about a time when...”

• Senior ICs and managers who want the role at the right level, and want to avoid a down-level offer

📅 How does the cohort run?

• 11 live sessions across 4 weekends (Oct 16 to Nov 8)

• 4 to 6 hours per week: live sessions, plus 2 to 4 hours writing and practicing your own stories

• A community of accomplished peers preparing alongside you

This is a live, hands-on cohort. You write your actual stories, get feedback on them, and practice them in mock interviews with me and with peers. You leave with a finished story bank ready for your interview.

The first 10 people who enroll in the October cohort get 10% off with the code FIRST10. And the first 5 get a 30 minute 1:1 session with me during the cohort, on top of the discount.

ENROLL IN THE OCTOBER COHORT

💸 How much does it cost?

The cohort is priced at $2,000.

I know that’s a real investment. Here’s how I think about it: a failed big tech interview often costs $100K+ in annual compensation and locks you out for 6+ months. A down-level offer costs even more over the years you spend climbing back to your actual level. Measured against that, 4 weeks of focused preparation is the cheapest part of the entire journey.

By the end of this cohort, you’ll have a complete story bank and everything you need to walk into big tech interviews prepared. But you’ll have to put in the required effort to be successful.

Not sure if this cohort is right for you? Have questions?

• Send an email at info@bigtechcareers.com

The first 10 people who enroll get 10% off with the code FIRST10. And the first 5 get a 30 minute 1:1 session with me during the cohort, on top of the discount.

Claim 10% Off Now

You didn’t get a newsletter from me last Thursday. That was a miss, and I want to talk about why, because I think the miss is as useful to you as most of what I’ve published this year.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

The two misses

1. I skipped a week.

One of my goals for 2026 was to publish one newsletter article every single week. Last week I didn’t. The two weeks before that were entirely eaten by BeSA Cohort 10 prep: 10,000+ registrations, provisioning AWS sandbox for hands-on Amazon Bedrock AgentCore workshop for 2000+ people, a fireside chat with Matt Wood, and 10+ AWS volunteers to coordinate. Something had to give, and the newsletter gave.

2. Zero out of three Claude certifications.

When I passed the Claude Certified Architect Foundations exam, I shared it here and on LinkedIn. My plan was to finish the three newer Claude certifications by the end of August. It’s the 27th. I haven’t sat a single one. I haven’t even properly started studying.

If I’m going to share the pass, I should share the miss. Same rules both ways.

What LinkedIn doesn’t show you

Ritendra Datta, who leads engineering at OpenAI, posted something this week that stuck with me. His point: LinkedIn’s feed is survivorship bias in action. People are living through their own hard stretches and posting only the highlights. In his words, “Nobody is posting about the hell.”

Read his full post below:

If you are feeling low staring at all the LinkedIn updates about someone’s funding round, someone’s fancy new job, or someone’s fancy new title from a promotion, while you struggle with your own situation, let me remind you: like most social networks, LinkedIn’s feed is a case study in survivorship bias. Everyone is living through their own hell; they’re just sharing the very best things happening to them. Nobody is posting about the hell. Behind every successful funding round are countless failed pitches, every landed job comes after rejections and ghosting, and every promotion has its share of negotiations, disappointments, politics, heartbreaks, and failed attempts. And that's just those with *some* good news to share eventually. There are many still waiting for that moment.

Nothing new here, but a reminder from time to time helps.

How do I know? Well I don't, but it's a good guess based on anecdotes. The ratio of good news to bad news people share with me IRL is usually much worse than what their feed represents. These ratios seem to be drawn from very differently shaped beta distributions. I also don't really post about my own failures, and I've failed many times, e.g. I once got a very good leadership job at LinkedIn and didn't take it. Couple years later, I applied again and failed the interviews 🤷. I wouldn't have shared that in isolation, sharing only because context and it feels 'safer' now.

Failure is where some of the best learning happens. But when a platform overwhelmingly distributes success stories, it teaches us to share just the good news, and the learning gets minimized while comparison and regret get maximized. You see everyone else’s outcomes while living through your own process, and that is a fundamentally distorted comparison.

I get incredible value from Linkedin because I've learned to use it in specific ways that work for me as a learning platform. Perhaps the most useful thing to learn from LinkedIn, then, is how not to be fooled by LinkedIn posts: take the feed with a grain of salt, build resilience, recognize the survivorship bias, and learn to separate signal from noise.

He went further and shared that he once turned down a strong leadership role at LinkedIn, applied again a couple of years later, and failed the interviews. That’s a senior leader at OpenAI telling you he got rejected. You would never have guessed it from his profile.

Now look at my LinkedIn. It may seem like I do everything.

I don’t. You’re seeing the output. You’re not seeing the process. You’re not seeing the number of failures leads to the output you are seeing. WHY? Because I don’t share my failures as openly as I share the success. And everyone is doing the same - sharing only their successes.

Ritendra put it well: you see everyone else’s outcomes while living through your own process. That’s a rigged comparison, and you will lose it every time if you don’t notice it’s rigged.

Missed goals are a signal, not a verdict

Here’s how I think about it. If I’m hitting every goal I set, my goals are too small. Missing some of them means I’m aiming at things that actually require stretch. Shoot for the stars and you’ll still reach the moon.

That’s not an excuse to be sloppy. It’s a reason to look at the miss and ask what it’s telling me.

What the miss told me

Ritendra’s post had one more line I keep coming back to: failure is where some of the best learning happens. So here’s the lesson from mine.

I cannot do everything alone.

I already know this. BeSA is proof. It works because it’s not my project but a community’s project. Ashish and Parna delivered the technical session at the kickoff. Volunteers worked relentlessly behind the scenes for setting up the logistics. Community Volunteers supported the workshop over the weekend. I’m one of many hands now, and that’s exactly why it scales.

I’ve been running this newsletter the opposite way. Every idea, every draft, every edit, every send: me. That worked until it didn’t, and last Thursday is when it didn’t.

So I’m changing it. I’m hiring someone to help me run Big Tech Careers newsletter, on the content and growth side, to take it to the next level. I’m always open to work with creative and dedicated professionals. So hit me up for a chat if you’re interested to know more.

Your turn

If you’re behind on a goal you set in January, you’re in good company. Most of the people whose posts made you feel behind are behind on something too. They’re just not posting it.

Look at your miss. Ask what it’s telling you. Then fix the system, not your self-esteem.

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• Everything You Need to Know About BeSA Batch 10

• The AI Job Market Has Split in Two. Here’s Which Side You Want to Be On.

• How to Transition from a Developer or Architect to AI FDE Roles

When you’re ready, here’s how I can help:

• 1:1 long-term career coaching to fast-track your career growth at Big Tech

• Behavioral Interview preparation course for MAANG+ companies

• Mock interviews for your upcoming interviews

For more details, send an email to info@bigtechcareers.com

In this week’s article, I share the 5 behavioral shifts that solutions architects need in the age of agentic AI.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

AI can now generate designs and architecture in minutes. It can compare services, draft documentation, and produce infrastructure-as-code faster than any human.

That is not the threat. The threat is that many solutions architects built their entire value around doing those things manually. And now the question is: what is left?

These five behaviors were always the real differentiators that technical work used to obscure.

Let’s get into them.

1. Proactive Engagement

Most solutions architects walk into a customer meeting and start by asking questions. It feels natural. It is also reactive.

The problem is you are rarely the first SA that customer has spoken to. If they have to explain their situation from scratch again, you have already lost ground.

The shift is to show up with a point of view, not a blank page. Before the meeting, spend 45 minutes doing AI-assisted research. Brief your AI tool on the customer, the industry, the regulatory landscape, and the modernization challenges companies like theirs typically face.

A question that helps: what do I already know about this customer that AI can help me build context around?

Then take it further. Ask the technical account manager about the stakeholders and their concerns. Then feed that into your AI tool and generate likely objections and responses before you walk in. You are not just preparing to answer questions. You are preparing to anticipate them. That’s the differentiator.

Showing up prepared builds trust. It also stops the customer from having to repeat themselves.

The question to ask yourself: Before my next customer meeting, can I articulate three things I already know about their situation without them having to tell me?

2. Outcome Oriented Communication

Most SAs are proud of the technical solution they built. So naturally, that is what they lead with. They talk about the orchestrator, the tools, the agent architecture, the token optimization. They jump straight into how they built the system.

The best SAs do the exact opposite.

They show the business outcome first. Show the data, the result, the time saved, the problem solved. They don’t spend time talking about the how until they have articulated the business value.

This matters even more with agentic systems because they are hard to demo. The chat window shows planning, thinking, reasoning. It disappears and comes back. You cannot demo that process in a way that lands with a non-technical executive. Demo the outputs. Show a side-by-side: here is what we got before, and here is what the agentic system produced. Then let that difference for itself.

The technicalities of how it is done are just the medium. The business outcome is what matters to the customer.

The question to ask yourself: If I removed every mention of a specific technology from my presentation, would the business value still be clear?

3. Human Contextualization

AI can get you 65 - 75% of the way to a solid architecture. It can research the industry, generate discovery questions, and produce reference architectures in minutes. Filling in that remaining 25 - 35% is what puts you ahead.

That gap is human context. The messy, political, budgetary reality that no AI tool can access.

AI cannot tell you that the customer’s CTO Dave is extremely cost conscious because the board is pushing for a 20 percent infrastructure cost reduction by end of year. It also cannot tell you that the CISO Priya is risk-averse and will push back hard on anything that touches customer data.

That information comes from the technical account manager, from real conversations, from paying attention. AI gives you the industry baseline. The human context is what makes it real for that specific customer.

The shift is to layer both together. Use the industry landscape AI provides, then combine it with the specifics you know about the dynamics of the people in the room. That combination is what turns a technically correct architecture into one the customer actually trusts and adopts.

The question to ask yourself: Can I name the top concern of every stakeholder who will be in my next meeting, without guessing?

4. Validation

AI can generate an architecture in minutes. But most architectures do not fail because they are technically wrong. They fail because the SA did not anticipate the questions that matter most to the customer.

Before the solution lands on a customer’s desk, run it through three questions.

1) Does it match the actual constraints I am dealing with right now?

2) Have I validated these claims and confirmed that this works?

3) Can I defend this in a room full of skeptics?

If the answer to any of those is no, you are not ready to present.

This is where you need to use AI against itself. Prompt the model to act as a skeptical CTO and generate the ten hardest questions that would challenge the design holistically.

Business risk, technical feasibility, operational complexity, hidden costs. Then prepare answers, with tiered options backed by real numbers.

For example, the customer asks: what happens if there is a regional outage? Do we lose all orders?

Instead of coming in with a vague reassurance, come in with three options.

Option A: accept the risk, estimated downtime 2 - 4 hours, revenue impact around $10,000.

Option B: add multi-region failover at $800 / mo, reduces downtime to minutes but adds operational complexity.

Option C: introduce a queuing layer at $20 / mo, orders are buffered during outages and processed when service recovers, no lost orders.

AI surfaced the options. You framed them in a way that lets the customer make a decision they feel confident about.

Trust, but verify. Every single time.

The question to ask yourself: Before I present, have I stress-tested my own recommendation by prompting AI to challenge it from the customer’s perspective?

5. The Identity Shift

This is the one that most SAs struggle with. And it is the one that makes the other four possible.

For years, your worth as a solutions architect was defined by what you knew. How many services could you memorize? How many certifications did you hold? Could you recite the differences between EBS volume types from memory?

AI filled that moat overnight. Anyone can now ask a model to compare services and get an accurate breakdown in seconds.

If your identity is tied to what you know, you will see AI as a threat. The SAs who resist AI the hardest are almost always the ones whose entire professional identity is built on technical knowledge.

But knowledge was never the real moat. The real moat is synthesis. Taking the technical capabilities, the business requirements, the human constraints, and the risk tolerance and synthesizing all of that into a coherent architecture that works in the real world. Not in a vacuum. In the actual messy environment where budgets are limited and the executives have been burned before.

Use AI aggressively for the knowledge-heavy work. Then reinvest the time you save into deeper customer conversations.

The job is not to be better than AI at what AI does well. It is to be indispensable at what AI cannot do.

The question to ask yourself: When asked what I do, do I start with a laundry list of tools or do I speak in the outcomes I deliver?

The Bottom Line

These five behaviors are not new. Good SAs have always done their homework, led with outcomes, read the room, validated their work, and thought beyond technical knowledge.

What is new is that AI removed the excuse for not doing them. What is left is the human layer - and if you cannot do these five things, there is nothing left to justify your seat at the table.

Every one of these behaviors is learnable. They are not personality traits. They are behaviors, and behaviors can be practiced.

Pick the one where the gap is biggest for you right now. Work on that first.

Want to Build These Shifts Alongside a Community?

BeSA Batch 10 starts 22 August and the entire behavioral track is built around Facilitation skills

Six sessions. Six Saturday mornings. Completely FREE.

Here’s the full behavioral track agenda:

Sessions run live every Saturday and are streamed on the BeSA YouTube channel. The recordings go up after each session if you miss a week.

👉 Register here: https://besa.techexpert.io/program/self-paced-become-a-solutions-architect-agentic-ai-on-aws-3849

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• Everything You Need to Know About BeSA Batch 10

• The AI Job Market Has Split in Two. Here’s Which Side You Want to Be On.

• How to Transition from a Developer or Architect to AI FDE Roles

When you’re ready, here’s how I can help:

• 1:1 long-term career coaching to fast-track your career growth at Big Tech

• Behavioral Interview preparation course for MAANG+ companies

• Mock interviews for your upcoming interviews

For more details, send an email to info@bigtechcareers.com

In this week’s article, I make the case for a skill that most tech professionals never formally develop i.e. facilitation skills

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

You’re in a room or on a call with a customer or a set of stakeholders. There are three competing technical opinions on the table. A decision-maker who hasn’t said a word in twenty minutes. A conversation that’s been going in circles for the past half hour. And a decision that needs to be made before end of day.

The person who moves that room forward is almost never the most technically brilliant person in it. It’s the person who knows how to facilitate.

I’ve sat in hundreds of technical meetings across my career. The single most consistent pattern I’ve noticed: your functional skills and technical depth gets you into the room. Facilitation is what makes you valuable once you’re in it.

And yet almost nobody in tech ever formally develops this skill. It’s not in your computer science degree. It’s not in your company onboarding. It’s barely mentioned in most leadership development programmes. It’s assumed or it’s not thought about at all.

This article is about what facilitation actually looks like in a technical context, why it gets ignored, and how to build it deliberately.

What Facilitation Actually Means in a Technical Context

Facilitation is the deliberate act of guiding a group toward a decision or outcome. That sounds simple. In practice, it covers a set of distinct skills: managing the energy of a room, surfacing blockers before they derail progress, handling competing opinions without letting them become personal, and ensuring that by the time the meeting ends, something has actually been decided.

It’s worth being specific about what it is not. It’s not presenting. Presenting is one person sharing information with others. It’s not chairing a meeting. Chairing is largely procedural. It’s also not about being “good in rooms” in some vague, social sense that some people have and others don’t.

Facilitation is harder in technical settings than in most others, for a few reasons. Technical people tend to have strong opinions. Domain expertise often gets used as a proxy for authority. The person who knows the most speaks loudest, and speaking loudest isn’t the same as being right. There’s also a real fear of being wrong in front of peers, which makes people dig in on positions rather than explore alternatives.

If your work regularly involves rooms where multiple people with different opinions need to reach a shared decision, facilitation directly affects how effective you are.

Why It Gets Ignored

Technical skills are visible and measurable. You can test them, certify them, demonstrate them in a pull request or a system design interview. Facilitation skills are none of those things, which makes them easy to deprioritise.

Most tech professionals are also rewarded through performance reviews, promotions, and peer recognition for being right. Being the person with the correct technical answer is celebrated. Over time, this shapes how people show up in meetings: optimising for correctness rather than for helping the group move forward.

The result is a gap that almost never gets named directly. The distance between senior and staff or principal level at most big tech companies is almost always, at its root, a facilitation gap. The promotion feedback says something like “needs to demonstrate broader influence” or “should drive decisions/outcomes across teams.” What it often means, underneath, is: this person is technically excellent but hasn’t yet learned how to move a room.

Degrees don’t teach it. Onboarding doesn’t teach it. Most tech training programmes skip it entirely.

And in 2026, this matters more than it ever has. As AI handles more of the technical execution, the humans who remain genuinely difficult to replace are the ones who can orchestrate the human decisions that AI can’t. Facilitation is precisely that skill.

What Great Facilitation Looks Like in Practice

Here are the specific things I’ve seen great facilitators do, that most people in tech don’t do consistently.

Set up before you walk in. Know who’s in the room before the meeting starts. Understand their stakes, their concerns, and what outcome they need. The facilitator who walks in cold is already behind. A five-minute pre-read of who you’re meeting with and what they care about changes how you open, how you frame questions, and how you manage the room.

Read the room in real time. There’s a meaningful difference between a discussion that’s generating momentum and one that’s going in circles. The second kind has a signature: the same points get made repeatedly, people start talking over each other, and energy drops. Recognising this early and intervening before it becomes entrenched is a core facilitation skill.

Use the parking lot. When a tangent comes up that’s genuinely worth discussing but isn’t the point of this meeting, name it and park it explicitly. “That’s an important point let’s add it to the parking lot and come back to it after we’ve resolved the main question.” This keeps momentum without dismissing valid concerns.

Learn to whiteboard. This is one of the most underused facilitation tools in technical settings. Drawing a rough diagram on a whiteboard or shared screen in real time does something that slides cannot: it makes the group’s thinking visible to everyone at the same time. When you draw a system, a flow, or a decision tree live, the conversation shifts. People correct the drawing rather than talking past each other. It becomes a shared object that the room can react to, build on, or push back against together. You don’t need to be a great artist. You need to be willing to draw something rough and use it as a thinking tool.

Name the decision out loud before you leave. This is the one I see skipped most often. A meeting ends, everyone goes back to their desks, and three people walk away with three different understandings of what was decided. The fix is simple: before the meeting closes, say out loud what you’ve agreed. “So what we’ve decided is X. The next steps are Y and Z, owned by these people.” Explicit is better than assumed every time.

Change the question when the room is stuck. When a discussion stops making progress, pushing harder on the same question rarely helps. What does help is reframing what’s being asked. If the group can’t agree on which technical approach to take, sometimes the unlock is asking “what outcome are we actually trying to achieve?” and working backward. The right question at the right moment is the most powerful facilitation tool there is.

How to Build It Deliberately

Facilitation is a learnable skill. It’s not a personality type. It’s a set of behaviours that can be practiced and improved with intention.

Take the facilitation role, not just the participant role. Volunteer to run internal sessions: design reviews, post-mortems, sprint retrospectives, team stand-ups. Most people attend these meetings. Facilitating them is a different experience entirely, and the gap between the two is where the learning happens.

Watch before you practice. Identify the people in your organisation who consistently move rooms forward. Observe specifically what they do: when they speak, when they hold back, how they handle interruptions, how they close. Then try it yourself in lower-stakes settings before you attempt it in high-stakes ones.

Learn to whiteboard. If you’re not already comfortable drawing architecture and flow diagrams live, start practicing. Do it in internal meetings first. The goal should be to get comfortable in externalising thinking in real time and using that visual as a shared anchor for the conversation.

Ask for feedback explicitly. After customer meetings or stakeholder sessions, ask: “Was that useful? Did we get to a decision?” Most people skip this because feedback is uncomfortable. It’s also the fastest path to improving. The facilitators who get consistently better are almost always the ones who actively seek to know where they fell short.

Practise in low-stakes settings first. Internal team meetings, brown bags, internal workshops are your training ground. Get comfortable moving a room of colleagues before you try it with a customer CTO or a steering committee.

The Career Payoff

The pattern I’ve observed is consistent across companies and career levels: the technical professionals who advance to senior, staff, and principal roles are the ones who combine deep technical credibility with the ability to move rooms. One without the other stalls. Both together is rare and is why those roles are hard to fill.

Facilitation is also what makes the difference between a technologist who delivers technically and one who makes customers and stakeholders feel they can move fast. The latter is genuinely difficult to find, genuinely difficult to replace, and compensated accordingly.

In an era where AI is increasingly handling the execution layer of technical work, the humans who earn and keep their seat at the table are the ones who can do what AI cannot: read the room, surface what’s unsaid, and help a group of people make a decision they’ll actually commit to.

Want to Build This Skill Alongside a Community?

BeSA Batch 10 starts 22 August and the entire behavioral track is built around Facilitation skills

Six sessions. Six Saturday mornings. Completely FREE.

Here’s the full behavioral track agenda:

Sessions run live every Saturday and are streamed on the BeSA YouTube channel. The recordings go up after each session if you miss a week.

👉 Register here: https://besa.techexpert.io/program/self-paced-become-a-solutions-architect-agentic-ai-on-aws-3849

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• Everything You Need to Know About BeSA Batch 10

• The AI Job Market Has Split in Two. Here’s Which Side You Want to Be On.

• How to Transition from a Developer or Architect to AI FDE Roles

When you’re ready, here’s how I can help:

• 1:1 long-term career coaching to fast-track your career growth at Big Tech

• Behavioral Interview preparation course for MAANG+ companies

• Mock interviews for your upcoming interviews

For more details, send an email to info@bigtechcareers.com

In this week’s article, I break down the Dice July 2026 Tech Jobs Report — 7 million job postings analysed — and pull out the signals that actually matter for your career decisions right now.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

Every month when the tech hiring numbers drop, most people read the headline figure and move on. The aggregate is useful as a mood indicator. It’s not useful for making career decisions.

The question that actually matters isn’t “is tech hiring recovering?” It’s: which parts are recovering, in which industries, for which skills? Because the answer to that question tells you where to point your next move and the answer in June 2026 is more interesting than the headline suggests.

Dice’s July 2026 Tech Jobs Report analysed over 7 million US tech job postings and published this month. Here’s what stood out.

The Headline: Recovery Is Real, and It’s Accelerating

Tech job postings grew 3% month-over-month in June — consistent with the sustained expansion that has held for most of 2026.

Year-over-year, postings are up 27% compared to June 2025.

Dice’s framing is deliberate: the market has moved from recovery into a period of steady growth. That’s a meaningful shift in language from where we were twelve months ago.

AI skill requirements reached 75% of US tech job postings in June, up from 73% in May — and up 178% year-over-year from June 2025.

The report’s conclusion: AI fluency now sits at the centre of most tech hiring, not at its margins.

That last point is worth pausing on. Three years ago, listing AI skills on your resume was a differentiator. Today, not listing them is a gap. The bar moved faster than most people adjusted.

Where the Industry Growth Is

This is where the headline number starts to break apart into something more useful.

Manufacturing posted the largest month-over-month industry gain in June, with tech job postings up 35%. Technology came in at +19%, Consulting at +7%, Software at +5%.

Manufacturing is growing faster than Technology. The report’s explanation is straightforward - manufacturers are moving past early AI pilots toward production-scale automation, and they need the technical talent to do it.

Year-over-year, the picture is even more striking. Manufacturing, Consulting, and Healthcare each grew more than 50%, consistent with industries that spent 2025 building out AI-integrated operations rather than experimenting with them.

Think about what that means for your job search. The industries most tech professionals instinctively target pure tech companies and software firms. They are growing but they’re not where the momentum is heaviest right now. Manufacturing, Healthcare, and Consulting are the growth stories of mid-2026, and they’re competing for the same supply of technical talent.

If you’ve been sending all your applications to software companies and wondering why the response rate feels low, this data is part of the explanation.

Where the Skill Growth Is

This is the finding I found most surprising and most directly actionable.

The fastest-growing skills month-over-month in June were Electronic Engineering (69%), API System Integration (58%), LDAP (55%), Digital Forensics (54%), Data Exchange (53%), Enterprise Integration (50%), Threat Detection (48%), NIST Cybersecurity Framework (47%), and SAML (45%).

Two clear threads run through that list.

The first is integration: API System Integration, Data Exchange, and Enterprise Integration are all in the top six. These skills reflect the work of connecting AI systems to enterprise data and workflows — widely cited as the primary bottleneck between AI pilots and production deployment.

The second is identity and governance: LDAP, SAML, NIST CSF, and Threat Detection. This reflects a security posture that treats AI agents as identities needing authentication and monitoring alongside traditional users. As agentic systems start acting autonomously inside enterprise environments, the question of “which agent is doing what, with whose credentials, and how do we audit it?” becomes urgent.

Now look at the year-over-year numbers, and the signal gets louder.

Skills growing 250% or more year-over-year include: Enterprise Integration (638%), Agentic AI (587%), AI Agents (503%), Responsible AI (495%), AI Infrastructure (366%), Vector Database (353%), Event-Driven Programming (310%), RAG (275%), Prompt Engineering (253%), and Observability (251%).

Enterprise Integration is growing at 638% year-over-year. Agentic AI, the most-discussed topic in our industry, is growing at 587%. Enterprise Integration is outpacing Agentic AI itself.

The report’s interpretation is explicit: connecting agentic systems to existing infrastructure is growing faster than the agentic systems themselves. The bottleneck isn’t building agents. It’s getting them to reliably talk to real enterprise systems like CRMs, ERPs, legacy databases, internal APIs.

If you’re deciding which technical skill to double down on right now, this data is pointing clearly in one direction.

The Job Titles Surging Right Now

Job titles posting month-over-month growth above 150% in June cluster into three groups:

Enterprise systems and consulting: Appian Developers, Oracle Cloud Financials Consultants, ServiceNow Managers, Principal Consultants, Technology Consultants.

Core engineering and infrastructure: IT Software Engineers, C++ Software Developers, Configuration Analysts, Support Engineers, Network Infrastructure Engineers.

AI and security: Artificial Intelligence Analysts, Cyber Threat Intelligence Analysts.

What This Means for Your Career Right Now

Three practical takeaways:

1. Widen your industry targeting. If your job search is focused on pure tech companies, you’re competing in a smaller pool than you need to be. Manufacturing, Healthcare, and Consulting are growing at 50%+ year-over-year and are actively looking for the same skills you have. Most of your competitors aren’t applying there. The job market is less efficient in these sectors, which works in your favour.

2. Reframe your integration experience. If you’ve worked on connecting systems like APIs, data pipelines, legacy modernisation, cloud migration, identity management etc, that experience is now directly in demand. It wasn’t always framed as a career strength. Frame it that way now, explicitly, in AI-adjacent language. “API System Integration” and “Enterprise Integration” are the specific terms showing up in job postings.

3. Think seriously about the integration + governance combination. The skills clusters in this data aren’t independent. The companies building production agentic systems need people who understand both integration architecture and identity and access management. Engineers who can speak credibly to both — how to connect an agent to an enterprise system, and how to ensure it’s doing so securely and auditably — are describing a skillset that is genuinely hard to find right now.

The Bottom Line

The 27% year-over-year growth is real. But the more useful number for your career is 638% which is the year-over-year growth in Enterprise Integration. The market is telling you clearly what it needs most right now: not more people who can build AI demos, but people who can connect those AI systems to the real infrastructure enterprises run on.

That gap between what’s been built and what’s been integrated is where the demand is. It’s also, not coincidentally, where most of the interesting problems are.

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• The AI Job Market Has Split in Two. Here’s Which Side You Want to Be On.

• How to Transition from a Developer or Architect to AI FDE Roles

• The Quiet Signs Your Company Is About to Do Layoffs — And What to Do Right Now

When you’re ready, here’s how I can help:

• 1:1 long-term career coaching to fast-track your career growth at Big Tech

• Behavioral Interview preparation course for MAANG+ companies

• Mock interviews for your upcoming interviews

For more details, send an email to info@bigtechcareers.com

In this week’s article, I share everything you need to know about the upcoming BeSA Cohort 10 — what we’re covering, when it starts, and how to register.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

BeSA (Become a Solutions Architect) is back for its tenth cohort — and if you’ve been following this newsletter for a while, you’ll know how much this program means to me.

For those of you who are new here: BeSA is a free, six-week mentoring program that Ashish Prajapati, I and few other volunteers co-founded in 2022. It’s run entirely by volunteers — AWS professionals who give up their free time to mentor people who want to grow into cloud and AI careers.

In four years, we’ve trained 23,000+ learners across nine cohorts. Cohort 9 alone had 10,895 registrations, 98,500+ YouTube views, 6,136 workshops completed, and 40+ community volunteers who showed up every weekend to help participants through the hands-on labs.

If you want the full story of how BeSA started — from a LinkedIn post in 2020 to a global mentoring program — I wrote about it here.

Cohort 10 starts 22 August. Here’s everything you need to know.

What’s Different About Cohort 10

Cohort 9 covered Agentic AI on AWS at a conceptual and foundational level. Participants loved it — the feedback was overwhelmingly positive, and several told us it was the first time they truly understood how to build agentic systems, not just what they were.

Cohort 10 goes further. The theme is Agentic AI: from POC to Production on AWS.

That framing is deliberate. Everyone’s running pilots now. The real gap is what happens after — how you take an agentic system and make it production-ready, secure, observable, and governable. That’s what this cohort addresses.

The behavioural track has also been sharpened: Leading Customer Discussions as a Solutions Architect. In a market where every senior SA is being asked to advise on AI strategy, the ability to facilitate a room full of competing technical opinions and help a customer make a decision — not just present slides — is the skill that separates good SAs from great ones.

And for hands-on experience, participants in Cohort 10 get access to AWS Workshops every week — real environments to build in, not just theory.

Full Agenda

Here’s what each session covers:

Session 1 — 22 August

• Technical: Anatomy of an AI Agent

• Behavioural: Keynote on Agentic AI

Session 2 — 29 August

• Technical: Building Agentic AI with AWS Serverless

• Behavioural: Why Facilitation is the SA Superpower

Session 3 — 5 September

• Technical: Building AI Agents on Amazon EKS

• Behavioural: Designing Workshops that Drive Outcomes

Session 4 — 12 September

• Technical: Design Authentication, Authorization, and Logging

• Behavioural: Facilitating Technical Decisions in the Room

Session 5 — 19 September

• Technical: Agentic AI Evaluation and Observability

• Behavioural: Visual Facilitation & Real-Time Architecture

Session 6 — 26 September

• Technical: AI Governance on AWS

• Behavioural: From Workshop to Action

Who Should Join

BeSA has never been just a beginners’ program. Previous cohorts have included people brand new to cloud alongside experienced engineers and architects who wanted to go deeper on a specific topic or sharpen their customer-facing skills.

Batch 10 is a good fit if you are:

• A developer or engineer looking to transition into Solutions Architecture

• A cloud professional who wants to go deeper on agentic AI and production systems on AWS

• An SA — whether early-career or experienced — who wants to get better at facilitating technical decisions and customer conversations

• Anyone who wants to speak more credibly about AI strategy with customers or leadership

If you’re right at the start of your cloud journey, I’d recommend working through the BeSA AWS Foundations platform first — built entirely by BeSA alumni, completely free. It’ll give you the grounding to get the most out of the live sessions.

How to Join

Here are the details:

• Start date: Saturday, 22 August

• Duration: 6 weeks (22 Aug – 26 Sep)

• Format: 120-minute live sessions every Saturday

• Timing: 2 PM GMT - 4 PM GMT

• Cost: Completely FREE

👉 Register here — https://besa.techexpert.io/program/self-paced-become-a-solutions-architect-agentic-ai-on-aws-3849

👉 Livestream — https://www.youtube.com/@be-SA/streams

Sessions are live-streamed on YouTube every Saturday. All recordings are posted on the BeSA YouTube channel after each session, so if you miss a week you can catch up — but we do ask you to commit to attending live as much as possible. The curriculum is progressive and the live interaction is a big part of what makes it work.

BeSA Cohort 10 Launch Video

Ashish and I recorded the launch video for BeSA Cohort 10 - watch it here!

A Note on Volunteers

BeSA runs because a group of people choose to give their time — on top of full-time jobs, on their weekends — because they believe in what this community is doing.

Batch 9 ended with 40+ community volunteers supporting 1,000+ participants every weekend through AWS Workshop Studio. Many of them were BeSA participants themselves in earlier cohorts, who came back to help the next wave of learners. That’s the compound effect of a community that genuinely cares.

If you’ve ever benefited from BeSA — as a participant, through the YouTube recordings, through the AWS Foundations platform — the right way to give back is to show up, engage, and eventually put your hand up to volunteer for a future cohort. That’s how this keeps growing.

BeSA Core Team

Parna Mehta · Ashish Prajapati · Prasad Rao

Follow us on LinkedIn to regular updates!

Please spread the word to friends, colleagues, and anyone in your network who’s working toward a cloud or AI career. The more the community grows, the more people we can help.

If you have any questions before registering, connect with any of us on LinkedIn.

See you on 22 August. 🚀

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• How BeSA Started and What’s Next

• Trip Report | BeSA Q1 2026 Agentic AI on AWS Cohort

• How to Transition from a Developer or Architect to AI FDE Roles

In this week’s article, I cover the 6 certification pathways for hottest skill combo (AWS + Claude) mapped by role.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

AWS + Claude is turning into one of the fastest-growing skill combinations in cloud right now.

I covered the 4 new Claude certifications in my last edition, breaking down the exam domains and formats. This time I want to go one layer deeper: how to pair each Claude certification with the right AWS certification, so you end up with a combination that actually signals something to a hiring manager, rather than two unrelated badges on a LinkedIn profile.

As a reminder, here’s the full Claude lineup:

• Claude Certified Associate – Foundations

• Claude Certified Developer – Foundations

• Claude Certified Architect – Foundations

• Claude Certified Architect – Professional

There’s something here for pretty much every role touching cloud and AI: sales, marketing, PM, engineering, solutions architecture, ML, and DevOps. The trick is not collecting all four. It’s pairing the one that matches your role with the AWS certification that already validates the cloud fundamentals underneath it.

The 6 pathways

1. Sales, marketing, PM - AWS Certified Cloud Practitioner + Claude Certified Associate – Foundations

This is the lightest pairing and it’s intentional. Cloud Practitioner gives you enough AWS fluency to speak the same language as engineering, and Associate – Foundations validates that you can apply Claude to real business workflows without needing to write code. If your job is closer to positioning, scoping, or running a project than building the system itself, this is your lane.

2. Software engineers, developers - AWS Certified Developer – Associate + Claude Certified Developer – Foundations

This is the builder pairing. AWS Developer – Associate proves you can work with core AWS services in code, and Claude Developer – Foundations proves you can do the same with the Claude API, Claude Code, and MCP. Together they cover the two things most engineering teams actually need right now: someone who can ship on AWS infrastructure and integrate Claude into the application layer.

3. Solutions Architect AWS Certified Solutions Architect – Associate + Claude Certified Architect – Foundations

This is the pairing I hold. AWS SA – Associate is still the anchor credential for architecture roles, and Architect – Foundations layers on the Claude-specific piece: agentic architecture, tool and MCP design, Claude Code workflows, and reliability patterns. If you’re the person designing how a system is put together rather than just building one piece of it, this is your combination.

4. Senior/Principal Solutions Architect - AWS Certified Solutions Architect – Professional + Claude Certified Architect – Professional

The step up. AWS SA – Professional already assumes you’re operating at enterprise scale, across multi-account environments, cost optimization, and complex migrations. Architect – Professional mirrors that at the Claude layer, covering RAG pipeline design, multi-agent orchestration, governance, and stakeholder communication. This is the pairing for architects who own the full lifecycle of a solution, not just a component of it.

5. Machine Learning / AI Engineer - AWS Certified Machine Learning Engineer – Associate + Claude Certified Developer – Foundations

A slightly less obvious pairing, but it makes sense once you think about what ML engineers actually do day to day. The AWS ML Engineer cert covers the traditional ML pipeline (data, training, deployment), while Claude Developer – Foundations covers the generative AI application layer: agents, tool use, and integration. Most ML engineers today are being asked to do both, so this pairing covers the full stack rather than doubling up on architecture.

6. DevOps Engineer AWS Certified CloudOps Engineer – Associate + Claude Certified Architect – Foundations

This one surprises people until you look at what’s actually in the Architect – Foundations exam. A meaningful chunk of it is Claude Code configuration and workflows: CI/CD integration, batch processing, hooks, and automation patterns. That overlaps directly with what a DevOps or CloudOps engineer already owns, which makes Architect – Foundations a better fit here than Developer – Foundations.

Why pair them at all

A Claude certification on its own tells an employer you understand one vendor’s product. An AWS certification on its own tells them you understand cloud infrastructure. Paired together, they tell a more specific and more valuable story: that you can take a Claude-powered application and actually run it in a real AWS environment, with the security, cost, and operational considerations that come with that.

That combination is still rare. Most people are certified in one or the other, not both. Early in a credential market, being one of the few people who can show both sides of that story tends to carry more weight than it will once everyone catches up.

One important caveat

These Claude certifications are currently only available to Anthropic partners, so access depends on your organization’s partner status rather than being open to everyone individually right now. If you’re not sure whether your company qualifies, that’s worth checking before you plan a study timeline around it.

Which pairing matches where you sit today?

If you’re an enterprise or a company looking to get your employees enabled on Claude, I run a custom corporate training program called Enterprise AI Solutions Architecture with Claude, built for teams who want to move past experimentation and actually deploy Claude in production, AWS and all. Reply to this email or reach out at info@bigtechcareers.com and we can talk through what that could look like for your team.

If this was useful, consider giving it a repost so it reaches someone else mapping out their next certification.

Related links:

• 3 New Claude Certifications, Broken Down (link to your previous edition)

• How I Passed the Claude Architect Certification

• Claude Partner Certifications: anthropic-partners.skilljar.com/page/partner-certifications

Want to go deeper on your career, your certifications, or your positioning? I offer 1:1 coaching sessions and multi-session packages built around getting you ROI that outweighs the cost. Reach out at info@bigtechcareers.com.

In this week’s article, I cover the new Claude certification announcements. Anthropic just went from one Claude certification to four.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

If you’ve been building a career around Claude, AWS, or the wider AI ecosystem, this is a moment worth paying attention to. A single certification turning into a full certification track is a strong signal that Anthropic is serious about building a professional ecosystem around Claude, the same way AWS, Google Cloud, and Azure did with their own cloud certifications.

I passed the original certification, Claude Certified Architect – Foundations (CCA-F), back before this expansion. If you want the full story on how I prepared and what the exam covered, I wrote about it here: How I Passed the Claude Architect Certification.

Today I want to walk through what’s new, why it matters, and which certification actually fits your role.

From one certification to a full track

Until now, there was exactly one Claude certification available: CCA-F. It launched as Anthropic’s first official credential, built for solution architects designing and shipping production Claude applications.

Anthropic has now expanded that into four certifications spanning three roles: Associate, Developer, and Architect.

Architect has two levels, Foundations and Professional, so it becomes a proper ladder rather than a single checkpoint.

Here’s the full lineup:

The new exams open on July 13th.

The 3 new certifications, broken down

I pulled the actual exam guides for all three new certifications, so here’s the real detail on format, domains, and who each one is built for, not just the marketing copy.

1. Claude Certified Associate – Foundations ($99, exam code CCAO-F)

This one is aimed at people who advise rather than build. It validates that someone can apply Claude to business and productivity tasks with minimal guidance, using built-in platform features to streamline workflows, and knowing when to escalate technical work to a Developer or Architect. Anthropic is explicit that this is not for software developers or people building agentic systems. It’s built for operations, marketing, project management, education, and communications roles, plus consultants who support implementation and use-case identification.

Format: 60 questions, 120 minutes, passing score of 720 out of 1,000. No mandatory prerequisites.

The exam blueprint breaks down into seven domains:

• Output Evaluation and Validation (21%) — the single biggest domain. Catching hallucinations, fact-checking, and knowing when human review is required

• Workflow Integration and Solution Design (16%)

• Governance, Risk, and Responsible Use (15%) — data sensitivity, organizational AI policy, ethical use

• Prompting and Task Execution (14%)

• Product and Model Selection (12%) — knowing when to reach for Haiku vs. Sonnet vs. Opus

• Configuration and Knowledge Management (12%) — Projects, connectors, system instructions

• Troubleshooting and Optimization (10%)

2. Claude Certified Developer – Foundations ($125, exam code CCDV-F)

This is the hands-on builder certification. It validates that someone can build, integrate, and ship production-grade applications, agents, and workflows using Claude at a foundational level. Anthropic recommends one to five years of software engineering experience and at least six months hands-on with Claude or a comparable LLM system, plus proficiency in Python and/or TypeScript.

Format: 53 questions, 120 minutes, passing score of 720 out of 1,000.

Eight domains, and the weighting tells you exactly where Anthropic thinks the real skill gap is:

• Applications and Integration (33.1%) — by far the largest domain, covering Claude API mechanics, software engineering foundations, application design across interfaces, and configuration management

• Model Selection and Optimization (16.8%) — LLM fundamentals, cost and token management, caching

• Agents and Workflows (14.7%) — agent architecture, construction with the Claude Agent SDK, agentic frameworks like LangGraph and PydanticAI

• Prompt and Context Engineering (11.0%)

• Tools and MCPs (10.6%) — building custom tools, MCP servers, weighing built-in tools vs. custom tools vs. Skills vs. MCPs

• Security and Safety (8.1%) — prompt injection defense, guardrails, hooks, secrets management

• Claude Code (3.1%)

• Eval, Testing, and Debugging (2.6%)

3. Claude Certified Architect – Foundations ($125, exam code CCAR-F) — the one I hold

This is where I started. It validates that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude. The exam tests foundational knowledge across Claude Code, the Claude Agent SDK, the Claude API, and MCP, the core technologies behind production-grade Claude applications. Anthropic recommends 6+ months of hands-on experience building with these tools.

Format: 60 questions, 120 minutes, closed-book and proctored. You’re presented with 4 of 6 possible scenario contexts, randomly selected, and answer scenario-based questions grounded in each one. It’s not a trivia exam. You’re making architectural decisions about multi-agent systems, debugging tool selection issues, and deciding when a support agent should escalate to a human versus handle something autonomously.

Five domains:

• Agentic Architecture & Orchestration (27%) — the single largest domain. Agentic loops, multi-agent coordinator-subagent patterns, session state management, task decomposition, hub-and-spoke orchestration

• Claude Code Configuration & Workflows (20%) — CLAUDE.md hierarchy, custom commands and skills, plan mode, CI/CD integration, batch processing

• Prompt Engineering & Structured Output (20%)

• Tool Design & MCP Integration (18%) — tool description best practices, structured error responses, MCP server configuration, built-in vs. custom tools

• Context Management & Reliability (15%)

I wrote up my full prep process and what the exam actually felt like here: How I Passed the Claude Architect Certification.

4. Claude Certified Architect – Professional ($175, exam code CCAR-P)

This is the one I’m most curious about, since it sits directly above CCA-F, the certification I hold. It’s aimed at mid- to senior-level solution architects, AI/ML engineers, and technical leads who own the full lifecycle of a Claude-powered system, including stakeholder engagement and executive-level architectural decisions. Anthropic recommends 3+ years in systems architecture or platform engineering and 6+ months of hands-on production experience with Claude.

Format: 63 questions, 120 minutes, passing score of 720 out of 1,000. This is the longest exam of the four.

Seven domains:

• Integration (19%) — RAG pipeline design, chunking and indexing strategy, MCP vs. API/CLI vs. agent-to-agent protocol selection, authentication and authorization gaps

• Solution Design & Architecture (17%) — translating business problems into architectures, multi-agent orchestration, choosing workflow vs. agentic vs. augmented-LLM patterns

• Evaluation, Testing & Optimization (16%) — eval datasets, A/B testing, diagnosing hallucinations and model mismatch

• Governance, Safety & Risk Management (14%) — guardrails, human-in-the-loop validation, GDPR/HIPAA/FedRAMP compliance

• Stakeholder Communication & Lifecycle Management (14%) — discovery, documentation, SLA management

• Claude Models, Prompting & Context Engineering (13%)

• Developer Productivity & Operational Enablement (7%)

One detail worth flagging across all four exams: retakes follow an escalating waiting period, 14 days after a first fail, 30 days after a second, 90 days after a third, capped at four attempts in a rolling 12 months. The credential itself is valid for 12 months, with a free non-proctored renewal assessment if you recertify on time.

Why this matters for your career

Anthropic building out Foundations-to-Professional tiers mirrors exactly what AWS did with its own certification maturity. A single cert, then a broadening into role-based paths, then advanced tiers layered on top. If that pattern holds, expect specialty certifications next.

The practical takeaway is that you don’t need all four. You need the one that matches where you actually sit today.

• If you’re advising customers and shaping deals, Associate is your lane.

• If you’re building integrations and agents day to day, Developer is your lane.

• If you’re designing the end-to-end solution, Architect is your lane, and Professional is where you head once you’ve got Foundations under your belt.

What carries over from my CCAR-F experience

I passed CCA-F through Anthropic’s own Skilljar-hosted courses rather than third-party prep material, and I’d recommend the same approach here. The course library covers the Claude API, MCP, Claude Code configuration, and agentic patterns, and a good chunk of that foundation will carry across all four exams, not just Architect.

Here is the preparation roadmap I created

If you’re deciding where to start, my full writeup on preparing for CCA-F is still the best reference I can point you to: How I Passed the Claude Architect Certification.

Should you get one?

Don’t chase all four. Pick the certification that matches your actual role today, and treat the next tier as where you’re heading rather than something to rush into immediately.

The AI certification market is still early. Getting certified now, while the credential pool is small, tends to carry more weight than getting certified once everyone else has caught up.

Please note that this certification only available for Anthropic Partners at this point. See more details at Anthropic Partner Academy

Looking to get your team Claude Certified?

If you’re an enterprise or a company looking to get your employees enabled on Claude, I run a custom corporate training program called Enterprise AI Solutions Architecture with Claude, built for teams who want to move past experimentation and build production ready Agentic AI solutions with Claude. It includes getting Claude certifications.

Reply to this email or reach out at info@bigtechcareers.com and we can talk through what that could look like for your team. Every engagement is tailored to align with your organisation’s AI strategy, technical maturity and business objectives.

Want to go deeper on your career, your certifications, or your positioning? I offer 1:1 coaching sessions and multi-session packages built around getting you ROI that outweighs the cost. Reach out at info@bigtechcareers.com.

In this week’s article, I trace how the acronym that defines “Big Tech” has quietly rewritten itself over the years — and what the latest version tells us about where careers, capital, and power are actually moving.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

If you grew up dreaming of working at a “FAANG company,” I have some news: that acronym is now older than some of the products built by the companies that replaced it.

In the space of about five years, the shorthand for “the companies that define tech” has gone from FAANG, to MAMAA, to MANGO, to MANGOS — and now there’s chatter of an even bigger version floating around social media. Each rewrite is a reasonably accurate live read of where capital, talent, and power are actually rotating in the industry. So this week, I want to walk through the full lineage — where each acronym came from, why companies got added or dropped, and where this is realistically headed.

Where It All Started: FAANG (2013)

The term was coined by CNBC Mad Money host Jim Cramer in 2013, originally as the four-letter FANG — Facebook, Amazon, Netflix, Google. Infact, market technician Bob Lang is credited with originating the acronym, which Cramer then popularized to a mass television audience.

Apple wasn’t part of the original group. It was added in 2017 as its market dominance became impossible to ignore, completing the five-letter FAANG we all grew up knowing. Cramer’s framing at the time was simple: these were companies that were, in his words, completely dominant in their respective markets.

What united the original FAANG five was a business model. Social media, e-commerce, streaming, search. Companies that won by capturing and monetizing human attention.

The First Rewrite: MAMAA (2021)

The first real signal that FAANG had an expiry date came in October 2021, when Facebook rebranded to Meta. Cramer retired FAANG that same week and introduced MAMAA — Meta, Apple, Microsoft, Amazon, Alphabet — dropping Netflix entirely and adding Microsoft, which had just overtaken Apple as the world’s most valuable company.

MAMAA never fully entered the cultural lexicon the way FAANG did — but it mattered for one reason: it proved the acronym wasn’t sacred. If the underlying companies changed enough, even the term’s own inventor was willing to scrap it and start over.

The Real Shift: MANGO and MANGOS (2025–2026)

This is where it gets interesting and where the story has moved fast enough that most career content hasn’t caught up yet.

The early, quieter version (2025). Before this went viral, the acronym was already circulating in analyst circles. BofA analyst Vivek Arya originally coined a similar acronym for a basket of semiconductor companies, and analyst Stirling Larkin repurposed the letters in 2025 to describe an AI-era grouping of Microsoft, Anthropic, Nvidia, Google, and OpenAI. It got some pickup — Axios covered it in October 2025, and venture investors discussed it on CNBC — but it stayed mostly within finance and VC circles.

The viral moment (June 2026). That changed fast. Software engineer Krishna B. posted a graphic on X on June 8, 2026, declaring “It’s not FAANG anymore. It’s MANGO” — built around Meta, Anthropic, Nvidia, Google, and OpenAI. The post didn’t just get noticed — it crossed 20,000 likes within 24 hours and was picked up by mainstream financial media almost immediately.

Why this exact moment. Timing is everything here. Both OpenAI and Anthropic filed confidential S-1 paperwork with the SEC, targeting public listings within the year — and that filing news is widely credited with turbocharging how fast the acronym spread. SpaceX was moving in parallel — its own IPO, one of the largest in history, began trading the same week the acronym went viral, which is what pushed people to extend MANGO into the six-letter MANGOS by adding SpaceX.

The logic behind the list. This isn’t a random collection of hot stocks. Nearly every MANGOS company is building infrastructure that other businesses pay to run on — Nvidia supplies the chips, Google and Meta build AI systems enterprises embed in their own products, OpenAI and Anthropic sell API access developers build on top of, and SpaceX’s Starlink provides connectivity infrastructure for industries broadband can’t reach. Combined, the group represents roughly $14 trillion in public market value and private valuations.

Why Amazon and Netflix got cut. This is the part that should sting if you’re targeting a “FAANG career.” Both companies “remain powerful,” but e-commerce and streaming look less groundbreaking than AI right now — and more importantly, neither Amazon nor Netflix owns a frontier AI model, which the report calls disqualifying in a list built specifically around control of the AI stack.

And Now: “MANGO MAX”

I’ve seen variations of an eight-company extension circulating on social media — sometimes labeled “MANGO MAX” — that builds on MANGO by folding in Microsoft, Amazon, and xAI/SpaceX:

Microsoft, Anthropic, Nvidia, Google, OpenAI, Meta, Amazon, and xAI/SpaceX.

Take the label itself with a grain of salt — it hasn’t been picked up by major outlets the way MANGOS has. But the logic behind each addition is grounded in real, verifiable developments, which is probably why this extended version is circulating.

Interestingly, the appetite for a bigger basket isn’t just social media chatter. Asset managers Yorkville America and Corgi Securities have already filed with the SEC to launch competing MANGOS-tracking ETFs — Yorkville’s version, called “Mango Plus,” explicitly extends the core six stocks with seven additional companies it calls the “Parabolic 7”. Whatever you call the eight-or-more company version, Wall Street’s product pipeline suggests the idea of an extended list is being taken seriously — even if “MANGO MAX” specifically hasn’t been adopted as the official name yet.

What This Pattern Actually Tells You

Step back from the cute fruit-based branding for a second, and the pattern itself is the real insight.

FANG → FAANG → MAMAA → MANGO → MANGOS → (possibly) MANGO MAX isn’t just Wall Street having fun with acronyms. It’s a fast-forward replay of where capital and talent attention are rotating, updated almost in real time. Two things stand out:

1. The list now includes private companies for the first time. No previous Wall Street acronym — not FAANG, not MAMAA, not Magnificent Seven — included companies that weren’t publicly tradable. MANGOS broke that rule with Anthropic, OpenAI, and (until recently) SpaceX, all private at the time the acronym took off. That alone tells you how much investor and career attention has shifted toward companies before they’ve even reached the public market.

2. The selection criteria changed from “attention” to “AI infrastructure.” FAANG companies won by capturing consumer time. MANGOS companies win by being the layer other businesses build on top of — chips, models, cloud, connectivity. If you’re mapping your own career trajectory, that’s a meaningfully different skillset to be building toward.

The Bottom Line

Acronyms are sticky because they’re simple. But simple isn’t the same as settled. FAANG took eight years to fully retire. MANGO took about eight months to mutate into MANGOS. Whatever comes after MANGO MAX — and something will — the underlying signal is the one worth tracking: power in tech is consolidating around infrastructure, compute, and frontier AI models, not consumer apps.

If you’re building your career with “I want to work at a FAANG company” as the goal, it might be time to update the target. The companies worth aiming for in 2026 look meaningfully different from the ones that defined 2013 — and the acronym churn itself is one of the clearest signals telling you so.

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• How to Stand Out When 95,000 Tech Workers Are Job Hunting at the Same Time

• How to Transition from a Developer or Architect to AI FDE Roles

• The Quiet Signs Your Company Is About to Do Layoffs — And What to Do Right Now

Big Tech Interview Preparation Course

While I share everything for free here in this newsletter, if you are preparing for behavioral interviews, I have a self-paced course for you.

Check the course page for more details.

Enroll for Interview Preparation Course

A few months ago I shared my preparation roadmap for the Claude Certified Architect exam on LinkedIn, and it went semi-viral. This week, it’s my turn to close the loop — what I actually followed from my own roadmap, what I didn’t, the resources that got me there, and what you can expect on exam day.

If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.

The Roadmap I Originally Posted

Here’s the six-week roadmap I shared on LinkedIn a few months back:

The plan, in short:

• Week 1: Complete the recommended courses — Building with the Claude API, Introduction to Model Context Protocol, Claude Code in Action, Claude 101

• Week 2: Build real projects with Claude Code, Agent SDK, the Anthropic API, and MCP

• Week 3: Get familiar with the exam structure and guide — go through the 6 exam scenarios, get familiar with the 5 domains, learn the skills needed for each task statement

• Week 4: Do the preparation exercises from the exam guide — build a multi-tool agent with escalation logic, configure Claude Code for a team development workflow, build a structured data extraction pipeline, design and debug a multi-agent research pipeline

• Week 5: Take the practice exam, aiming for a score greater than 850/1000

• Week 6: Take the real exam — only one attempt allowed

That roadmap got a genuinely good response when I posted it. When I created the plan, I thought I’d follow it. I never actually got a six-week window to do that.

Instead, here’s what I did. I want to walk through what actually happened, because I think the gap between “the plan” and “the execution” is more useful to you than the plan alone.

What I Followed, What I Didn’t, and Why

Weeks came and went, but I was never able to get onto the six-week plan. I kept opening the roadmap, looking at Week 1, and closing my laptop because there were other higher-priority items that week. This is the part nobody puts in their LinkedIn post: the plan sat untouched for couple of months.

A two-week window opened up where my regular workload eased off. I went all in and compressed the entire six-week roadmap into those two weeks.

A few things made that compression possible for me specifically, and I want to be upfront about them rather than imply this is universally achievable:

• I already have a solution architecture background. I was mapping existing knowledge onto Claude-specific patterns, not building those patterns from scratch.

• I had two weeks of genuinely focused time. At least couple of hours daily for 2 weeks.

If you’re starting fresh — new to agentic architecture concepts, new to Claude’s tooling, or only able to carve out a few hours a week — the original six-week plan is a far more realistic target than my two-week compression. Calibrate to your own starting point and bandwidth.

The Resources I Actually Used

Here’s the real sequence, in order.

1. Five Skilljar Courses

Anthropic Academy has 15+ free courses on Skilljar, and you don’t need all of them. I completed five:

• Building with the Claude API

• Claude Code in Action

• Introduction to Model Context Protocol

• Introduction to Agent Skills

• Introduction to Sub Agents

These five cover the practical surface area tested across the 5 Domains (more on it shortly). I picked these based on which domains felt least familiar to me. I’d encourage you to do the same with your own gaps, instead of working through the full catalog.

2. Official Practice Test — First Attempt: 700

Once I’d worked through the courses, I sat the official practice exam cold, with no additional review. I scored 700. Given the real exam’s passing score is 720, that result told me exactly where the gaps were, without the pressure of a real attempt.

3. The Book — Read End to End

This is the resource I’d recommend even if you weren’t taking the exam at all: Architecting Agentic Solutions with Claude by Vladimir Provorov.

Provorov passed the CCA-F exam in its first week of availability, and this book grew directly out of his own preparation notes.

I’d recommend this book to anyone designing production LLM systems, certification or not. The architectural principles — how to think about tool design, escalation logic, context management, and reliability at scale — are the same principles you need whether or not you ever sit the exam. What makes it genuinely useful for the exam is the self-check questions with detailed answers after each of the 12 chapters.

4. Official Practice Test — Second Attempt: 950+

After finishing the book, I retook the official practice exam. This time I scored 950+. That gap from 700 to 950+ was almost entirely the book closing conceptual gaps the courses alone hadn’t covered. At that point, I knew I was ready.

5. Exam Morning: A Chapter-by-Chapter Scenario Refresher

On the morning of the exam, I didn’t start anything new. I went back through the book and revisited the self-check questions at the end of each chapter — on average about five per chapter. It was pure pattern reinforcement right before attempting the main exam.

6. The Exam: 881, Passed

I scored 881 on the real exam — comfortably above the 720 passing threshold, though notably lower than my second practice test score. That gap is worth mentioning honestly: the real exam scenarios carry more layered detail and ambiguity than practice questions typically do, even when your practice scores look strong.

Here is the breakdwn:

What You Can Expect From the Exam

Pulling directly from Anthropic’s official exam guide, here’s what the CCA-F exam actually looks like:

Target audience: solutions architects, technical leads, and developers within the Anthropic Partner Network. Anthropic recommends at least 6 months of hands-on, practical experience with Claude’s API, Agent SDK, Claude Code, and MCP before attempting it — this isn’t an entry-level credential.

Exam format: 60 questions, 120 minutes, closed-book, proctored — built to assess real-world systems design rather than theoretical knowledge. No AI assistance is permitted during the exam itself. It’s scored on a scaled range of 100–1,000, with a passing score of 720, and delivered online proctored through Anthropic’s Skilljar platform.

Key topics tested:

6 real-world scenarios (4 randomly chosen for your exam, 15 questions each)
across 5 domains:

→ Agentic Architecture & Orchestration
→ Claude Code Configuration & Workflow
→ Prompt Engineering & Structured Output
→ Tool Design & MCP Integration
→ Context Management & Reliability

Availability and Cost: Available only Anthropic Partners and free for the first 5,000 partner company employees during the early-access phase, and now available at $99 per attempt.

The scenario structure: the exam draws from a pool of 6 production scenarios — things like a customer support resolution agent, a multi-agent research system, and a code review CI/CD pipeline — with 4 of the 6 randomly selected for your particular sitting.

How the time and the questions actually felt: 60 questions in 120 minutes felt comfortable for me — I finished with 12 minutes to spare. I’d always thought AWS had mastered the art of “close enough” options, where passing often comes down to sharp elimination skills more than full certainty. Anthropic has quietly raised the bar here. Some questions made me pause, re-read, and genuinely think — closer to working through an actual production tradeoff than picking the best-worded answer on a multiple-choice test.

The Bottom Line

My roadmap said six weeks. My reality was a long stretch of procrastination followed by two weeks of focused execution — and that only worked because of a background and bandwidth that not everyone starting this exam will have. If you’re earlier in your Claude journey, the original six-week plan is the more honest target. My two-week number is one data point shaped by a specific starting line — calibrate to your own.

Have you started prepping for the CCA-F exam, or are you considering it? Feel free to ask questions in the comments!

Enjoyed this article? You might also like these popular posts from Big Tech Careers:

• How to Stand Out When 95,000 Tech Workers Are Job Hunting at the Same Time

• How to Transition from a Developer or Architect to AI FDE Roles

• The Quiet Signs Your Company Is About to Do Layoffs — And What to Do Right Now

Big Tech Interview Preparation Course

While I share everything for free here in this newsletter, if you are preparing for behavioral interviews, I have a self-paced course for you.

Check the course page for more details.

Enroll for Interview Preparation Course