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

In this week’s article, I share 5 soft skills that will help you become a super Individual Contributor (IC).

If you enjoy this article, click the ❤️ icon — it helps me know what content resonates with you.

Your technical skills get you in the room. Your soft skills determine what happens once you are there.

I have watched incredibly sharp professionals get passed over for promotions. I have seen people struggle to get their ideas adopted even when their ideas were clearly right. I have seen others spin their wheels on the wrong work, delivering good output that nobody asked for.

In almost every case, the gap was not technical ability. It was something else. It’s the soft skills that consistently separate good ICs from super ICs.

These are not the fluffy skills. These are real, learnable skills and directly tied to your impact and your career trajectory.

Let’s get into them.

1. Influence without authority

This is the defining skill of a great IC.

You cannot mandate anything. You do not have direct reports. You cannot order anyone to do what you think is right. Your only lever is your ability to make people want to move in your direction.

Most ICs try to win arguments through logic alone. And logic helps. But influence is built over time through a combination of track record, clarity of thinking, and knowing when to push hard versus when to plant a seed and let it grow.

The ICs who are genuinely influential tend to do a few things well. They frame problems in a way that makes others feel seen. They invest in understanding what motivates different stakeholders before they start advocating. They pick their battles carefully, which means when they do push, people listen.

If you are finding that your ideas get adopted less often than they should, this is the skill to look at first.

The question to ask yourself: When I last tried to move something forward and it stalled, was it a logic problem or an influence problem?

2. Ruthless prioritization

This one is invisible until it goes wrong.

Nobody tells you what to drop. At senior IC level, your calendar will always have more in it than you can execute well. The ability to choose what not to do is just as important as the ability to do things well.

I see a lot of ICs fall into a trap here. They are hardworking, they respond to every request, they say yes to everything because they want to be helpful. And then they spread themselves so thin that nothing they do is truly excellent.

Super ICs have a clear answer to the question “what is the most important thing I can do?” They protect that work fiercely. They are not rude about saying no, but they are clear.

Doing five things adequately will always be less impressive than doing two things memorably. Promotions and recognition go to people whose names are attached to outcomes, not to people who were involved in a lot of things.

The question to ask yourself: If I could only complete two things this quarter, which two would create the most impact? Am I actually spending my time on those?

3. Executive communication

Most ICs communicate the way they think, which is from context to conclusion.

They start with the background, explain the problem, walk through the options considered, and eventually land on the recommendation. This works well in a design document. It does not work well in a 15-minute meeting with a VP.

Executives think the opposite way. They want the conclusion first, and they will ask for context only if they need it.

Super ICs learn to flip their communication style. One sentence on what they are recommending. One sentence on why it matters. Then they stop and open the floor. Context is available on request.

This is not about being less thorough. It is about respecting that senior stakeholders are context-switching constantly and need to quickly understand where to focus their attention.

The practical shift is simple. Before any meeting or written update, ask yourself: if I had 60 seconds and nothing else, what is the one thing this person needs to hear?

Start there.

The question to ask yourself: Am I leading with the insight or leading with the journey?

4. Intellectual credibility

Intellectual credibility means people trust your judgment specifically because you consistently know more than they expected, ask the questions nobody else thought to ask, and connect dots across domains.

In a world where AI tools are accelerating the pace of change, this matters more than ever. Everyone can now produce a decent answer quickly. What distinguishes super ICs is that they are genuinely ahead of the room, not just broadly informed.

Intellectual credibility compounds. Once people know you are the signal in the noise, they bring their hardest problems to you. That access creates more opportunities to have impact, which builds more credibility.

How do you build it? Deep work. Staying close to the frontier of your domain. Being honest about what you do not know. And following through when you say you will come back with an answer.

The question to ask yourself: When someone in my organization has a hard problem in my area, am I the person they think of?

5. Navigating ambiguity

This is the one that most clearly separates good ICs from super ICs.

Most professionals are comfortable executing against clear requirements. They wait for clarity before they move. At senior levels, clarity often does not come. The situation is genuinely complex, the requirements are incomplete, and the stakeholders have conflicting views.

Super ICs do not wait. They impose structure on the ambiguity themselves.

This means writing the draft definition of the problem when nobody else has. It means calling out the assumptions being made and asking whether they are correct. It means moving the conversation forward even when the answer is not yet known.

This skill matters because ambiguity is expensive. Every week a problem sits undefined is a week of delayed progress. The IC who steps in and makes the ambiguity legible is creating real organizational value.

You do not need to have the answer. You need to be the person who makes the question clearer.

The question to ask yourself: When I encounter an ambiguous situation, is my instinct to clarify it or to wait for someone else to clarify it?

How these five skills compound

Here is the thing about these skills. They do not just add up. They multiply.

When you have intellectual credibility, your influence without authority becomes much more effective. When you communicate like an executive, your prioritization choices get more buy-in. When you navigate ambiguity well, you create the conditions for everyone else to be more effective.

Super ICs are not superhuman. They are just consistently good at these five things, and the compounding effect over time is significant.

The good news is that every one of these skills 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.

In this week’s article, I share the early warning signs that layoffs are coming and the steps you can take before the announcement lands.

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

A friend of mine at a large tech company told me something recently that stuck with me.

“Looking back,” he said, “the signs were everywhere. Three months before the announcement, I could see them clearly. But I convinced myself it wouldn’t happen to my team.”

It did happen to his team. And because he started searching only after the news broke, he was competing against hundreds of colleagues who received the same email on the same morning. It took him five months to land his next role and he took a lower base salary than he had before, just to end the uncertainty.

I think about that conversation a lot when I look at where we are right now.

As of June 11, 2026, there have been 247 layoff events this year impacting 183,966 workers — averaging 1,136 job losses per day. That’s double the daily rate of all of 2025. Microsoft, Oracle, Intel, Salesforce, Meta — the names keep coming. And the pattern isn’t random. It’s structural. AI efficiency gains are compressing headcount, and that pressure isn’t going away.

So this week I want to talk about how to read the room before the announcement comes. Not to scare you. Not to make you paranoid. But because the single most powerful thing you can do for your career right now is stop being reactive and start being proactive.

Why Most People Miss the Signs

Here’s the uncomfortable truth: we are wired to miss these signals.

When you’re inside a company, you see things that would be obvious to an outside observer but your brain has a vested interest in explaining them away. You’ve built your life around this job. Your identity, your income, your visa status, your team relationships. Of course you don’t want to believe it.

This is what psychologists call optimism bias, the tendency to believe that bad things are more likely to happen to others than to ourselves. It’s not stupidity. It’s human nature. But in the context of a tech career in 2026, it is expensive.

The other reason people miss the signs is simpler: they don’t know what to look for. So let me tell you.

The Quiet Signs to Watch For

These are ordered roughly from earliest to latest signal. The earlier you catch them, the more options you have.

1. A hiring freeze is announced in all-hands

This is usually framed as “being thoughtful about headcount” or “prioritising quality over quantity.” It sounds prudent. It often means the finance team has told leadership to stop spending.

Hiring freezes don’t always precede layoffs but layoffs almost always start with a hiring freeze. If you haven’t seen one yet at your company, note when it arrives.

2. Stack ranking exercises appear out of nowhere

If your company suddenly introduces or significantly tightens its performance review process outside of the normal cycle, pay attention. Stack ranking is often the mechanism used to build a list before a reduction. The framing is always about “raising the bar.” Sometimes it is. Sometimes it’s preparation.

3. Skip-level meetings get rebranded as “calibration sessions”

When your skip-level starts meeting with your peers without you, and those conversations are described as “calibration,” it usually means leaders are assessing the team.

4. Your manager is added to an extra layer of org chart

Consolidation above you almost always precedes consolidation below. When a new layer of management appears between your manager and their VP, it often means the organisation is restructuring and your team’s scope may shrink as a result.

5. A new PIP cohort opens up

PIPs (Performance Improvement Plans) are sometimes genuine development tools. But a sudden uptick in PIPs across a team or org is often a managed exit strategy — a way to reduce headcount with documentation. If you hear peers talking about being placed on PIPs, take note.

6. Leadership language shifts

Listen carefully to the words used in all-hands, town halls, and company-wide emails. When “growth” and “investment” get quietly replaced by “efficiency,” “doing more with less,” and “AI productivity gains,” that is not coincidence. It is a preview.

If you spot two or more of these signals at the same time, don’t wait. Start moving.

Why Timing Changes Everything

Let me come back to my friend’s story and specifically the part about the lower salary.

According to Zety’s 2025 Post-Layoff Recovery Report, 59% of laid-off workers said facing lower salaries was their top challenge in finding a new job. And that makes complete sense when you understand the negotiation dynamics.

When you search while still employed, you negotiate from strength. You have a salary, you have stability, and you can walk away from any offer that doesn’t meet your floor. The company knows that. They price their offer accordingly.

When you search after a layoff, you negotiate from urgency. Every week that passes costs you money and, if you’re on a visa, costs you legal status. You feel the pressure, and it shows in the conversations. Companies know that too.

This isn’t a knock on anyone who’s been laid off and had to accept something less than ideal to end the uncertainty — that’s a rational decision in a hard situation. But if you can avoid being in that situation by acting earlier, you should.

The same Zety report found that 53% of laid-off workers submitted more than 50 applications before landing a role, and 1 in 5 submitted over 100. Over 30% were unemployed for more than 90 days.

That is the cost of searching after the fact. The goal is to avoid that position entirely.

How to Soft-Search Without Burning Bridges

This is the part most articles skip. They tell you to “update your resume and start networking” without acknowledging the real constraint: you can’t let your employer know you’re looking.

Here’s how to do it properly.

Turn off LinkedIn activity broadcasts before you update anything. Go to Settings → Visibility → Share profile updates. Turn it off. Otherwise, your entire network, including your manager, gets notified the moment you update your title or add a skill.

Reach out to your network under the guise of genuine curiosity. Not: “Hey, I’m quietly exploring opportunities.” Instead: “I saw you moved to Google’s infrastructure team, how’s that been? I’d love to hear what the culture is like there.” Build the conversation first. The opportunity discussion comes naturally from there, or not at all — and that’s fine too. You’re warming the network, not activating a transaction.

Target conversations, not applications. At this stage, you are not mass-applying. You are having 3–5 quality conversations a week with people at companies you’d genuinely consider joining. These conversations give you market intelligence, warm introductions, and when the time comes a very different starting point than a cold application.

Use your personal device and personal email exclusively. This should go without saying, but it bears saying: don’t use your work laptop, work email, or any work tools to conduct your search. Not even for “quick” things.

Don’t tell colleagues. Even people you trust completely. This is not about distrust, it’s about protecting them from an awkward position and protecting yourself from a conversation that reaches the wrong person.

What to Do Inside the Company in Parallel

Soft-searching outside doesn’t mean disengaging inside. In fact, the opposite.

Get visible on high-impact work right now. If layoffs do come and you’re being evaluated, you want to be the person leadership thinks of as essential — not the person who’s been heads-down on a quiet project for six months. Raise your hand for visible work. Take on cross-functional projects. Make sure the right people know what you’re delivering.

Document your impact. Don’t assume your manager is tracking everything you’ve shipped. Write it down. Keep a running log of outcomes, metrics, and decisions you’ve influenced. This serves two purposes: it protects you in a stack-ranking exercise, and it gives you the raw material for an excellent resume and interview stories if you do end up searching.

Build relationships outside your immediate team. Your direct team relationships are valuable. But in a layoff, decisions are often made at the org level — not the team level. Knowing people in adjacent orgs, in leadership, and in other business units creates options that wouldn’t otherwise exist, including internal transfers before separation.

Know your severance policy before you need it. Read your employment agreement and your company’s HR policies. Know what the severance formula is, what the vesting cliff is for your next equity grant, and what the timeline looks like if notice is given. This is basic information that most people only look up when it’s too late to act on it.

The Bottom Line

Layoffs in 2026 are not random bad luck. They follow patterns, and those patterns leave footprints.

The people who land well, in equal or better roles, at equal or better compensation, are almost always the ones who started moving before the announcement, not after.

Start paying attention now. The signs are there if you’re willing to look.

Have you spotted any of these signals at your company recently? Reply and tell me what you’re seeing. I read every response.

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

• 1:1 long-term career coaching to fast-track your career growth and land new opportunities

• Behavioral Interview preparation course for MAANG+ companies

• Mock interviews for your upcoming interviews

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

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

• When Life Throws Lemons: Navigating Layoffs with Resilience

• How to Stand Out When 95,000 Tech Workers Are Job Hunting at the Same Time

• Behavioral Interview Question Bank Categorized into 8 Themes

This week’s post comes from a special guest , author of the newsletter, where he shares insights from his experience on how to get your AI workloads past the demo stage to production. I highly recommend following him on LinkedIn and subscribing to his newsletter.

In this article, he shares why the AI labs need the consultants.

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

Over to you, Sandipan!

Six months ago, the prevailing story was clear: AI had made the traditional consultancy obsolete. Why pay McKinsey day rates when a frontier model could synthesise strategy in seconds? The argument had enough surface logic to fill a dozen conference keynotes.

Then OpenAI launched DeployCo, a $4 billion joint venture with Bain & Company, Capgemini, and McKinsey as founding investors. Anthropic followed with its own enterprise venture, backed by Blackstone and Goldman Sachs, alongside a $100 million partner network anchored by Accenture, Deloitte, and PwC.

The firms that were supposedly extinct are now co-owners of the platforms that were supposed to replace them.

This deserves more than a moment of irony.

What the “death of consulting” argument got wrong

The argument was always a category error. It assumed the consultancy’s core product was analysis - that what Bain or McKinsey sold was structured thinking, market research, frameworks. If that were true, yes: a sufficiently capable model would have undercut them within a budget cycle.

But that was never the product. The product was access.

Access to the CFO who trusts the partner from decades of working together. Access to the board conversation that happens before the RFP is written. Access to the unwritten political map of a large organisation - who actually holds the budget, who will block the implementation, which division chief needs to feel heard before a decision can move.

That cannot be distilled into a model. It took decades to build. It lives in relationships, in dinners, in the credibility that comes from having been right (and wrong) in front of the same people, repeatedly, over time.

Why the AI labs need the consultants

Both OpenAI and Anthropic built something genuinely extraordinary. Then they hit a wall that had nothing to do with the quality of their models.

Enterprise AI deployment is not a technical problem at its core. The model works. The infrastructure can be provisioned. What fails consistently, expensively, and quietly is the organisational layer. The wrong executive owns the project. The business case was written to justify a decision already made. The frontline teams who are supposed to adopt the system were never asked whether the system solved their actual problem. The governance structure for when the AI is wrong doesn’t exist.

These are not engineering problems. They are change management problems, political problems, trust problems.

The consultancies have been solving exactly these problems - in exactly these organisations, with exactly these leadership teams for forty years.

DeployCo’s stated mission is to “identify where AI can make the biggest impact, redesign organisational infrastructure and critical workflows, and turn gains into durable systems.” Read that sentence without the AI framing. It is a description of what consultancies have been selling for so long.

The PE forcing function

There is a second mechanism at work that the “consultants are dead” narrative missed entirely.

Private equity now owns enormous parts of the mid-market. Those firms face mounting sponsor pressure to show AI-enabled value. And they want it as a measurable feature of the business at exit, not as a future roadmap item. That creates urgent demand, at scale, that the AI labs cannot service directly. The labs do not have the client relationships, the sector knowledge, or the change management capability.

Goldman Sachs appears as a partner in both DeployCo and the Anthropic venture. That is not a coincidence. Goldman controls the financial conversations that precede every major enterprise investment decision.

The AI labs are not buying technology capability from these firms. They are buying the room.

What this actually tells leaders

Two things are now demonstrably true, and they are in tension.

The AI labs built models that can genuinely change how organisations operate. They are also, structurally, unable to make that happen without the firms they spent two years threatening to displace.

For leaders making AI investment decisions, the implication is uncomfortable: the quality of the underlying technology is now largely secondary to the quality of the deployment. A superior model, poorly deployed into a politically resistant organisation with no clear ownership and no change management, will produce nothing. An adequate model, deployed by a team that knows the organisation’s real power structure and has the trust of its senior leadership, will produce results.

Technology has never transformed an organisation. Trusted humans, using technology, have. The AI labs just spent $4 billion learning what every failed ERP implementation already knew.

I would like to extend a big thank you to for sharing his insights with Big Tech Careers readers.

I encourage you to subscribe to his newsletter, to keep upto date on strategies to take your AI workloads to production

In this week’s article, I share how to cut through the noise and stand out in the most competitive big tech job market in years.

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

I recently delivered a full-day, 8-hour bootcamp on AI-Powered Big Tech Interview Prep for Tech ICs and Leaders! Here is some of the feedback from the students!

I’ve announced the next date for the bootcamp in July. If you have an upcoming interview in the coming weeks, you can get the recordings of the previous cohort with an option to join the next live cohort. Email bigtechcareers@gmail.com for details.

Let me be honest with you about what’s happening out there right now.

Over 92,000 tech workers have been laid off so far in 2026, according to Layoffs.fyi — bringing the total to nearly 900,000 since 2020. Almost every Big Tech is doing layoffs. And this layoffs wave is far from over.

What this means practically: the moment you apply for a tech role right now, you are competing not just with strong candidates — you are competing with recently laid-off engineers and architects from Big Tech.

Job postings are down 15% over the past year while the number of applications per job has jumped 30%, according to Handshake data cited by Crunchbase. The math is simple and brutal: more people, fewer seats.

If your job search feels harder than it ever has before — it is. You’re not imagining it. But here’s what I want you to take away from this article: the crowd is doing the same things, and that’s exactly your opportunity.

Why the Usual Playbook Is Failing Right Now

Most job seekers are following the same script:

• Apply through LinkedIn or the company careers portal

• Keyword-optimize the resume

• Passively prepare for interviews

• Wait

That script worked in 2021 when companies were scrambling to hire and interviews moved fast. It doesn’t work when hiring managers are swimming in applications from ex-MAANG candidates.

The irony is that the flood of strong candidates has raised the baseline — you’re no longer differentiated just by where you’ve worked. Everyone on the shortlist has an impressive brand on their resume. What separates the people who get offers from the people who get ghosted is what they do that others don’t.

Here’s what that looks like in practice.

1. Your Resume Needs to Reflect Impact, Not Presence

One of the most common patterns I see is candidates leaning too heavily on what they did and not enough on the impact they delivered.

It doesn’t. Not anymore.

When every shortlisted candidate has MAANG on their resume, the differentiator becomes the work — specifically, quantified outcomes. Not “led migration to microservices” but “led migration to microservices, reducing p99 latency by 40% and cutting infrastructure costs by $2M annually.”

A few questions to stress-test your resume bullets:

• Does each bullet answer “so what?”

• Does it reflect your level of ownership, not just participation?

• Could someone else have written the same bullet?

If the answer to the last question is yes, rewrite it. The resume that stands out shows what you drove, not what your team shipped.

2. Your Behavioral Stories Are Your Unfair Advantage

This is the part most candidates underinvest in — and it’s where I see the biggest gap between candidates who make it to final rounds and those who don’t.

Here’s the reality: at the senior level and above, everyone interviewing you can code. Everyone has shipped large-scale systems. Technical chops are a floor, not a ceiling. What separates the hire from the no-hire at MAANG+ is how clearly and credibly you can demonstrate leadership, judgment, and impact through your stories.

The mistake most candidates make with behavioral prep: they prepare stories that describe what happened rather than stories that demonstrate who they are.

Interviewers at companies are listening for their core values. At Meta, they’re scoring you across five specific signal areas. At Google, they want evidence of Googleyness and leadership. These aren’t just frameworks — they are literally the rubrics your interviewers are scoring you against.

Your stories need to be calibrated to those rubrics, not just polished anecdotes.

A few things that separate great behavioral stories from average ones:

• Clear ownership language — “I decided,” “I initiated,” “I advocated for” rather than “we delivered”

• Measurable impact — ideally in time, money, revenue, or customer outcomes

• Honest tension — the best stories have a real constraint, disagreement, or failure that you navigated

• Level signal — the scope and complexity of your story should match the level you’re interviewing for

3. The Network Play Nobody Is Making

Here’s the uncomfortable truth about job applications in this market: cold applications are a lottery.

That’s not to say don’t apply — you absolutely should. But when you’re one of hundreds of applicants for a role, you need parallel paths running. The single most effective parallel path is a referral.

Referrals don’t just help you get seen — they change the dynamics entirely. At most companies, a referral from a current employee puts your resume in a separate queue and signals that someone with skin in the game vouches for you.

Most people handle this the wrong way. They either don’t ask at all (too shy) or they reach out cold with: “Hey, could you refer me to this role?” which puts a stranger in an awkward spot.

Target hiring managers, not just recruiters. Recruiters are gatekeepers with high volume. Hiring managers care deeply about filling their open role. A thoughtful LinkedIn message to a hiring manager — short, specific, showing you’ve done your homework on their team — can get a response when the recruiter queue doesn’t.

4. AI Skills Are No Longer a Differentiator — They’re a Baseline

This one is worth paying close attention to.

According to Dice’s April 2026 Tech Jobs Report, 71% of U.S. tech job postings now require AI skills — up 181% from just one year ago. Their conclusion: AI fluency is no longer a differentiating credential — it has become a baseline expectation.

If you’re not demonstrating AI fluency in your resume, your conversations, and your interview stories by now, you’re not standing out — you’re falling behind.

This doesn’t mean you need to be an ML researcher. It means you should be able to speak credibly about:

• How you’ve used or integrated AI tools in your current or past work

• Your understanding of agentic AI patterns, LLM limitations, and responsible use

• Where AI creates leverage in your specific domain (architecture, SWE, solutions, data)

If you haven’t read my earlier piece on transitioning to AI FDE roles, now is a good time as FDE is one of the hottest role in tech right now. Even if you’re not targeting that specific role, the framing of how to position your AI skills is directly applicable.

5. Treat Your Job Search Like a Project with Metrics

The emotional weight of a long job search is real — especially when you’re competing against this much talent and hearing nothing back for weeks at a time. I’ve watched smart, capable people spiral into self-doubt simply because of the volume of silence they faced.

The best antidote I know is structure.

Treat your search like a project. Define your weekly targets. Track your inputs, not just your outcomes. Something like:

• X applications submitted per week

• X new networking conversations initiated

• X behavioral stories reviewed/refined

• X mock interviews completed

You can’t control whether companies respond. You can control whether you are consistently doing the right things. Metrics give you something to act on — and they keep the search from feeling like a passive waiting game.

And a practical note on timing: hiring cycles at big tech are genuinely longer right now. Build that expectation into your planning. A search that feels slow isn’t necessarily failing — it may just be operating at the speed of the market.

The Bottom Line

The competition is real. The math is working against everyone right now. But most candidates are applying the same strategies, telling the same generic stories, and waiting passively for callbacks that don’t come.

The candidates who land offers in this market are doing something different: they’re leading with specific impact, they’re building warm paths in before they apply, they’re investing deeply in behavioral prep calibrated to each company’s rubric, and they’re showing genuine AI fluency.

None of these are shortcuts. They’re the fundamentals — executed with more intention than the person applying alongside you.

Here is what I covered in the full-day, 8-hour bootcamp on AI-Powered Big Tech Interview Prep for Tech ICs and Leaders!

Though the next live cohort is in July, if you have an upcoming interview in the coming weeks, you can get the recordings of the previous cohort with an option to join the next live cohort.

Interested? Email bigtechcareers@gmail.com for details.

Though I position this as an Interview Prep course, frankly it helps you grow professionally in your career! Have a read of the feedback below from one of the MAANG participants.

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 bigtechcareers@gmail.com

This week’s post comes from a special guest Milos Mandic, Forward Deployed Engineer at Lleverage and author of the FDE Hub newsletter, where he shares insights from his experience as an FDE and interviews others in the role.

If you’re curious about what it means to be a Forward Deployed Engineer, I highly recommend following him on LinkedIn and subscribing to his newsletter.

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

Over to you, Milos!

Register interest for AI FDE course

The FDE role has been getting a lot of attention lately, and with attention comes skepticism. I’ve seen the comments on LinkedIn, the Reddit threads, the Twitter dunks. “It’s just professional services with a fancy title.” “Glorified consultant.” “Military cosplay for tech bros.”

I get it. New titles invite mockery. It’s human nature.

About two years ago, I was at a spontaneous standup comedy show in Cork with a friend who works as a product manager. The comedian spotted him in the crowd, heard the title, and paused. “Product manager? That sounds like a fancy title for a drug dealer.” Beat. “What exactly is the product?”

The room laughed. My friend laughed. I laughed.

Tech has a title problem. We keep inventing new ones, and outsiders keep assuming we’re either making them up or hiding something. Sometimes both.

Fifteen years ago, when I started university, “software engineer” was still fighting for legitimacy. People who “just wrote code” weren’t considered real engineers. The title felt aspirational, maybe even a bit pretentious. Who’s questioning it now?

Titles evolve. What matters is what you actually do and what you learn doing it.

So let me tell you why I chose this path, and more importantly, who probably shouldn’t.

Thanks for reading FDE Hub! Subscribe for free to receive new posts and support my work.

The entrepreneurship training ground

Naval Ravikant has a famous line: “Learn to sell. Learn to build. If you can do both, you will be unstoppable.”

I’ve been an entrepreneur before. It runs in my blood. And when I look at the FDE role through that lens, I see something most people miss.

This role is entrepreneurship training with a salary.

Every week, I’m selling. Not in the quota-carrying, commission-driven sense. But selling nonetheless. Selling a technical approach to a skeptical stakeholder. Selling patience to a client who wants everything yesterday. Selling the idea that the first version won’t be perfect, and that’s okay.

Every week, I’m building. Not just code. Workflows. Integrations. Trust.

Every week, I’m sitting with customers, watching them work, spotting problems they didn’t know they had. That pattern recognition is invaluable. It’s the kind of market insight founders pay consultants thousands for, and I’m getting it as part of the job.

I’ve picked up knowledge in domains I never expected. I couldn’t pass a chartered accountant exam, but I’ve become surprisingly proficient in bookkeeping. I’ve learned how insurance claims get processed, how logistics companies optimise routes, how wholesale distributors manage inventory. None of this was in the job description. All of it compounds.

If you want to start a company someday, or if you’ve already tried and want to try again, this role puts you in the best possible position. You develop the full stack of entrepreneurial skills while someone else handles payroll.

Who shouldn’t do this

Not everyone should be an FDE. I mean this genuinely, not as gatekeeping.

In my analysis of nearly 2,000 FDE profiles, the average FDE has 12 years of industry experience. That’s not a coincidence. This role requires a certain baseline of confidence, autonomy, and accumulated judgement.

When I started at Lleverage, there was no playbook. No onboarding manual that told me how to handle a client who changes requirements mid-sprint, or how to push back on a sales promise that’s technically impossible, or how to know when a project should be killed rather than saved. We figured it out. We had to.

If you need guidance, if you thrive with clear expectations and well-defined processes, this role will break you. Not because it’s harder than other roles. Because it’s differently hard. The ambiguity is the job.

There’s another reason to stay away: if you don’t care about the breadth.

Maybe you’re a world-class software engineer. Maybe you’ve spent years mastering distributed systems or compiler design or machine learning infrastructure. That depth is valuable. The world needs people who go deep.

FDEs don’t go deep. We go wide.

Jack of all trades, master of none. I used to hear that as an insult. Now I see it as a job description. Most FDEs will never be the best engineer, the best salesperson, or the best product thinker in any room. But we might be the only person in the room who can do all three passably well, in the same afternoon, for different clients.

It turns out the world needs people like that too.

On the hate

I want to address something directly.

The criticism of this role often boils down to: “This isn’t new. You’re just consultants. You’re just sales engineers. You’re just solutions architects with better marketing.”

There’s some truth there. The activities aren’t entirely new. People have been deploying software at client sites for decades.

But the context is new.

AI has changed what’s possible in a single deployment. The productivity gains mean smaller teams can do more. The pace of model improvements means yesterday’s impossible is today’s afternoon project. The ambiguity of what AI can actually do in a specific business context means someone needs to figure it out on the ground, in real time, with real stakes.

That’s the FDE role in 2026.

Is it a fancy title? Sure. So is “software engineer.” So is “product manager.” So is every title that didn’t exist fifty years ago. The question isn’t whether the title is new. The question is whether the work creates value.

I think it does. But I’m biased.

Looking forward

There’s always risk in any career bet. Technology moves fast. The role that exists today might not exist in five years, or it might look completely different.

But here’s what I’ve noticed: FDEs are positioned better than most to adapt.

We’re stretched thin by design. We’re always looking for the most optimal way to do something because we have to be. We’re at the bleeding edge not because we’re early adopters by personality, but because the job demands it. When new tools emerge, we’re often the first to try them, because our productivity depends on it.

This role wouldn’t exist in its current form without AI. And if AI continues to reshape how work gets done, FDEs will be among the first to know, because we’ll be the ones doing the reshaping.

That’s not a guarantee. It’s a bet. But it’s a bet I’m comfortable making.

The real question

If you’re considering this path, ask yourself:

Do you thrive in ambiguity, or does it drain you?

Can you sell an idea to a sceptical room without feeling like you’ve betrayed your engineering soul?

Are you okay being pretty good at many things rather than exceptional at one?

Do you have the agency to figure things out when no one’s going to tell you what to do?

If yes, this might be your path.

If no, that’s not a failure. It’s self-knowledge. The world needs specialists. The world needs people who go deep. The FDE path isn’t better. It’s just different.

I chose it because it matches how my brain works. Because it feeds the entrepreneurial itch without the existential risk. Because every week teaches me something I didn’t know I needed to learn.

Your reasons might be different. Or this might not be for you at all.

Both are fine.

I would like to extend a big thank you to Milos Mandic for sharing his insights with Big Tech Careers readers.

I encourage you to subscribe to his newsletter, FDE Hub, to learn more about the FDE role.

If you are looking to transition to AI FDE role, these articles will be helpful

1. The Role of Forward Deployed Engineers (FDE) in the AI Era

2. How to Transition from a Developer or Architect to AI FDE roles -

3. Skills You Need for AI FDE Roles at OpenAI, Anthropic, NVIDIA, Databricks & Salesforce

Want to be become an AI FDE, register your interest for 4-6 week FDE course.

Register interest for AI FDE course

This week, I’m sharing tips from recent experience of my mentee clearing a LIVE coding interview round at Data and AI company

If you enjoy this article, click the ❤️ icon — it helps me know what content resonates with you.

I recently delivered a full-day, 8-hour bootcamp on AI-Powered Big Tech Interview Prep for Tech ICs and Leaders! Here is some of the feedback from the students!

I've announced the next date for the bootcamp in July. If you have an upcoming interview before July, the bootcamp is also available as self-paced. Details at the end of the article.

One of my mentee recently cleared a Live Coding Interview at a Data and AI Company.

They had no idea what to expect walking into a live coding interview at a major Data and AI company and somehow came out the other side with a pass.

Here’s what they learned.

The Biggest Misconception About Live Coding Interviews

Everyone thinks a live coding interview is a technical test. It is not.

Yes, there is code involved. Yes, you are solving a technical problem. But the coding part is actually the easy bit. You are given a problem, you use AI tools to generate the code, and you work through it step by step.

So if the coding is easy, what are they actually testing?

They are testing how you think. How you communicate. How you approach a problem you have never seen before. How you behave when something goes wrong. How you explain a technical decision to a non-technical person. How you react when you are stuck.

Every single one of those is a behavioural signal.

The interviewer is sitting next to you asking themselves: is this how this person would show up in front of a real customer? Would I want them on my team? Can they handle pressure and still communicate clearly?

That is the real interview. The code is just the context it happens in.

With AI coding assistants now doing most of the heavy lifting, the technical barrier to writing working code is lower than ever. Anyone can generate a working data pipeline with a good prompt. What separates candidates is everything that happens around the code. The questions they ask. The way they explain their thinking. The calm they show when an error appears. The business reasoning behind every decision.

Prepare for that. That is what is being tested.

6 behavioral tips to apply in your next live coding interview

1. Think out loud constantly

Never go silent. This is the single most important thing.

Narrate every decision you make. Say what you are about to do before you do it. Say what you notice when you look at the output. Say what concerns you about a piece of code.

Silence reads as confusion. Talking makes you look confident even when you’re figuring things out.

2. Ask clarifying questions before touching anything

Spend the first few minutes understanding the problem properly. Ask about the business context. Ask about data volumes. Ask about quality expectations.

It mirrors how professionals actually work with clients and shows structured thinking.

3. Validate as you go, not at the end

Run code in small increments and check output at each step. Don’t solve the full problem before you start validating.

Catching issues early shows discipline and prevents compounding errors that are harder to debug later.

4. Debug out loud when things break

When something breaks, slow down and narrate your debugging process.

Read the error message out loud. Name the root cause. Explain your fix before you apply it.

Interviewers care more about how you handle failure than whether everything runs perfectly first time.

5. Connect every technical decision to a business reason

Do not just say what you are doing. Say why it matters. “I am removing duplicate records to avoid double counting revenue.” “I am using a left join to keep all customers even if they have no orders.”

This is the difference between someone who codes and someone who solves business problems with code.

5. Pilot your tools, don’t just use them Whether it’s AI, documentation or Stack Overflow — always audit the output. Catch things that look wrong, explain what the code is doing in your own words, and push back when something doesn’t make sense. Showing critical judgment over tools is what separates strong candidates from everyone else.

6. Vibe code with intention

AI assistants are fair game. Use them. But catch the things that look wrong. Explain what the code does in your own words. Push back when something doesn’t make sense. Identify opportunities to optimize the code.

The candidates who impress are the ones who direct the AI with specific, detailed prompts and then audit what comes back. Vague prompts produce vague code.

Showing critical judgment while using AI to generate code is what separates strong candidates from everyone else.

Final Thought

The interviewer is not trying to catch you out. They want to see a future colleague in action. Stay calm, keep talking, and show them you can think clearly under pressure.

That is all they are really testing.

My mentee was not a data engineer and had minimal experience with data analytics going into this interview. If someone like them can clear it, technical skills are clearly not the main concern.

What they showed was simple. They worked through an unfamiliar problem methodically. They communicated their thinking at every step. They treated the interviewer as a collaborator to solve the problem together.

That is what the interviewers look for. Someone who can sit across from a customer, navigate ambiguity, and get to a solution without falling apart. The coding is just the vehicle. The behaviour is the test.

Here is what I covered in the full-day, 8-hour bootcamp on AI-Powered Big Tech Interview Prep for Tech ICs and Leaders!

While the next live cohort is in July, you can get the self-paced version at 50% off to prepare for your upcoming interviews.

You'll get access to the recording, the AI tool, and a Discord community of professionals preparing for big tech interviews — just like you!

Interested? Email bigtechcareers@gmail.com for details and the payment link.

This week, I’m sharing which AI role you should aim for based on whether you like building, scaling, shipping, or advising.

If you enjoy this article, click the ❤️ icon — it helps me know what content resonates with you.

Ashish Prajapati is running a one-day live bootcamp for the NVIDIA Associate — AI Infrastructure and Operations (NCA-AIIO) certification on May 16th. Ashish is 5x NVIDIA certified and his self-paced NVIDIA courses on Udemy are top rated.

He’s offering 50% off for Big Tech Careers readers this week.

Claim 50% off for NVIDIA Certification

Everyone wants to “work in AI,” but that’s too vague to be useful. The better question is: which AI role fits your strengths, your interests, and the way you like to work?

The AI job market is no longer a single track. It now has clear lanes for builders, model specialists, product thinkers, infrastructure operators, customer-facing problem solvers, and strategic advisors. If you pick the right lane, you are not just chasing a hot title — you are building a career that compounds.

The top 6 AI roles

A practical shortlist for 2026 is:

1. AI Engineer.

2. Machine Learning Engineer.

3. AI Product Manager.

4. AI Platform / MLOps Engineer.

5. AI Forward Deployed Engineer.

6. AI Solutions Architect / AI Consultant.

That works because it moves from building the tech, to shaping the product, to making it run at scale, to delivering it in the real world, and finally to advising organizations on how to use it well.

AI Engineer

If you like shipping quickly, AI Engineer is one of the most natural places to start. This role is for people who want to build AI features, agents, workflows, and product experiences that users can actually touch.

AI Engineers usually sit close to software delivery, and the work often involves LLM APIs, retrieval systems, prompt orchestration, and application logic. It is a good fit for software engineers who want to move into AI without going into deep research.

This role fits you if:

• You enjoy building products.

• You like rapid iteration.

• You want visible impact.

Machine Learning Engineer

If you care more about model behavior, data, and performance, Machine Learning Engineer is the better fit. ML Engineers work on training, fine-tuning, evaluation, and deployment, and they care deeply about whether the system is accurate, stable, and useful in production.

This role remains one of the backbone jobs in AI because every serious AI system depends on model quality. It is especially strong for people who enjoy technical depth and want to work closer to the science of the system than the interface.

This role fits you if:

• You like data and evaluation.

• You want depth over flash.

• You enjoy hard technical problems.

AI Product Manager

AI Product Manager deserves a place in the lineup because it is the role that connects AI capability to business value. These people decide what gets built, why it matters, and how success is measured.

This role is growing because AI is no longer just a lab experiment. Companies need product leaders who understand what AI can and cannot do, and who can translate that into roadmaps, user flows, and real outcomes. It is a strong choice if you want influence without being purely technical or purely commercial.

This role fits you if:

• You like prioritization.

• You enjoy balancing trade-offs.

• You want to shape what ships.

AI Platform / MLOps Engineer

If you love systems, reliability, and scale, this is the lane to watch. AI Platform and MLOps Engineers build the infrastructure that keeps AI working in production, with monitoring, deployment pipelines, inference optimization, and operational control.

This role matters more as AI moves from demos to real usage. Businesses now need systems that are fast, observable, cost-aware, and resilient, which makes platform-minded engineers increasingly valuable.

This role fits you if:

• You think in systems and pipelines.

• You care about reliability.

• You want to build the rails, not just the app.

AI Forward Deployed Engineer

This is one of the hottest roles in the market right now. AI Forward Deployed Engineers work directly with customers or enterprise teams, taking AI from prototype to production and adapting solutions to real-world constraints.

What makes the role interesting is the mix of skills it demands. You need enough technical depth to build, enough product sense to know what matters, and enough communication skill to work with clients. That makes it one of the best roles for people who like variety and want to see the direct business effect of their work.

This role fits you if:

• You like customer interaction.

• You enjoy ambiguity.

• You want engineering with a consulting edge.

AI Solutions Architect

AI Solutions Architect is the most strategic role in this set. These professionals help organizations decide how to use AI, how to integrate it, and how to design systems that are secure, scalable, and useful.

This is a particularly strong path for people who are technically fluent but also enjoy big-picture thinking. The role rewards people who can explain trade-offs clearly, influence stakeholders, and connect technology choices to business outcomes.

This role fits you if:

• You like architecture and strategy.

• You enjoy explaining complex ideas.

• You want to guide adoption, not just execution.

Which role fits who

Here’s the simplest way to map the roles to strengths:

• Builder at heart? AI Engineer.

• Model and data obsessed? Machine Learning Engineer.

• Product and business minded? AI Product Manager.

• Systems and reliability focused? AI Platform / MLOps Engineer.

• Customer-facing and delivery-driven? AI Forward Deployed Engineer.

• Strategic and consultative? AI Solutions Architect.

That progression reflects where the market is heading: toward people who can not only build AI, but operationalize it, deliver it, and help organizations use it well.

Final thought

The best AI role is not the one with the flashiest title. It is the one that matches how you think, what you enjoy, and how you want to spend your day.

Where NVIDIA fits

NVIDIA sits under much of this career stack as part of the compute and platform foundation behind modern AI.

It matters most for AI engineers, ML engineers, and platform roles, where GPU performance, inference optimization, and scale all influence what gets shipped.

In other words, NVIDIA is is part of the engine that powers several of the hottest roles.

And that’s the reason Ashish’s NVIDIA 1-day Certification bootcampe is trending at 2nd position on Maven.

75+ people already enrolled! With 48 people enrolled last week. Last few seats remaining before registrations closes.

He’s offering 50% off for Big Tech Careers readers this week.

Claim 50% off for NVIDIA Certification

This week, I’m sharing how you can showcase your AI Experience when applying for AI roles at tech roles!

I’m also running a full-day live workshop on Interview Prep on May 2nd, where I cover all the strategies to clear your big tech interviews and demonstrate how to use this custom AI tool in practice.

If you enjoy this article, click the ❤️ icon — it helps me know what content resonates with you.

Getting a AI role at a top tech company means sitting in front of a hiring manager and answering questions about your AI experience. Many candidates struggle here — they’ve done real work, but they don’t know how to present it in a way that lands.

Here’s what you need to know.

What Interviewers Are Actually Testing

When a hiring manager asks “tell me about an AI project you worked on,” they’re looking for three things:

Hands-on depth. Did you actually build it, or were you just in the room when someone else did? They want to hear specifics — the tools you used, the problems you hit, the decisions you made.

Critical thinking. AI tools produce wrong outputs. Interviewers want to know whether you trust everything a model tells you, or whether you question it and dig deeper.

Learning ability. AI is moving fast. They want to see that you’re keeping up — that you learn from each project and apply that knowledge going forward.

The Five Questions You’ll Likely Face

These come up in interviews related AI roles :

1. Tell me about the most impactful AI solution you’ve designed or contributed to.

2. Walk me through a solution that required you to learn something new — and how you identified your knowledge gaps.

3. Tell me about a time an AI tool gave you a wrong or misleading output.

4. Describe a time you explained an AI solution to a non-technical stakeholder.

5. Have you ever flagged a bias or ethical concern in an AI system?

If you can answer these with a real story from your experience if you have, you’re in good shape.

Use the STAR Framework — with an AI Twist

Most people know STAR: Situation, Task, Action, Result. It’s a solid structure for any behavioural interview. When talking about AI work, add few additional details!

Here’s the AI edition:

• Situation — What problem existed that AI could solve?

• Task — What specific outcome were you trying to achieve with AI?

• Action — What tool or approach did you choose, and why that one?

• Why AI — Why was AI the right approach here, rather than something else?

• Result — What was the measurable outcome?

• What I Learned — What did this teach you about working with AI?

That last point matters more than most candidates realise. Interviewers at top companies are specifically listening for self-awareness and growth. Telling them what you’d do differently is a strength.

A Real Example

Here’s how this framework plays out in practice, using a real interview answer for a Data and AI Solutions Engineer role at a Data and AI company .

The question: “Can you talk me through a data and AI solution that you’ve either designed or contributed to recently?”

Situation

Let me talk about a customer which is a global recruitment agency operating across around 40 countries – where I implemented Gen AI solution in Q3/Q4 last year.

They had been doing Gen AI experiments but wanted to move beyond experiments and apply AI in a way that would genuinely improve recruiter productivity across regions — while staying compliant with HR and legal requirements specific to each country.

Recruiters were spending too much time searching across multiple portals and documents. The business wanted something scalable and safe.

There was also a competitive threat from another vendor, who were pitching their Gen AI capabilities heavily, so there was pressure to move quickly.

Task:

As a Principal Solutions Architect, my role was to find the right use cases, shape the architecture, do initial prototypes and to enable the customer teams to take the solution forward.

I ran workshops with business and technical teams to identify high-priority Gen AI use cases. From an initial list of around 8–10, I narrowed to 3 use cases: a recruiter knowledge assistant (RAG-based), candidate matching at scale, and safe/consistent AI deployment. I prototyped 2 of the 3.

Action:

For the RAG-based knowledge assistant, I designed the full ingestion and query pipeline: documents were stored in S3, chunked via AWS Lambda, embedded using Titan embeddings, and stored in OpenSearch as the vector database. The model was Claude on Bedrock.

The assistant was giving arbitrary answers even after everything was set up. I initially looked at the model and prompt engineering, but when I dug into the chunking and retrieval stage specifically, I found the problem. I had set a 512-token chunk size, which was working fine for other use cases but not here.

The HR policies were country-specific, and the token boundary was splitting sentences mid-context — so when a recruiter asked a query, they were not getting accurate answers as the context window was bleeding across boundaries. Switching to sentence-boundary splitting fixed it.

In parallel, I worked on an evaluation and safety framework — this was the bigger learning curve, and it was less about technology and more about navigating internal customer dynamics.

I built 80 gold standard test cases and a confidence threshold scoring system, so the COE team had a clear basis to approve moving to production.

To get buy-in across the organisation, I flew to customer location for 7 days with 4 colleagues. I ran a 5-day workshop with their business and tech teams.

I got senior recruiters to do reverse-shadow sessions on the AI knowledge assistant. The customer legal and compliance teams flew in from Netherlands, Malaysia and Australia to be in the room.

I worked through two specific mandates from customer leadership: quality must improve over time (they understood that solution will not be perfectly accurate at launch), and responses must remain compliant with HR and legal policies across all countries.

For this opportunity, we had top-down buy-in from the CEO and CTO but I also had to bring in line-of-business owners on the ground, country by country to move things forward.

Result:

Recruiter search time reduced by 30–40%, validated through pre and post evaluation criteria.

An unexpected byproduct was that new recruiter ramp-up time dropped by 20% — the goal had been to help existing recruiters, but because there was now one portal instead of five, new joiners had a dramatically simpler onboarding experience.

I’ll give an example of a specific edge case outcome which set the benchmark. In some counties of far east countries, contract rates for specific job roles change monthly and recruiters had to manually check government portals before rolling out offers.

I automated this — new government documents are ingested into S3, chunked, and served through the RAG system with guardrails. This was tested with senior recruiters multiple times and certified.

What Comes After the Main Question

Interviewers don’t stop at one question. Once you’ve told your story, expect follow-ups like:

• How did you prioritise which use cases to prototype?

• Did this go to production?

• Were there alternative architectures you considered?

• How would you approach this differently today, given how much the space has moved?

• How did you handle conversations with the business about the risks of LLMs processing personal data?

The candidates who answer these well are the ones who were genuinely involved in the work — who made real decisions, hit real problems, and had to explain their reasoning to real stakeholders.

I’ll cover the entire flow in the full day workshop on May 2nd.

IN THIS WORKSHOP YOU’LL LEARN

• How to craft Big Tech ready resume

• How to deliver high-impact responses in STAR format

• How to craft compelling technical achievement stories

• How to effectively communicate leadership experiences

• How to share lessons learned from past failure and conflict experiences

• How to craft and deliver senior level responses to get hired at the right level

Then put it all into practice with FREE AI-powered mock interviews for a week using custom AI tool!

Last chance to get 50% off. Use the code LASTCHANCE50!

Join AI-Powered Interview Prep at 50%

This week, I’m sharing how you can build your story bank using a custom AI tool that acts as your personal AI Coach for big tech interview preparation.

I’m also running a full-day live workshop on Interview Prep, where I cover all the strategies to clear your big tech interviews and demonstrate how to use this custom AI tool in practice.

If you enjoy this article, click the ❤️ icon — it helps me know what content resonates with you.

If you’ve read my previous articles, you’ll know I’m a strong advocate of building your story bank around eight categories I’ve curated: Customer Focus, Success, Failure, Conflict, Problem Solving, Learning Mindset, Leadership and Time Management. This approach keeps your preparation company-agnostic, while still allowing you to map your stories to any company’s core values and adapt them as needed.

I’ve created templates to help you build stories for each of these categories. I'd been planning to build a custom AI tool to help you through this process, and that's now a reality.

Vamsi Narla, Founder of Revarta — a complete behavioral interview mastery platform — has integrated the BigTechCareers story bank directly into Revarta, along with a Story Builder powered by the Revarta AI Coach to help you build your story bank. And it’s free forever!

You can sign up to Revarta and build your story bank at no cost!

Build Story Bank using AI for free

There are premium plans available, if you would like to use Revarta to do mock interviews and practice your answers loud using AI coach. And frankly the pricing is pretty reasonable compared to doing mock interviews with coach like me.

As an interview coach, I know it feels like I’m replacing myself here with an AI but I love what Revarta has built. And honestly, I never had enough bandwidth to do 1:1 career coaching and interview prep coaching.

Instead, I focus on small group coaching! So, I’m running a full-day live workshop on AI-powered Interview Prep on 2nd May!

IN THIS WORKSHOP YOU’LL LEARN

• How to craft Big Tech ready resume

• How to deliver high-impact responses in STAR format

• How to craft compelling technical achievement stories

• How to effectively communicate leadership experiences

• How to blend technical depth with strong behavioral skills

• How to maintain authenticity while following structured frameworks

• How to project confidence through voice, body language, and pacing

• How to share lessons learned from past failure and conflict experiences

• How to craft and deliver senior level responses to get hired at the right level

Then put it all into practice with FREE AI-powered mock interviews for a week using Revarta!

With the right strategy and preparation, you can showcase your expertise and demonstrate your leadership potential.

Here is the full workshop agenda:

And with the workshop you’ll get free access to unlimited mock interviews on Revarta Platform for a week!

And we are offering 50% discount with the code REVARTA50.

Join AI-Powered Interview Prep at 50%

Now I'll hand it over to Vamsi to walk you through how to use Revarta to build your story bank. Over to you, Vamsi!

Thanks Prasad! As you know, single highest-leverage thing you can do to prepare for big tech interviews is to build a repository of structured stories.

Here’s the part most people underestimate: you have to build stories before you need them, because your best raw material is leaking out of your head every single week.

Think about your last month at work. You shipped something. You navigated a cross-functional disagreement. You coached a teammate through a tough launch. You made a hard tradeoff on a roadmap call. Each of those moments was a story-worthy experience at the time the context was sharp, the numbers were fresh, the specific decision you made was still clear in your mind.

Now try to recall the texture of something similar from six months ago. The outcome you remember. The details, the exact stakeholders, the specific tradeoff, the number you moved have faded into a vague outline. A year later, most of it is gone.

The fix is a continuous habit: capture one story every week or two, while the details are still fresh. Build the library before you need it. This is where AI has actually changed the game.

Step 1: Let AI find your story candidates from your resume

Open Story Builder and choose “From your resume.” Upload your PDF. The AI reads it and identifies 4-8 story candidates specific projects, leadership moments, problem-solving situations, growth experiences from your actual background that have enough signal to be interview-worthy.

You don’t have to think about what to talk about. The AI surfaces the strongest material from your background and gives you a queue to work through.

Step 2: Pick a candidate and start the voice conversation

Pick a candidate. The AI coach kicks off by referencing the specific experience from your resume “I see you led the migration to microservices. Tell me what was happening before you started this...”

You answer out loud. Not typing. This matters.

Interviews happen out loud. The muscle memory you build by typing a polished answer doesn’t transfer to the moment when an interviewer asks you a question and you have 30 seconds to start talking. Voice-first practice is the only kind that builds the right reflex.

Step 3: Let the coach probe for STAR depth

This is the part most candidates skip when they prep alone. The AI doesn’t just record what you say it actively listens for STAR coverage and probes specifically where you’re thin.

• Vague on Action? “What specifically did you do to address that? Walk me through your decision-making.”

• Missed the Result? “What was the measurable outcome? What did you learn that changed how you operate?”

• Spending too long on Situation? It redirects you forward.

The visible STAR indicator at the top tells you in real time which sections are strong, partial, or missing. You leave the conversation knowing your story is complete not hoping it is.

Step 4: Get a synthesized, mapped, ready-to-use story

After the conversation, the AI structures everything into a polished STAR story preserving your specifics and your voice, not generic AI prose. Then it does two things most prep tools don’t:

1. Maps the story to 3-5 specific behavioral interview questions

2. Auto-tags it to 1-2 categories - Leadership, Conflict, Failure, Success, Problem Solving, Learning, Customer Focus, Time Management

That’s your library entry. Categorized. Indexed. Ready to pull from when an interviewer asks “tell me about a time you pushed back on a stakeholder.”

Step 5: Build the habit. One story per week.

The compounding move: don’t try to build all your stories at once. One session per week. Each session takes 15-20 minutes. In two months you’ll have a categorized library covering all eight behavioral themes built before any recruiter reaches out.

This is the difference between scrambling two weeks before a loop and selecting from a library you already trust. Interviewers can tell which one you are within 30 seconds.

Join AI-Powered Big Tech Interview Preparation

Learn from an expert behavioral interview coach, build your story bank and practice mock interviews with a custom AI tool - ALL IN A ONE DAY WORKSHOP.

You’ll get one week of free access to the Revarta platform for unlimited mock interviews. In the workshop, we’ll show you how to build your story bank using the Story Builder and prepare for your next big tech interview.

Sign up this week and get 50% off using the code REVARTA50 →

Join AI-Powered Interview Prep at 50%

This week’s post comes from a special guest , Forward Deployed Engineer at Lleverage and author of the newsletter, where he shares insights from his experience as an FDE and interviews others in the role.

If you’re curious about what it means to be a Forward Deployed Engineer, I highly recommend following him on LinkedIn and subscribing to his newsletter.

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

Over to you, Milos!

Ashish Prajapati is running a one-day live bootcamp for the NVIDIA Associate — AI Infrastructure and Operations (NCA-AIIO) certification on May 16th. Ashish is 5x NVIDIA certified and his self-paced NVIDIA courses on Udemy are top rated.

He's offering 50% off for Big Tech Careers readers this week.

Claim 50% off for NVIDIA Certification

Since I started writing newsletter, I’ve had dozens of people reach out saying they love what I’m sharing about the FDE role. The most common request? Tell us more about the day-to-day. The actual experience. What does a week actually look like?

Fair enough. Here’s a recent one. Ten clients, fifty hours, and enough context-switching to make your head spin.

A quick note: at larger companies like Palantir or OpenAI, FDEs typically go deep on one or two clients at a time. At a startup like Lleverage, I’m running parallel deployments across many clients simultaneously. It’s a different version of the role, less depth, more pattern recognition across contexts. Both are valid. This is the startup FDE experience.

Monday: Planning the Chaos

The week starts with a planning session. Me, the other FDEs, and our head of customer delivery sit down for an hour to review every active client and set priorities for the week.

This sounds corporate. It isn’t. It’s survival.

When you’re working with ten clients in parallel, you need to know which fires are smouldering before they become infernos. Which PoC is about to hit a deadline. Which client has been quiet for too long, which usually means they’re stuck and haven’t told us yet. Which prospect needs a scoping call before they lose momentum.

We use Linear to track everything. Each client has their own project, their own set of tasks, their own status. Without this, I’d be lost within a day.

After planning, the rest of Monday is a blur of calls. Status updates with existing clients. A pre-sales call with a prospect trying to figure out if what they want is even possible. By the time I look up, it’s 6pm and I haven’t written a single line of code.

This is more common than I’d like.

The Two Active Builds

I usually have two clients in active build mode at any given time, with the rest in earlier or later stages.

The first might be something like a document processing pipeline. On paper it sounds simple. Documents come in, structured data comes out. In practice, a single client will have half a dozen document types arriving from a dozen different sources, each one needing to be classified, routed, validated against business rules, and then pushed into a downstream system that has its own opinions about what valid data looks like.

You get to 80% quickly and it feels like the end is in sight. It isn’t. The core workflow runs. I can take a clean example, extract what’s needed, hand it off in the required format, and the demo lands well. Everything after that is the part nobody sees.

Documents arrive in formats that don’t quite match the spec. Fields that are mandatory in theory turn out to be optional in practice, and the agent has to know the difference. Two operators at the same client disagree about what the right answer should be on the same document, which means there isn’t really a ground truth, there’s a negotiation. Handwritten annotations confuse the OCR. A customer sends scanned PDFs at a resolution that makes the whole thing unreliable. The downstream system rejects an upload because of a field constraint nobody mentioned in the scoping call.

A lot of my building time goes into chasing these. Tightening prompts, adding context the model needs to disambiguate one document type from another, expanding the test set to catch failures we hadn’t seen yet, adding fallbacks for the cases where the agent should escalate to a human instead of guessing. None of it is glamorous. It’s the difference between a demo that impresses people and a system that runs in production without someone babysitting it.

The second build is usually earlier stage. We’ve proved the concept on a handful of input-output pairs and now we need to scale to a hundred or more, which is where the architecture that worked for the prototype starts to creak. A PoC is a magic trick. Production is plumbing. Moving between them often means rethinking decisions you made when you were just trying to prove the thing was possible at all.

This is also where coding agents have changed the shape of my week. I run Claude Code in the background on a lot of the grunt work, scaffolding test cases, refactoring messy prototype code, drafting integration glue against an API I’m still figuring out. It hasn’t reduced the thinking. If anything, it’s made clearer how much of the job was thinking in the first place. What it has done is compress the typing, which means the constraint moves further upstream. The bottleneck is no longer how fast I can build. It’s how quickly I can extract enough operational context from the client to know what to build next.

The Communication Sprawl

I’m logged into dozens of Slack workspaces and Microsoft Teams instances. Every client uses their own tools and we meet them where they are, so I have Slack for some, Teams for others, each with their own channels, their own notification sounds, their own conventions for what counts as urgent. Most clients also have my phone number, which means a real escalation can land as a WhatsApp message at 9pm on a Sunday. That hasn’t happened often, but it’s happened enough that I keep my phone within reach.

On top of that there are our internal tools. Linear for project tracking, Notion for documentation, Google Docs for shared specs and proposals, Excel for data analysis and quite often as a source of data, Postman for poking at APIs, and Claude and Claude Code threaded through most of it for writing, debugging, and thinking out loud.

Context-switching isn’t really about moving between projects. It’s about remembering which client uses which tool, which channel is for urgent issues versus general updates, and where I left a conversation three days ago when I was last in their world.

When Things Break

Every few weeks, something upstream goes down. A model provider has an incident, a cloud region wobbles, an auth service hiccups. When that happens, our clients have problems, and when our clients have problems, they message us.

Half a day disappears into firefighting. Checking status pages, sending updates to clients who are panicking, trying to figure out if there’s anything we can do to route around the outage. Often there isn’t, but you still have to check. You can have the perfect week mapped out and then an upstream provider takes you straight into reactive mode. The deep work you had blocked out waits another day.

We have monitoring in place to catch these issues early, which helps. It doesn’t eliminate the disruption.

The 50/50 Split

If I’m honest about time allocation, it’s roughly 50% meetings and 50% building. The meetings are client check-ins, internal planning, pre-sales calls, scoping sessions, status updates, and the occasional firefighting call. The building is actual coding, prompt engineering, testing, debugging, and feeding insights back to our product team about what primitives we need.

I try to protect Tuesdays and Thursdays for deep work. Four-hour blocks where I can actually make progress on complex problems. It doesn’t always hold. A client escalation or an urgent prospect call can blow up any day. But when I do get those blocks, that’s when the real work happens.

The short gaps between meetings, the 30 to 60 minutes here and there, are for small fixes and maintenance. You can’t architect a system in 45 minutes, but you can tweak a prompt, kick off an agent on a small refactor, respond to a client question, or review test results from an overnight run.

The People Part

Most of my conversations are with business stakeholders, not technical people. This surprised me at first. I expected to spend more time with engineers, but in practice I talk to technical people mainly when I need access to systems or help with integrations. The day-to-day work is with operations managers, department heads, and executives who are trying to figure out what AI can actually do for their business.

A lot of that work is translation. Explaining what’s possible, managing expectations about what AI agents can and can’t do, redirecting requests from “we want an AI that figures everything out automatically” to “let’s start with these specific inputs and outputs.” We found ourselves repeating the same explanations so often that we built a playbook. It’s a document we share with every client that covers what data we need from them, how we communicate, how they should test and give feedback, and how to capture the SOPs and business rules that the agent needs to do its job.

That last part is the one that matters most. Agents need the rules of your business written down somewhere before they can automate anything against them, and most clients have never written those rules down. The playbook sets that expectation before we write a single line of code.

Friday: Internal Focus

By Friday, the client calls slow down and the internal work ramps up. This is when we do team syncs, retrospectives, and product feedback sessions. The things that matter for the long term but get squeezed out when client work is intense.

The product feedback loop is one of the parts of this job I find most valuable. When you’re implementing the same patterns across multiple clients, you start to see what should be abstracted into the platform. I spend time with our product team talking through which primitives we keep building from scratch, because that usually means they should exist as features we configure instead of code we write every time. The interesting half of that conversation is the inverse: which patterns look repeatable but actually shouldn’t be productised, because the edge cases between clients are larger than the shared core. Knowing the difference is the part of the job you can only learn by sitting across many implementations at once.

What This Role Actually Requires

Looking at a typical week, a few things stand out.

First, you have to be comfortable with chaos. Ten clients, different tools, different stages, different problems, constant context-switching. If you need long stretches of uninterrupted focus to be productive, this role will break you.

Second, the technical work is real but fragmented. You’re not spending eight hours a day writing code. You’re spending two hours here, four hours there, and the rest in conversations that shape what that code needs to do. Coding agents have shifted that ratio a bit, but they haven’t changed it fundamentally.

Third, the business side is unavoidable. If you just want to build things and not talk to people, this isn’t the role. Most of my week is communication. Translating requirements, managing expectations, navigating stakeholder dynamics.

Fourth, you carry full context. One FDE per client. There’s no handoff to a delivery team. What you scope is what you build. This is exhausting but also clarifying. You can’t overpromise because you’re the one who has to deliver.

The Honest Version

If I had to name the thing that defines this role, it’s this: the work is less about building AI systems and more about understanding businesses well enough to know what to build.

The technical skills matter. You need to be able to code, to understand how LLMs work, to debug systems under pressure. But the differentiator is pattern recognition across messy human organisations. Seeing what’s actually blocking a client, which is rarely what they say is blocking them. Knowing when to push back and when to just build what they asked for.

Every week is different. Every client is different. The only constant is that my carefully planned Tuesday deep work block will probably get interrupted by something.

That’s the job.

I would like to extend a big thank you to for sharing his insights with Big Tech Careers readers.

I encourage you to subscribe to his newsletter, , to learn more about the FDE role.

AI-Powered Big Tech Interview Prep for Tech ICs and Leaders

While everything I share in this newsletter is free, if you'd prefer the material in a structured course format — with a deep dive into behavioural interview preparation — I'm running a 1-day Big Tech Interview Workshop. Newsletter readers get an exclusive 30% discount.

Check out 1-day interview prep workshop

In this week’s article, I share the report of the recent BeSA Q1 2026 cohort we completed on Agentic AI on AWS. It includes the exact report we sent to our leadership.

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

After every customer event, we send out an internal Trip Report. BeSA is more of a community event — but given the scale and impact of the Q1 2026 Cohort on Agentic AI on AWS, we felt it deserved one too.

This cohort had some standout moments: free hands-on workshop environments for thousands of participants every week, and community volunteers who stepped up to help people get through the workshops.

What really moved us, though, were the participant quotes like:

• “Mastered Agentic AI from Kenya.”

• “The BeSA program made me realize how capable I am.”

• “I’m ill with fever but still not missing this for the world.”

• “This program gave me a lot of motivation during a tough time.”

Below is the Trip Report we shared with our teams and leadership.

About BeSA

BeSA (Become a Solutions Architect) is a free, community-driven 6-week mentoring program run by AWS professionals that helps aspiring cloud practitioners develop both the technical and behavioral skills needed to excel in their cloud and AI career journey. Since its inception in 2022, BeSA has trained 23,000+ learners across 9 cohorts through live-streamed sessions featuring presentations, role-plays, hands-on workshops, and guest speakers from across the industry. The program is live streamed every Saturday, and all sessions are recorded and posted on the BeSA YouTube channel.

Cohort Details and Statistics

Program: BeSA (Become a Solutions Architect) Cohort 9

Total registration: 10,895

• Personal Learning: 5,727 (52.6%)

• AWS Customer: 1,497 (13.7%)

• AWS Partner: 1,453 (13.3%)

• AWS/Amazon Employees: 369 (3.4%)

• Potential AWS customer: 415 (3.8%)

• Others: 1,434 (13.2%)

Topics covered:

• Technical Track: Agentic AI on AWS

• Behavioral Track: Developing the SA Mindset in the AI Era

• Hands-on Track: Level 200/300 AWS workshops on Amazon Bedrock, Strands Agents, Bedrock AgentCore, MCP and Kiro

Logistics:

• Dates: February 21 - March 28, 2026

• Livestream time: 3:00 PM - 5:00 PM GMT (every Saturday)

• Workshop access duration: 24 hours over the weekends

• Platform: YouTube Livestream + Discord + AWS Workshop Studio (Hands-On Labs)

Participation engagement:

• Total YouTube views: 98,500+ (as of 5^th April 2026)

• Total badges claimed: 7,485

• Total Workshops completed: 6136

Weekly Agenda and Statistics:

What Worked Well

• The Agentic AI theme was timely and resonated strongly with participants

• The role-play session format of interaction between an AWS expert and customer was appreciated— the customer voice represented the audience, making it easy to relate to

• Technical, behavioural, and hands-on tracks gave participants the depth they needed to understand what to build, why it matters, and how to approach it

• Hands-on AWS Workshop Studio labs gave participants real-world experience building agentic AI applications on AWS. A live pre-workshop overview and recorded walkthrough helped everyone navigate the workshops with confidence

• The virtual format enabled global participation across different time zones, with multiple workshop slots to accommodate different regions

• This cohort, we also welcomed community volunteers from around the world to support participants on Discord. By the end of the cohort, we had 40+ volunteers who helped in keeping this community self-sufficient and thriving

• Live Q&A and chat support on YouTube, backed by AWS volunteers and an active Discord community, provided real-time answers and peer support throughout the workshops

• Post-session knowledge checks and digital badges helped reinforce key concepts — and participants were proud to share their credentials on LinkedIn

• Our partnership with Whizlabs offered complementary structured learning and free AWS Generative AI labs to extend the experience beyond the sessions

What Can be Improved

• Workshop access duration can be increased. Participants requested access to workshops on weekdays as well, since committing to 6 consecutive weekends for hands-on workshops can be difficult

• Consolidate the different platforms used for registrations, hands-on workshops, knowledge checks, chat support, email, and badges into one cohesive experience

• Engage the community and keep it active after the BeSA cohort ends

• Make the BeSA Badges and Certificate credible and verifiable on platforms like Credly

• Continue providing access to Whizlabs learning resources after the batch ends

• Expand reach of BeSA on social media platforms beyond LinkedIn

Participant Quotes and Feedback

AI Generated Summary – “From the very first session, participants made clear that BeSA Batch 09 was something special. The overwhelming sentiment throughout was one of gratitude, inspiration, and genuine connection — remarkable for a free volunteer-run program delivered entirely over YouTube Live. Participants consistently praised the role-play teaching format as the program’s defining strength. Rather than traditional lectures, BeSA paired technical presenters with co-hosts who played customer or SA roles, creating dynamic conversations that made complex Agentic AI concepts feel tangible and relatable. As one participant put it, “Always liked the dialogue mode of presenting than monologue” The volunteer team’s dedication was the most emotionally resonant theme across all six weeks. Participants were visible moved that AWS employees were donating their weekends to deliver high-quality , free training at global scale. Comments like “Not all heroes wear capes,” and “You all give your 200% and even giving away all these for FREE — just mind blowing” appeared weekly .

The impact extended well beyond technical upskilling, with participants sharing powerful personal testimonials — from “Mastered Agentic AI from Kenya” to “The BESA program made me realize how capable I am” — while emotional investment deepened each week, evolving from Week 1’s excited curiosity (”I am ill with fever but still not going to miss this for the world”) to Week 6’s heartfelt farewells (”This program gave me lot of motivation in tough time,” “Missing these energetic Saturday mornings,” and “Your dedication and compromise to share your knowledge has no price”). The strongest sentiment signal came not from praise but from action — participants organically forming study groups across countries, requesting BeSA T-shirts as community identity, and repeatedly asking “When is the next cohort?” and “How do I volunteer?” — confirming that BeSA had built not just a training program but a lasting global community that participants don’t want to leave.”

• “From Foundations of AI Agents to Building with Agentic AI, I gained hands-on exposure to designing intelligent systems. One of the most valuable parts of this program was the hands-on sessions, which made a huge difference in truly understanding the concepts and applying them in real-world scenarios. Looking forward to applying these learnings to build scalable, intelligent, and impactful AI-driven solutions.” - Chaitali Kayastha, Software Engineer, JP Morgan Chase

• “I am truly amazed by the impact you have had on the community. I have never witnessed such dedication or such a high-quality program made available to professionals at no cost. This is a truly selfless act, and the one word that comes to mind is simply: Gratitude.” - Jaypal Baviskar, Solutions Architect, Cisco

• “This wasn’t your run of the mill webinar series, it was a three-track program that focused on; technical deep dives, the Solutions Architect’s mindset, and weekly hands-on labs, all led by tenured AWS practitioners. I loved the opportunity to build, break things, debug, and then build again” - Paul Madojutimi, Technical Project Manager, Apple

• “I just completed 6 weeks of Agentic AI on AWS with the BeSA program — led by Amazonians. What made BeSA different: Each week ended with a hands-on workshop — of actually building and deploying on AWS. That’s what made concepts stick, role-play learning with AWS experts making complex concepts tangible, a global cohort, thoughtful mentors, and zero cost to participants” - Inderpal Singh, Cloud Architect, Accenture

• “I have been to many workshop and registered for many courses but was not able to build rapo/ professional relationship. BeSA stands tall with the content, vocabulary and no toy projects. Great Job by entire BeSA team for putting for all your effort with content” - Ashok Vaddepally, Senior Cloud Devops Engineer, CGI

• “I found myself shifting from a developer mindset focused on “How do I build this?” to thinking like an architect asking “Why should this be built this way?” and “What if we approached it differently?” - Neetika Yadav, Senior Power Engineer, Transport for London

• “Over the past 6 weeks, I had the opportunity to complete an outstanding program on Agentic AI, led by senior AWS architects. It stands out as one of the most well-structured programs among leading hyperscalers, taking me from conceptual understanding to hands-on building with AWS Bedrock, Strands, AgentCore, MCP, and Kiro spec-driven development. With 12 hours of live sessions and ~50 hours of AWS resources provisioned for hands-on practice, the program blends solution architecture learning with the behavioral mindset required to design, build, and operationalize Agentic systems at scale in enterprise environments.” - Anand Parthasarathy, Sr. Technology Delivery Lead, Accenture

• “I thought I was learning how to build AI agents… but somewhere in those 6 weeks, the real transformation happened — I started thinking like an architect, not just a developer.” - Guru Ganesh Chintalapudi, SDE-3 ZF Tech

Special Thanks and Recognitions

AWS Leadership Support

• Rohan Karmarkar (Director, Partner Technology) for the sponsorship and support.

• Roland Barcia (Director, Specialist SA and Tech) for approval to use workshop studio for the community and also for the keynote fireside chat.

• Swami Sivasubramanian (VP, AWS AI) for recording a welcome video to kickstart the cohort and promoting BeSA on X

• Jeff Barr (VP, AWS Evangelism), Ruba Borno (VP, AWS Specialists & Partners), Julia Chen (VP, AWS Partner Core) for the support and sharing about BeSA on LinkedIn. Helped us to get 10,000+ registrations.

Cohort 9 Volunteers

Jeff Escott, Aanchal Agrawal, Nisha Dekhtawala, Raj Menon, Dr. Anil Kumar Giri, Kavya Sidda, Anmol Katakwar, Chris Poole, Laura Smith, Kavya Gopi, Bhaskar Pathak, Santosh Setty, Thomas Utsey, Asheesh Pandey, Vijender Singh

Workshop Studio, Service team and workshop owners

• AWS Workshop Studio Team — <names redacted>

• Amazon Bedrock Team — <names redacted>

• Nova Pro Team — <names redacted>

• Kiro Team — <names redacted>

• Workshop owners - <names redacted>

Core Team Members

Parna Mehta, Ashish Prajapati, Prasad Rao

What’s Next

• Make the Agentic AI on AWS cohort self-service for the community.

• The next cohort of BeSA will be planned for Q3 2026.

• Incorporate the feedback to consolidate different platforms to simplify the experience.

• Scale to 20,000 participants for the next cohort.

- BeSA Core Team
[Parna Mehta, Ashish Prajapati, Prasad Rao]

That was the Trip Report — but we also want to take a moment to thank a few people and platforms who made this possible.

TechCreator.io

Hosting BeSA on ’s TechCreator platform was a game-changer for us. It handled our weekly knowledge checks, gave out badges to everyone who passed, and issued certificates at the end of the six-week cohort. The result? Hundreds of people proudly sharing their badges on LinkedIn every week.

We’re taking this further — the Agentic AI on AWS cohort will soon be fully self-serve on TechCreator. Participants will be able to register, enroll, watch videos, complete knowledge checks, and claim their badges and certificates, all in one place. There’ll also be a Discord channel for the community to connect and get questions answered. And yes — it’ll all be free.

Thank you, for offering the platform at no cost and helping us make such a big impact. 🙏

Whizlabs

I first met Whizlabs CEO Krishna Srinivasan last year at re:Invent, though we’d been exchanging emails for over a year — so the in-person meetup was long overdue. When I told him about the cohort we were planning, he didn’t hesitate. He talked about how passionate he is about building community, and offered free access to Whizlabs’ Amazon Bedrock course and labs for all BeSA participants — committing to 10,000+ people.

One of the best signs of how good the platform was? Participants kept asking for extended access even after the cohort ended.

Thank you, Krishna. 🙏

Community Volunteers

Week 1 gave us the kind of problem everyone hopes for — things breaking because the interest was far beyond what we expected. We had committed to 24-hour workshop coverage, but supporting 1,000+ people at once was something we hadn’t planned for. We had around five volunteers lined up, but ended up pulling an all-nighter just to keep up with the non-stop questions pouring in on Discord. By the time it was over, we knew we needed to scale volunteers 10x before the next week.

And that’s exactly what happened. The community rose to the occasion.

The BeSA community volunteer success belongs to 40+ of them.

40+ volunteers. 1,000+ participants. 24 hours of workshop coverage. Every single weekend.

They were BeSA participants themselves — people who had done the workshops, worked through the hard parts, and figured things out. And then turned around and helped others do the same. On their weekends. On their own time. With zero obligation.

Running a completely free cohort on Agentic AI for thousands of people would simply not have been possible without them.

Thank you. Each and every one of you. 🙏💙

This week I bring you a guest post from Sarvesh Talele, AI Engineer at TCS! He shares how he prepared and passed Claude Architect Certification in 5 days. Follow him on LinkedIn for more tips on working with Claude.

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

Couple of weeks ago, I shared my Preparation Roadmap for the Claude Certified Architect Certification. It kind of went viral. 🚀

Two things happened:

• A flood of comments and DMs thanking me for the roadmap

• Early adopters sharing that they’d already passed the exam

That got me thinking — why just hear from me, when you can hear from someone who’s actually done it?

In this article, Sarvesh, who passed the Certification within a week of its launch, will break down:

• The exact system they used to prepare

• How prior Claude experience shaped their approach

• A step-by-step framework you can follow

This is the kind of insider insight you won’t find in official docs.

A quick note before we dive in: Sarvesh cleared the exam in 5 days because he has hands-on experience with Claude and works with it on a daily basis. If you are someone starting fresh, take the framework below as a 5-week program rather than a 5-day one.

Your mileage may vary depending on your skill level — it may take 2 weeks for some and 10 weeks for others. Choose the pace you’re comfortable with and focus on gaining the knowledge and hands-on experience.

Now, over to you, Sarvesh!

A Bit About Where I’m Coming From

I spent 3.7 years building AI solutions at TCS. During this time, I worked across the full stack of practical AI engineering, including designing retrieval pipelines, building production grade multi agent systems, and delivering production integrations using Azure, LangChain, MCP, and Claude. Claude is now my primary tool for building, debugging, prototyping, and shaping architecture decisions in live client work.

When Anthropic announced the Claude Certified Architect Foundations certification on March 12, 2026, I approached it with extensive hands-on experience rather than as a beginner. I had already used Claude intensively and wanted to identify gaps in my understanding. That context matters because it directly influences how realistic a five day preparation timeline is for you.

I passed the exam, and this is the exact system I followed.

The Thing Most People Get Wrong Before They Even Start

When a new certification appears, most people begin with reading. They review the exam guide, study documentation, read blog posts, build detailed notes, and move through content with a steady sense of progress.

That approach alone won’t get you to a 720 score on this exam.

The Claude Certified Architect exam centers on one core skill: selecting the right architectural decision when three of the four options seem valid. The incorrect choices appear reasonable and often reflect what a strong engineer might choose in a slightly different context. The exam targets the gap between understanding a concept and applying it correctly under pressure when multiple answers feel defensible.

Reading alone does not bridge that gap. Practice does, especially when it includes immediate and precise feedback that shows exactly how and why an answer missed the mark.

This principle shaped the system I built.

Three Modes, One Tool, Five Days

Before I describe the system, here is the honest picture on time spent. Across the five days, I invested roughly 35 to 40 hours of focused preparation. That breaks down to roughly 8 hours on days one and two, 7 hours on day three, 9 hours on day four, and 6 hours on day five including the mock exam and targeted drilling.

If you are new to developing with Claude, plan for a longer duration based on your skillset and bandwidth. The approach outlined here works at any starting level though the timeline might vary.

I built three system prompts, each putting Claude into a different mode for a different stage of preparation. Setup instructions at the end of the article.

The first mode acts as a learning coach - Claude reads the exam guide before responding, explains each concept using three rules, pauses to confirm understanding, and links every concept to its domain and task. Commands control the flow.

The second mode acts as a practice coach - It creates new questions, applies a strict format where each incorrect option matches a distractor type, evaluates answers with clear reasoning steps, and tracks performance and weak areas.

The third mode acts as mock test - It selects four scenarios, assigns questions based on domain weight, shows one question at a time, and provides results only after you submit. The experience mirrors the real exam and builds test readiness.

The system runs within one Claude project. Upload the exam guide once, and all modes will use it across sessions. I'll first explain how I used it over 5 days to pass the exam, and then walk you through how you can set it up for your own preparation.

Day One and Two: Build the Foundation

The exam guide defines five domains, with Domain 1 accounting for 27 percent of the score. It carries the highest weight and is often underestimated. The focus extends beyond using Claude to designing systems that operate reliably at scale.

I spent the first two days on the Anthropic Academy website. All courses are free and include a completion certificate.

I started with Claude 101 to organize my prior knowledge and identify misconceptions developed through daily practice.

Next, I completed AI Fluency: Framework and Foundations. This course introduces the 4D framework and builds the decision making model the exam evaluates. The focus shifts from defining concepts to selecting the right approach under constraints.

On day two, I worked through Building with the Claude API. The course covers authentication, multi turn interactions, system prompts, tool usage, context management, and architecture patterns. Domains 1, 4, and 5 rely heavily on this material.

Along with the courses, I utilized teaching mode and $learn commands. Each topic was promptly reinforced with organized explanations, annotated code examples, and decision analysis.

This integrated loop of organized learning and guided coaching shortened a two-week procedure to two concentrated days.

Day Three: MCP and Claude Code

Day three covered the two domains most people either skip or underestimate.

Domain 2 is an overview of Introduction to Model Context Protocol and Advanced Topics. The main takeaway is straightforward but important: tool selection is determined by how effectively the tools are described. When descriptions are unclear, Claude makes inexperienced choices, which show up in both production systems and on the exam.

These courses sharpen that edge. They demonstrate what strong tool descriptions look like and how accuracy directly improves dependability.

Domain 3 explains Claude Code in Action and Introduction to Agent Skills.

You move beyond basic usage to structure and control. CLAUDE.md hierarchies, path-specific rules, custom commands, scoped skills, and CI processes become part of your thinking, in addition to your tools. These patterns emerge instantly in exam scenarios, and any informal understanding clearly shows limitations.

By the end of day three, I had switched to teaching mode with $domain 2 and $domain 3. The coach divided each domain into task statements, key knowledge points, and essential skills, and then compared everything to real-world code examples from the guide.

That shift changed how I saw the exam. Questions stopped feeling random. Patterns became visible before they appeared.

Day Four: Practice Until the Patterns Become Automatic

During the examination, a clear pattern is observed. The questions look different on the surface, yet they continually test the same fundamental errors in architectural judgment. I identified eight recurring distractor patterns which are discussed below:

• The first is to depend on system prompt instructions to enforce important business logic in situations where a programmed gate is required.

• The second is adding few-shot examples when the root cause is a tool description that is too minimal.

• The third is over-engineering a solution, reaching for a classifier or ML system before the simpler architectural fix has been tried.

• The fourth is escalating based on sentiment when the actual trigger should be explicit policy gaps or the customer’s own stated preference.

• The fifth is giving an agent more than four or five tools, which degrades selection reliability. The sixth is using the Message Batches API for a blocking workflow that cannot tolerate a 24-hour processing window.

• The seventh is self-review, asking the same session that generated the code to also review it, when an independent instance without prior reasoning context is what accuracy requires. The eighth is checking text content to determine whether the agentic loop should stop when `stop_reason` is the correct and only signal.

These patterns display what the test is truly looking for: exact architectural judgment when there is variability.

Day Five: The Mock Exam and What It Reveals

On day five, I used $mocktest standard in exam mode. Twenty-four questions. Four random situations. No suggestions, feedback, or advice until $submit.

The report that followed became the most valuable output from the entire process.

It displayed my estimated score, highlighted my strong and weak areas, and identified the distractor pattern I used the most frequently. Each question included the proper answer, the trap I chose, and a clear thinking process.

Domain 5, Context Management and Reliability, came out as my weakest point. The exam assesses the “lost in the middle” effect, in which models perform well at the beginning and finish of inputs but lose features in the middle of them. I understood the concept but lacked experience implementing it in real-world circumstances for context management. The simulated test revealed that gap.

I spent the afternoon drilling Domain 5 with $drill 5 and reinforcing it through $review context management until the pattern became instinctive.

The next morning, I scored 911 in the Claude Architect Exam.

Reflections After the Exam

The scenarios have more complexity than practice questions can express. Constraints are distributed throughout multiple phrases, with the most significant details frequently located in the middle. Reading too rapidly makes the correct answer feel incorrect. I slowed down after the first few questions when a pattern became crystal clear.

Production experience was quite beneficial. Tradeoff questions were familiar since they correlated scenarios I had already encountered. When deciding whether to batch or stream in a latency sensitive pipeline, I relied on real-world failures rather than theory. That type of foundation is tough to establish via reading and memorising alone.

The exam rewards meticulous thinking. I used almost all of the given time. Speed provides no benefit, but meticulous reasoning typically results in superior decisions. Overall, the exam seemed noteworthy. It rewards an in-depth understanding of how Claude acts at the system level, which extends beyond prompt engineering.

Setup Claude Project to prepare for exam:

Overview:

The three coaching prompts are designed to live inside a single Claude Project. Here is how to set them up.

• Step 1: Go to Claude.ai and create a new Project. Name it something like “CCA Exam Prep.”

• Step 2: Upload the official exam guide PDF to the Project’s knowledge base. This is the document all three prompts reference when teaching concepts or generating questions. Once it is uploaded, you do not need to re-upload it across sessions.

• Step 3: Paste each of the three system prompts into the Project instructions. The prompts are available here.

You switch between Learning Mode, Practice Mode, and Mock Test Mode by using the corresponding commands in the chat. All commands begin with $ to keep them distinct from normal questions.

Learning Mode

• $overview—full domain map with weightings and study order

• $domain [1–5]—every task statement in that domain with code anchors

• $scenario [1–6]—step-by-step deep-dive with pauses for confirmation

• $learn [topic] — single concept taught through the 3 master rules

• $explain [concept]—senior engineer explanation with before/after code

• $compare [A] vs [B] — side-by-side table with distractor class callout

Practice Mode:

• $practice [1–6]—3 questions on a specific scenario, graded one at a time

• $drill [1–5]—5 rapid-fire questions across a domain, score at the end

• $hard [topic] — 1 question where all 3 wrong options are architecturally valid

• $blind—2 questions with hidden scenario (true exam simulation)

• $traps—1 question per distractor class, train recognition under pressure

• $review [topic] — 2 questions targeting the most commonly missed concept

Mock Test Mode:

• $mocktest short — 12 questions, ~15 min

• $mocktest standard—24 questions, ~30 min

• $mocktest full—48 questions, ~60 min

• $submit—end the test and reveal the full diagnostic report

• $review Q[n]—revisit any question after submission

• $pause / $resume—save and continue

Check the detailed steps and in case you get stuck in the set up, feel free reach out to me over LinkedIn.

Prasad here again 👋

I would like to extend a big thank you to Sarvesh for sharing his insights with Big Tech Careers readers. Follow him on LinkedIn for more tips on working with Claude which he shares regularly.

Big Tech Interview Preparation Course

While I share everything for free here in this newsletter, if you need all the material in a structured course format with a deep dive into preparation methodology for behavioral interviews, I have a self-paced course for you.

Check the course page for more details.

Enroll for Interview Preparation Course