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

Last week, Shola shared his journey from Agricultural Economics to AWS Solutions Architect. This week, the part everyone wants to know. How he became an AWSome Legend, AWS’s highest recognition, awarded to only 120 people globally.

Shola story is about struggle, about being invisible despite doing great work, and about the uncomfortable decision to make your impact impossible to ignore.

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

Over to you, Shola!

The Award Nobody Plans For

When I joined AWS, I did not know this award existed. And honestly, I was not in any position to think about awards.

I joined as a Solutions Architect with zero AWS experience. None. My background was in .NET and Microsoft workloads. I had an Economics and Finance degree. Before AWS, I was working at the NHS. And before that, I was in Nigeria studying agricultural economics.

So when I walked into my first week at AWS, I did not feel like I belonged.

People around me were dropping service names I had never heard of. They were drawing architecture diagrams from memory. They had been building on AWS for years. I was Googling what an S3 bucket was.

The imposter syndrome was not a phase. It was a daily companion. Every customer call, I would prepare for two hours just to sound competent for thirty minutes. Every internal meeting, I stayed quiet unless I was certain. Every time a colleague casually referenced a service, I would write it down and study it that evening.

Nobody talks about this part. The part where you are technically in the room, but you feel like you are behind a glass wall watching everyone else do the job you were hired to do.

That lasted months.

The Gap Nobody Talks About

Here is what I wish someone had told me when I started: doing great work is not the same as being recognised for great work.

After about 18 months, I had found my rhythm. I was comfortable with customers. I was closing deals. I had already earned two quarterly recognition awards. By every internal metric, I was performing.

But I also noticed something. Other people who were doing comparable work were getting more visibility. Not because they were better. But because they were more intentional about making their work visible.

I would solve a critical customer problem on a Tuesday and forget to document it by Friday. I would deliver a workshop that got excellent feedback and never tell anyone except the customer. I would create a reusable framework and share it on Slack, where it disappeared into the scroll within a day.

Sound familiar?

Most of us work this way. We believe the work should speak for itself. And in theory, it should. But in a large global organisation, the work does not speak. You have to speak for it.

That was the first uncomfortable realisation.

The Shift From Tasks to Outcomes

The second realisation was about how I was measuring my own work.

Most of us are trained to measure ourselves by effort. Hours worked. Projects delivered. Meetings attended. But that is not how recognition works at a company like Amazon. Recognition comes from owning the result: the business problem solved, the metric changed, the customer impact created.

Here is the framework that changed everything:

1. What business problem are we solving?

Not: “I am building an architecture.” But: “This customer is losing revenue because their system cannot scale during peak hours. That is the problem.”

2. What metric changes if this works?

Not: “I deployed a solution.” But: “Their deployment time dropped by 40%. Their infrastructure costs decreased by 30%.”

3. What did we ship, and what improved?

The before and after. The evidence. Not: “I helped with a migration.” But: “We migrated dozens of workloads, automated infrastructure pipelines, and freed up hundreds of hours of manual work per quarter.”

4. Who can confirm the impact?

This is the part most people skip. You need witnesses. Customer testimonials. Manager confirmation. Internal stakeholders who saw the result. If nobody else can vouch for it, it did not happen.

I applied this framework to every customer engagement. Every technical crisis. Every project I owned. And I documented it as I went, not months later when I was trying to remember what happened.

The Customer Moment That Mattered

Let me give you a real example of what this looked like in practice.

A customer hit a critical issue that put a significant engagement at risk. It was the kind of problem where most people would escalate to the relevant service team and wait for a response.

I did escalate. But I did not wait.

I spent nearly two weeks embedded in the problem. Not just coordinating. Actually digging in. Working directly with the customer. Pulling together internal teams that do not normally collaborate. Going back and forth until we found a resolution.

But I did not stop there. I worked with the service team to make the fix permanent, so that other customers would never hit the same issue. What started as one customer’s problem became a lasting improvement.

That is the difference between doing your job and creating impact. Solving a problem is expected. Making sure nobody else hits the same wall? That is what gets remembered.

And I documented every step of it. Because I had learned: if you do not write it down, it did not happen.

Building in Public (When Nobody Was Watching)

The other dimension of my work that made a difference was content.

When I started posting on LinkedIn about AWS, I had maybe 100 followers. Nobody was reading. Nobody cared. I posted about certifications, about cloud concepts, about what I was learning. It felt like shouting into a void.

I kept going.

Over the next two years, something compounded. 25,000 followers. Millions of impressions. Posts that drove real, trackable traffic to AWS. One post led to a senior leader at a company reaching out through a LinkedIn DM, which turned into a real customer conversation.

What made this count was not the vanity metrics. It was that the impact was measurable. I could show how many people engaged with AWS because of my content. Not “I think my posts help” — actual numbers, actual outcomes.

That is not “I post on LinkedIn.” That is “I built a content engine that drives measurable business value.”

The difference? Documentation. Measurement. Intentionality.

Writing My Own Case

Now here is the part that made me most uncomfortable.

When the time came for my nomination, I did not wait for someone else to write it. I treated it the way I would treat any important career document. I wrote a detailed case for why my work mattered.

Pages of evidence. Customer stories with outcomes. Content metrics. Speaking engagements with feedback. Reusable frameworks that other Solutions Architects had adopted.

Then I went to two senior leaders — people I had built relationships with over the previous year — and asked them to support it.

That was terrifying. Not because they said no. They said yes immediately. It was terrifying because I had to ask. I had to say: “I believe my work deserves this recognition, and here is the evidence.”

Most people will never do this. Not because they do not deserve it. But because self-advocacy feels arrogant. It feels like you are being too much. It feels safer to wait and hope someone notices.

Nobody noticed until I made it impossible not to.

After that, the process took its course. I did not hear anything for weeks. You do not get updates. You do not get told whether it is progressing or not.

You just wait.

Seattle

In February 2026, I flew to Seattle.

When I got there, I met the other 119 Amazonians who had received the same honour. I sat with AWS leadership: VPs, the CEO. People who make company-wide decisions. And I had a moment of: Seven years ago, I was in Nigeria studying agricultural economics. How is this real?

With AWS CEO Matt Garman at The Spheres, Seattle

That experience taught me five things:

1. Consistency beats talent. Nobody in that room was there because of one brilliant moment. We were there because of what we had done repeatedly, week after week, month after month. The work compounds.

2. Teach everything you know. The common thread across every person in that room: they were not gatekeeping. They shared what they learned. They mentored others. They built in public.

3. Build in public. Every single person I talked to had a presence beyond their day job. LinkedIn. Blogs. Speaking. Community involvement. Because they understood that your work only matters if people know about it.

4. Your story is your superpower. In a room full of brilliant engineers and architects, what set people apart was the clarity with which they could tell the story of why it mattered.

5. Imposter syndrome never leaves. I sat next to a VP and asked them: ‘Does it ever feel normal?’ They laughed. ‘No. Not once.’ The difference is the willingness to show up even when you do not feel ready.

The AWSome Legend Award — one of 120 globally

Why I Am Telling You This

I am not telling you this story because I want you to win an award.

I am telling you because the system I used — documenting impact, building in public, measuring outcomes, writing my own case, asking for what I wanted — is the same system that works for promotions. For job offers. For career transitions. For any moment where you need someone to see your value.

And most people never do it. Not because they cannot. But because nobody told them they were allowed to.

So here is your permission.

You are allowed to document your wins. You are allowed to tell people what you have accomplished. You are allowed to write your own case and hand it to someone and say: “This is what I have done. I believe it matters.”

You are allowed to be intentional about your career in a way that feels uncomfortable at first.

I started with a degree that had nothing to do with technology. I started at the NHS with no cloud experience. I started at AWS with zero certifications. I started posting on LinkedIn when nobody was reading.

Every single time, I did not feel ready.

Every single time, I showed up anyway.

And that is the real story behind the award.

Prasad here again 👋

Two-part story from Shola. From agricultural economics to AWS Solutions Architect to AWSome Legend.

What struck me most? It was not the award. It was the two weeks he spent embedded in a customer crisis when he could have just escalated and waited. It was the discomfort of writing his own case and asking senior leaders to back it. It was posting on LinkedIn when he had 100 followers and nobody was reading.

That is what intentionality actually looks like.

If you are working on building your own impact, here is how to connect with Shola:

🎯 Free resource: Roadmap to Your First Tech Job — sholastechnotes.com/roadmap-first-tech-job

📬 Stay connected: Shola’s Tech Notes — sholastechnotes.com

Thanks for reading, and I will catch you next week.

I have been wanting to bring you this story for a while. Shola studied Agricultural Economics in Nigeria, came to the UK with zero tech background, and is now an Enterprise Solutions Architect team at AWS. Oh, and he recently became an AWSome Legend — one of only 120 people globally to receive that recognition.

This is Part 1 of a two-part series. Today: the journey. Next week: the intentionality behind the award.

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

Over to you, Shola!

I Studied Agricultural Economics

I did not grow up thinking about technology. I grew up in Nigeria, where the practical choice seemed to be a degree in something tangible — something that would translate directly into employment. I chose Agricultural Economics at the University of Ibadan. I was good at it. I understood systems, resource allocation, the logic of how inputs become outputs. But I knew, somewhere in the back of my mind, that it was not where I was going to build my career.

I had no plan for what would come next. I just knew I needed to keep moving forward.

Moving to the UK With No Tech Background

When I moved to the UK to pursue my master’s degree — an MSc in International Business — I arrived without a network, without a clear career path, and without any formal technology training. What I had was curiosity and a willingness to figure things out.

A lot of people underestimate how disorienting that phase is. You are in a new country, building from scratch, trying to understand a job market that was not designed with your background in mind. I spent a lot of time just observing — watching what skills employers actually wanted, what roles seemed to have longevity, and where the real opportunities were.

That observation period was not wasted time. It shaped everything that came after.

Discovering Data Analytics by Accident

My first real exposure to technology came through a role that had nothing to do with software engineering. I was working in a support function, and I started noticing that a lot of the decisions being made around me were based on data — but the data was messy, inconsistently tracked, and hard to interpret.

I started teaching myself Excel. Then SQL. Then Power BI. Not because anyone told me to, but because I could see the problem in front of me and I wanted to solve it. That is still how I approach most things — find the problem, then find the tool, not the other way around.

What I did not fully appreciate at the time was that this was a pivot. I was not just learning a tool. I was entering the technology industry through a side door.

Growing at NHS England

Eventually, I joined NHS England. Working in one of the largest health systems in the world gave me a perspective I could not have got anywhere else. The scale, the complexity, the stakes — it changes how you think about technology. You are not building for convenience. You are building for continuity.

I was working with data at scale — population health data, operational data, strategic reporting for national leadership. The work forced me to develop skills I did not know I needed: stakeholder communication, translating technical findings for non-technical audiences, operating under pressure.

But I also started to see the ceiling. Data analytics got me in the door. Cloud was where the industry was heading.

The Shift to Cloud Computing

I made a deliberate decision to move into cloud. I started with certifications — not because I believed certifications alone would get me hired, but because they gave me a structured framework for learning something I had no formal training in.

The AWS Cloud Practitioner was my first. Then the Solutions Architect Associate. I kept going. Over time, I accumulated nine cloud certifications — five AWS, four Azure. But the certifications were never the point. They were the on-ramp. The real learning happened when I started applying what I had studied to actual problems at work.

That combination — certifications to build the framework, real projects to build the depth — is what actually moved my career forward.

The Secondment That Changed Everything

The turning point came when I had the opportunity to take a secondment into a cloud architecture role. I almost did not apply. I did not feel fully ready. I did not have all the experience the role description asked for.

I applied anyway.

That secondment gave me direct exposure to cloud architecture at an enterprise level. I was working on real infrastructure decisions, real migrations, real trade-offs. I was in rooms where senior technical decisions were being made and I was expected to contribute.

That experience is what allowed me to make the leap to a cloud provider. Not because I had a perfect CV, but because I had done the work in a context that made the experience legible to a new employer.

Deciding to Work for a Cloud Provider

At a certain point, I realised that if I wanted to deeply understand cloud — not just use it, but truly understand how it is architected and where it is going — I needed to be on the inside. I needed to work for one of the providers.

That was not a small decision. The jump from a large public sector organisation to a hyperscaler is significant. The interview process is different. The expectations are different. The culture is different.

But I had spent years building both the technical depth and the ability to communicate it. Those two things together — being able to do the work and explain the work — are what get you through the door at a company like AWS.

Landing at AWS With Zero AWS Experience

Here is the part that surprises most people: when I joined AWS, I had no professional experience using AWS in a commercial context. Everything I knew had been built through self-study, certifications, and a relatively brief secondment.

I want to say that clearly, because I think a lot of people assume you need years of hands-on cloud experience to land at a cloud provider. You do not. What you need is evidence that you can learn fast, think architecturally, and communicate complex ideas clearly.

The first year at AWS was one of the most intense learning experiences of my career. But I had been preparing for that intensity for years — not by accumulating experience in a straight line, but by consistently choosing to stretch into discomfort.

Building in Public

Alongside the career, I started sharing. LinkedIn posts, newsletter editions, practical guides for people trying to break into cloud or navigate career transitions. I built ResumeRadar — a free CV scanning tool that has now been used by over three thousand people. I mentor, I answer questions, I show up.

Building in public did something unexpected: it accelerated everything else. The clarity you develop when you try to explain something to someone else is unlike any other form of learning. It sharpens your thinking. It builds a network. It creates opportunities that you cannot manufacture through a CV alone.

I now have 24,000 followers on LinkedIn — not because I set out to become an influencer, but because I decided to share what I was learning in real time, with honesty.

What I Have Learned So Far

If I were to distil this journey into the things I actually believe — not the advice people expect, but the things that actually proved true — it would be this:

• Your background is not a limitation. It is a different angle. Agricultural Economics taught me systems thinking. That is exactly what cloud architecture requires. The non-linear path is not a liability — it is a lens.

• Ask before you are ready. I applied for the secondment before I felt qualified. I applied for AWS before I had every box ticked. Readiness is something you build during, not before.

• Certifications plus hands-on experience. Neither alone is enough. Certifications give you a map. Projects give you the territory. You need both.

• You do not have to do it alone. The people I have learned from, the communities I joined, the mentors who gave me an hour of their time — those relationships compounded over years.

• Start sharing before you feel ready. The clarity you develop when you try to explain something to someone else is unlike any other form of learning. It sharpens your thinking, builds your network, and creates inbound opportunities.

NEXT WEEK

I will share how I became an AWSome Legend — one of only 120 people globally to receive AWS’s highest recognition for community contribution.

Prasad here again 👋

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

I also encourage you to follow him on LinkedIn for further insights.

I hope you found Shola’s story as compelling as I did. The non-linear path — Economics degree to NHS to AWS — is a genuinely useful case study in how careers in tech are actually built, not how we imagine they are built.

Shola has put together two resources I want to make sure you know about:

FREE Roadmap to Your First Tech Job

A free guide covering the exact 4-phase framework Shola used to go from no tech background to a role in cloud. Domain selection, certifications, projects, personal brand — all mapped out.

→ Get the free roadmap

FREE TOOL ResumeRadar — Free CV Scanner

Shola built a free tool that scans your CV against job descriptions and tells you exactly where the gaps are. Over 3,000 people have already used it.

→ Try ResumeRadar free

In this week’s article, I share how to standout during technical interviews by sharing your experience and showcasing your behavioral skills.

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

When answering pure technical questions, if possible, extend with one of the following:

• Your work experience of when you have tackled that technical scenario

• If you do not have direct experience, talk about how you have learned about it or how you would approach it

Put simply, do not stop at just answering the technical question.

Add your authentic experience to stand out.

Let me start this section with a personal anecdote.

In one of my technical interview I was asked, “What is an Idempotent API?”

My response was in 3 steps:

1. Answered the technical question asked upfront

I explained what an Idempotent API is, showcasing my technical knowledge.

2. Shared my previous project where I implemented an idempotent API

I showcased my actual hands-on work experience without the interviewer even asking me.

3. Explained my project experience in STAR format

While explaining my project experience in STAR format, I also explained WHY the idempotent API was required in that scenario. I talked about how the APIs I built were reporting trades worth millions in real-time to regulators and the reason I had to implement them as idempotent.

This is where I showcased my behavioral skills. I demonstrated I understand the business impact of the technical solutions I build.

This article is based on a lesson from the course Ace Your Big Tech Interviews with Proven Strategies, which focuses on mastering the art of behavioral storytelling and effective communication for interviews with MAANG+ companies.

The Problem with Pure Technical Answers

Many candidates show off their technical knowledge in technical interviews, and most get the technical answers right.

Let’s say 10 people interview:

7 of them answered the technical questions correctly. You’re one of those 7. So why should the interviewer pick you?

You need to stand out.

How? By sharing your real-world experience and behavioral skills.

While technical answers showcase that you have knowledge, they don’t paint a complete picture of your ability to succeed in a role.

For example, all engineers know what an idempotent API is. But how many can connect it to their experience in an interview and share real-world examples to boost the interviewer’s confidence in their skills? You stand out from other candidates by showing your experience and behavioral skills while you answer technical questions.

This also ensures that your interviewer does not downlevel you.

Let’s look at a couple of common technical questions…

I’ll show you how to answer them in a way that also shows off your behavioral skills and experience.

Question: “What are microservices, and what are their advantages and disadvantages?”

Purely Technical Approach

“Microservices are an architectural style where an application is built as a collection of small, independent services. The advantages include scalability, flexibility, and easier maintenance. Disadvantages include increased complexity and potential performance overhead due to network communication.”

(This is just an example. You’ll have your own version of a technical answer with much more depth to it!)

Behavioral Skills Showcase Approach

After you provide the technical answer, add your personal experience to it.

“In fact, in one of my previous projects when I was consulting for a manufacturing company in 2022, I led a team that modernized our e-commerce platform by transitioning from a monolith to microservices.

We decided to make this shift because our monolithic application was becoming increasingly difficult to maintain and scale. For instance, deploying even small changes required testing the entire application, leading to a release cycle of 6 weeks.

To begin the transition, I initiated and facilitated an event storming session with stakeholders from development, operations, and business teams. This collaborative approach helped us identify natural service boundaries and ensured buy-in from all departments.

We started by extracting the product catalog service, as it was relatively self-contained. We faced several challenges, such as increased operational complexity and data consistency issues. I saw these as opportunities for the team to learn and grow. We invested time in upskilling, bringing in external experts for workshops on distributed systems and organizing internal knowledge-sharing sessions.

I’m happy to dive deep more into my experience. I’ve seen firsthand in this project the advantages of microservices and the challenges that come along with it.”

This response not only demonstrates technical knowledge but also showcases your experience and several behavioral skills:

• Leadership: Leading the modernization project

• Communication: Facilitating sessions with various stakeholders

• Problem-solving: Addressing challenges that arose during the transition

• Learning mindset and adaptability: Learning and applying new technologies

Now, let’s look into another question.

Question: “What factors would you consider when choosing between SQL and NoSQL databases?”

Purely Technical Approach:

“When choosing between SQL and NoSQL databases, several factors come into play.

Data structures are a primary consideration, with SQL being ideal for structured, relational data, while NoSQL is better suited for unstructured or semi-structured data.

Scalability needs often favor NoSQL, which typically scales horizontally more easily.

SQL databases offer stronger ACID compliance and excel at complex queries involving joins and transactions. However, NoSQL databases provide greater schema flexibility, allowing for more dynamic data models.

Performance requirements are also crucial, as NoSQL can offer faster read/write speeds for certain use cases.

Data consistency needs should be evaluated, with SQL providing immediate consistency and some NoSQL databases offering eventual consistency.

The choice ultimately depends on the specific requirements and constraints of the project at hand.”

This is a good answer and will probably make the cut. But as I mentioned, most candidates will be able to provide this level of answer. You need to strive to go above and beyond.

Behavioral Skills Showcase Approach:

I understand you cannot have work experience for every technical question asked in an interview. And that is absolutely fine. Complement the technical answer above with how you would approach such a scenario.

“To understand the requirements and constraints, I would organize a requirements gathering session with various stakeholders like the development team, product managers and, if possible, end-users. During this session, I would ask key questions such as:

• How structured is the data? Do we need a fixed schema or flexibility for evolving structures?

• What are our scalability requirements? What are the expected read/write ratios?

• Do we need strong consistency for all operations, or is eventual consistency acceptable for some data?

• What are our typical query patterns? Do we need complex joins and transactions?

• How frequently will our data model change?

Once we have these answers, I would analyze them in the context of ACID (Atomicity, Consistency, Isolation, Durability) properties typically associated with SQL databases, and BASE (Basically Available, Soft state, Eventually consistent) properties often seen in NoSQL systems.

I would also consider the CAP theorem (Consistency, Availability, Partition tolerance) which states that in a distributed system, you can only have two of these three guarantees.

And most modern systems often benefit from a polyglot persistence approach, using different databases for different purposes within the same application.

For example:

PostgreSQL for user accounts and financial transactions, where ACID properties were crucial. MongoDB for storing product catalogs with varying attributes. Redis for caching and real-time analytics

This decision cannot be made in isolation. I would consider trade-offs of each approach, challenge assumptions and provide alternative viewpoints.”

This response shows several behavioral skills:

• Analytical thinking: Systematically considering various factors

• Stakeholder management: Involving different teams in the decision-making process

• Communication: Organizing and facilitating requirements gathering and review sessions

• Decision-making: Weighing pros and cons to arrive at a solution

By answering technical questions in a way that showcases both your technical knowledge and behavioral skills, you present yourself as a well-rounded candidate who can not only do the job but also work effectively within a team and contribute to the company culture.

Companies are looking for more than just technical expertise. They want employees who can communicate effectively, work collaboratively, adapt to changing circumstances, and drive innovation.

So, as you prepare for your next technical interview, reflect not just on your technical accomplishments, but also on how you’ve demonstrated these crucial behavioral skills in your work.

Quick Recap

By answering technical questions in a way that showcases both your technical knowledge and behavioral skills, you present yourself as a well-rounded candidate who can not only do the job but also work effectively within a team and contribute to the company culture.

1. Go Beyond Technical Knowledge: While answering technical questions correctly is important, it’s often not enough to stand out among other qualified candidates.

2. Showcase Real-World Experience: After providing a technical answer, share relevant work experiences or projects where you’ve applied this knowledge.

3. Demonstrate Behavioral Skills: Use your answers to highlight important soft skills such as leadership, communication, problem-solving, and adaptability.

4. Connect Technical Solutions to Business Impact: Show that you understand how your technical decisions and implementations affect the broader business goals.

5. Approach Hypothetical Scenarios Comprehensively: Even if you lack direct experience, explain how you would approach a problem, considering stakeholders, requirements gathering, and decision-making processes.

6. Show Depth of Understanding: Discuss trade-offs, alternative approaches, and industry best practices to demonstrate a thorough grasp of the subject matter.

Companies are looking for more than just technical expertise. They want employees who can communicate effectively, work collaboratively, adapt to changing circumstances, and drive innovation.

So, as you prepare for your next technical interview, reflect not just on your technical accomplishments, but also on how you’ve demonstrated these crucial behavioral skills in your work.

If you found these insights valuable, you might benefit from the complete interview preparation system in my course Ace Your Big Tech Interviews with Proven Strategies. The course expands on these concepts with detailed frameworks for crafting compelling technical stories, mastering the STAR format, and communicating leadership experiences effectively. It includes practical exercises, real-world examples, and strategies specifically designed for securing roles at Big Tech companies. For more details, explore the full curriculum.

Check out the course page

Have questions? Send email at info@bigtechcareers.com

In this week’s article, I share advice from a Principal Architect on working smarter in the AI era.

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

As many of you might already know, we are in week 2 of the Become a Solutions Architect (BeSA) cohort on Agentic AI on AWS. As always, in BeSA we focus on both technical and behavioral skills. In this cohort, the theme of the behavioral skills track is "Develop an SA Mindset in the AI Era."

Glad to see the feedback from participants on the value of the behavioral track.

This week's article is based on a conversation between Raj Menon (roleplaying a Junior Architect) and Jeff Escot (roleplaying a Principal Architect) that took place in in the behavioral track last Saturday (starts at the 62-minute mark). Consider this as an advice from a Principal Architect on how to develop the Solutions Architect mindset in the AI era.

Let’s get started!

Consider how easy these days is creating an architect diagram. You open ChatGPT, type a few sentences, and 90 seconds later there’s a full three-tier cloud architecture on the screen. VPCs, subnets, load balancers, RDS. Clean. Polished. Ready to present.

For a lot of Solutions Architects, the demo like these trigger a quiet panic. If AI can do in 90 seconds what takes us a day and a half, what exactly are we here for?

The Architecture AI Can’t Draw

That 90-second diagram didn’t include the customer’s on-prem Oracle database that their team flatly refuses to migrate. Or the compliance requirement to keep all data in Frankfurt. Or the CTO who got burned by Lambda cold-starts two years ago and has had a thing against serverless ever since.

None of that is in a prompt. None of it ever will be.

Solutions Architects navigate the messy, political, budget-constrained, personality-driven reality of a specific customer at a specific moment. That’s the work AI genuinely cannot do.

Think about what happened when calculators arrived. Mathematicians didn’t disappear. The ones who only did arithmetic had a problem. The ones who understood why you solve certain equations, when to apply which model, and what the results actually mean became more valuable than ever. AI is the calculator. The question is whether you’re the architect who only does arithmetic, or the one who understands the math.

What a Real Engagement Looks Like Now

Take a recent healthcare engagement: a mid-size company building a patient data analytics platform on AWS. A year ago, the process looked like this: day one reading HIPAA documentation, day two comparing Redshift versus Athena versus EMR, day three producing a first-draft architecture. Three full days before anything meaningful hit the page.

Here’s how it went instead. A detailed prompt describing the workload, the data volume, the compliance requirements. Two minutes later: a structured comparison table covering strengths, limitations, cost estimates, and HIPAA considerations for each service option.

The output was about 70% of the way there. A starting point, not a finished product.

The AI recommended Redshift Serverless, which is technically solid advice. What it didn’t know is that this customer’s finance team operates on fixed annual budgets and can’t absorb variable monthly costs. It flagged HIPAA compliance at a surface level but missed that the use case involved sharing data with a research university, which triggers an entirely different conversation about de-identification under HIPAA Safe Harbor. It suggested a standard three-AZ deployment, with no way of knowing that this customer’s board mandated active-active multi-region after a previous outage made national news.

The final architecture came together in four hours instead of three days. Higher quality than a solo effort, because the tedious groundwork was already done and all the energy went into the decisions that actually required thinking.

Two Buckets

If the answer can be looked up, service comparisons, reference architectures, IaC templates, first-draft documentation, AI handles it faster and more thoroughly than any individual can.

What stays firmly in human hands: understanding budget politics, reading a room where a skeptical CTO, a cost-watching CFO, and a paranoid CISO all have different definitions of success. Making trade-off calls under real uncertainty. Knowing whether a team can actually operate what you’re about to design for them. Thinking about where the business needs to be in three to five years.

Judgment under ambiguity is what customers pay premium rates for. AI automated the least valuable, most tedious part of the job.

Three Loops, Not One

The cleanest way to picture the new workflow is three loops, each with a different role for AI.

In the discovery phase, before you ever walk into a customer meeting, AI compresses days of research into hours: industry trends, regulatory context, competitor patterns. After the meeting, it can scan your notes and surface the requirements you forgot to ask about.

In the design phase, AI generates the starting point: reference architectures, service options, infrastructure-as-code. Run everything through three questions before it leaves your hands. Does this match the customer’s actual constraints? Have the key claims been verified against primary documentation? Can you defend every decision in a room of skeptics?

In the delivery phase, AI drafts executive summaries, architecture decision records, and presentation outlines. The communication strategy, who hears what, in what order, framed around whose concerns, is yours to own entirely.

Think of AI tools like a team of capable, fast-moving interns. They take direction well and produce solid work. They need briefing, review, and guidance. They amplify what the lead can get done.

The Identity Shift Nobody Talks About

For years, the value of a senior SA was tied up in knowledge. Certifications. Memorized service comparisons. Being the person who could recite EBS volume types from memory at 6pm on a Friday.

AI has changed that completely.

The real value was always synthesis: taking technical capabilities, business requirements, human constraints, and risk tolerance and turning them into a coherent architecture that works in the real world. That requires experience, empathy, creativity, and judgment.

The architects who thrive will use AI aggressively for knowledge-heavy work and invest the freed-up time into deeper customer relationships and sharper strategic thinking. A surgeon uses an MRI and brings clinical judgment. That’s the model.

Three Things to Do This Week

Brief AI on the customer before every engagement. Industry, tech stack, known constraints, what keeps the CTO up at night. The quality of AI’s output is directly proportional to the quality of your briefing. Treat it like onboarding a new team member.

Build a library of power prompts. Questions like “What are the top five operational risks in the first 90 days?” or “If the budget were cut 40%, what would you cut first?” These prompts become repeatable, high-leverage tools you reach for on every engagement.

Never skip validation. AI is confident even when it’s wrong, especially when it’s wrong. Any claim that feeds into a critical architectural decision needs to be checked against primary documentation.

The Bottom Line

The tedious parts of this job are being automated. The strategic thinking, the creative problem-solving, the human trust built over years of showing up and getting it right, are more valuable than ever.

The calculator arrived. Time to do some real math.

Enjoyed reading the article? You might also enjoy the most popular posts from Big Tech Careers:

• You’re Doing STAR Format Answers Wrong. Here’s How to Do It the Right Way

• The One-Minute Elevator Pitch That Will Transform Your Interview Introduction

• The Complete Blueprint for Using AI in Your Interview Process

Also, connect with me on LinkedIn to excel in your cloud and AI career.

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 behavioural interviews, I have a self-paced course for you.

Check out the course page

Hey, Prasad here 👋 I’m the voice behind the weekly newsletter “Big Tech Careers.”

This week I bring you another guest post from Jove Zhong, Head of FDE @ Cresta! In this article, he shares his insights on why and how you should learn to code in 2026.

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

Over to you, Jove!

Last weekend I was one of the judges at the Cursor Hackathon at UBC Vancouver. (Small confession: it’s a 10-minute drive from my place, and I feel guilty that I don’t visit the campus more often.)

Students, AI engineers, even non-tech users — building something complete in 3–5 hours. That would’ve sounded crazy 2 years ago.

I won’t lecture you with deep “insights.” But I left with 3 observations that stuck with me — and they go straight to the question I was asked over and over again: Should I still learn programming? Should I take CS courses? Is coding even worth learning anymore?

Observation 1: Cloning is easy. Positioning is hard

In 4 hours, I saw clones of Wispr Flow, OpenAI browser, CoderPad.

With today’s models and coding assistants, you don’t need to reverse engineer anything. You can just build it.

But building a handy desktop tool is rarely a strong business case. SaaS lives long if it provides real collaboration, workflow depth, or complex platform features.

The bar for “I built this over a weekend” is low. The bar for “I’d pay for this every month” is still high.

This is the first lesson: knowing how to code is no longer enough on its own. The question is what you combine it with.

Observation 2: Coding is like English

Knowing how to code is like knowing how to speak English.

Great. But are you Shakespeare? Or JK Rowling?

Or do you combine it with something else — BioTech + Coding, Voice AI + Hiring, Security + Agents?

Know your ICP (Ideal Customer Profile), as narrow as possible.

“Next-gen CoderPad” doesn’t excite me. “CoderPad for candidates as voice AI agent developers” makes me pause.

Specificity wins.

This is the second lesson: product sense and domain knowledge are the multipliers. A programmer who understands a specific industry — healthcare, legal, finance, voice AI — is exponentially more valuable than one who just knows syntax.

Observation 3: Code is cheap. Talk is cheap. Idea is cheap. Iteration speed is everything

After judging, I started using one of the projects. I opened 6 tickets at 8pm. 5 got resolved at 9pm. Sunday night!

That’s the new software loop. You can use a laptop, an IDE, a text editor, or just a CLI to code, even with a mobile app, or just Telegram/Whatsapp with OpenClaw.

Code is cheap. Talk is cheap. Idea is cheap. Iteration speed is everything. Use the best coding model (e.g. Opus), use the best coding agent (yes, Claude Code), don’t waste time on cheaper or small models. Don’t waste your own time as a human to type everything, Cmd+F to search keywords in documentations, or write design doc or test cases.

Which brings me to the real topic of the blog:

“So, Should You Still Learn Programming in 2026?”

Yes. But not for the reason you think.

Not so you can write code. AI does that.

You need to be a good software engineer so you don’t blindly trust AI. That means learning programming, yes — but also taking CS courses like data structures, databases, system design, and understanding how hardware works. You don’t need a CS degree specifically. But you need the knowledge those courses teach.

If you can’t read code, evaluate code, or understand what’s happening under the hood, you’re not an engineer — you’re a relay between the user and Claude Code. Then why would I hire you, and not someone else who also knows how to commit code generated by Claude?

The answer is: I hire the person who can tell when the AI is wrong, who can direct it toward the right solution, and who understands the customer problem well enough to know what “right” even means.

That requires 3 things the hackathon made crystal clear: engineering fundamentals, product sense, and people skills. Let me connect each back to the observations.

Engineering Fundamentals: Why You Can’t Skip Them

Everyone at the hackathon could build something. The ones who built something good understood what was happening under the hood. They caught edge cases. They didn’t just ship — they shipped something that worked.

Without hands-on engineering experience and foundational CS knowledge — whether from a degree, self-study, or years in the field — you’ll struggle to evaluate what AI gives you.

You won’t know:

• What a deadlock is when the AI’s solution creates one

• The difference between an OLTP and OLAP database when the AI picks the wrong one — when to use SQLite, when to use DuckDB, which logic is running in the browser and what are done on the server side

• Why AI-generated code often only works on the happy path — it looks fine in a demo with 100 rows, but breaks in production with real data, real concurrency, and real edge cases

• What SQL injection looks like in the code Claude just generated

Anthony Mein, one of the founding Forward-Deployed Engineers on our team who graduated in 2022 — just before ChatGPT — said it well: “I’m super thankful that I have that foundation because now when I’m working with AI, I’m spending more time reading code than I am writing code.”

He built foundations before AI was everywhere. Students today have to build them deliberately, in spite of AI being available. “Do your data structures and algorithms by hand, without AI.” Check more in the “The Practical Gameplan” section.

Product Sense: The Multiplier CS Programs Ignore

This connects directly to Observation 1&2 — cloning is easy, positioning is hard; coding is like English, specificity wins.

At the hackathon, the teams that stood out weren’t the ones with the most impressive tech. They were the ones who could answer: “Who would pay for this, and why?”

Most CS programs teach you to build. Almost none teach you to figure out what to build. But in the AI era, the “what” is the hard part. The “how” is increasingly handled by AI.

This is exactly why the FDE (Forward-Deployed Engineer) role is growing while traditional engineering roles shrink. FDEs are deployed at customers. They understand the use case deeply enough to adapt the product in the field. They sit at the intersection of engineering, sales, and product — as we discussed in detail on the Forward-Deployed Caffeine podcast.

And it’s why the merge is happening: engineers need to think like PMs, and PMs need to build things like engineers. If you’re a PM who can’t read code or build things with AI, you’ll easily lose context in technical conversations. If you’re an engineer who can’t think about users, you’ll build things no one wants to use. The winners are the people in the middle — technical enough to build, product-minded enough to know what to build.

If you want to be safe in the next decade, develop product intuition alongside technical skills. Listen to customer calls. Study how products grow. Understand basic economics. Talk to users.

People Skills: The Moat AI Can’t Cross

Iteration speed is everything, but iteration requires collaboration with real humans.

Shipping fast means nothing if you’re shipping the wrong thing. And figuring out the right thing requires talking to customers, reading between the lines, and managing expectations — skills no model has.

You have to know when to say no to a client. You have to deliver bad news without losing the relationship. You have to read whether someone is frustrated vs confused over a Zoom call. As Anthony put it: “FDE is a really tricky role... You have to manage client expectations and you also need to be really friendly about this as well.”

AI can draft your email. It can’t build your reputation.

This is why traditional backend engineers, frontend engineers, and QA roles are under serious pressure — their primary output is code, and AI writes code. But FDEs and sales are safer. They require real-world interaction: presence, judgment, and trust. Things AI can assist with but not replace.

People skills compound over time in a way that technical skills don’t. The engineer who is technically average but excellent at building trust will outlast the brilliant engineer who can’t communicate.

The New Hiring Bar (What We Actually Test For)

So what does this all mean in practice? Let me tell you exactly what we look for when we hire FDEs. This has changed significantly.

Old interview: Can you implement a binary search tree? Can you reverse a linked list?

New interview: Given a real use case, a set of APIs, and your preferred AI tools — can you build a working AI agent? And then what?

Here’s what we actually care about:

1. Can you build a basic AI agent?

Not “write an algorithm from scratch.” Build something that connects to a real API, uses an LLM, and does something useful.

This is table stakes now. If you can’t scaffold a simple AI agent in a few hours, you’re behind.

2. Can you iterate and evaluate it?

This is more important than building the initial agent.

Anyone can prompt Claude and get something that looks like it works. The real skill is:

• How do you know if it’s actually working correctly?

• How do you write evals?

• How do you catch edge cases?

• How do you measure quality over time?

Shipping an AI feature is easy. Knowing it’s performing well in production is hard.

3. Can you ask good follow-up questions — and push back?

The candidates who impress us aren’t the ones who accept every AI suggestion. They’re the ones who say: “That solution works, but it has this edge case. Let me refine the prompt.” Or: “The code Claude generated here has a potential SQL injection — let me fix that.”

You should not be blindly copy-pasting everything AI generates and calling it done. You need to:

• Know what a good solution looks like

• Review code, whether it came from a human or an AI

• Correct the AI when it’s wrong

• Direct it toward the right answer when it drifts

The candidates who just let Claude do all the work and accept everything — that’s a red flag. That’s the person who will ship a security vulnerability to production because they didn’t read what they were deploying.

The Practical Gameplan

If you’re learning CS or programming today:

Phase 1: Build real foundations.

• Do your data structures and algorithms by hand, without AI. Yes, really.

• Understand databases: transactions, indexes, the difference between SQL and NoSQL.

• Learn networking basics: what HTTP actually does, how DNS works, what happens when you call an API.

• These aren’t academic exercises. They’re the vocabulary you need to review AI’s work.

Phase 2: Learn to build and ship AI agents.

• Pick a real use case you care about.

• Use your preferred model (Claude, GPT, Gemini — whatever).

• Build it end to end: prompt design, API integration, error handling, basic evaluation.

• Iterate. Measure. Improve.

Phase 3: Develop your domain angle.

• What industry do you care about? Healthcare, legal, education, sales, voice AI?

• Coding + deep domain knowledge = defensible career.

• “I build AI agents for X” is a much stronger sentence than “I build AI agents.”

Throughout: Review more code than you write.

• Read open source projects.

• Do code reviews with AI assistance — but form your own opinion first.

• Practice spotting bugs, security issues, performance problems.

• The ability to evaluate code is the skill AI can’t replace.

Is it getting easier or harder to be an engineer?

The bar hasn’t gotten lower. It’s shifted.

You don’t need to memorize sorting algorithms. You need to know enough to catch the AI when it gives you a bad one. You don’t need to build everything from scratch. You need to know enough to evaluate what was built. You don’t just need to code. You need product sense to direct AI toward the right solution, and people skills to understand the problem in the first place.

Code is cheap. Judgment is expensive. Iteration speed is everything.

The students who win won’t be the ones who prompt AI the best. They’ll be the ones who know when AI is wrong — and who can talk to a customer to figure out what “right” actually means.

That still requires building foundations first.

It’s the best time and worst time for builders.

Just make sure you understand what you’re building.

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

Want more on AI engineering careers and what it actually takes to be a Forward-Deployed Engineer? Subscribe to the Forward-Deployed Caffeine podcast. For resources, visit FDHub.org.

Related reads: Breaking Into AI FDE Roles Through a Hiring Manager’s Lens | Where Does the FDE Role Belong?

Connect: Follow Jove Zhong on LinkedIn for ongoing discussions about AI engineering, hiring in the AI era, and what the future of software development actually looks like.

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 behavioural interviews, I have a self-paced course for you.

Check out the course page

This week I bring you another guest post from Jove Zhong, Head of FDE @ Cresta! In this article, he shares his insights on where the FDE (Forward Deployed Engineering) teams should be placed in an organization.

If you are looking to get hired as an AI FDE, check his last week’s article - Breaking Into AI FDE roles Through a Hiring Manager’s Lens.

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

Over to you, Jove!

The $10 Million Question

Your company is building AI products. Customers need help deploying them. You’re hiring Forward-Deployed Engineers. (Check my blog to learn more about the FDE role)

One question will shape everything that follows: Where do they report?

• Engineering? (Build better products)

• Sales/GTM? (Close more deals)

• Customer Success/Professional Services? (Keep customers happy)

The answer isn’t obvious. And it matters more than you think.

The Three Models (And Why Two Are Wrong)

Model 1: FDE in Sales/GTM

The Logic: FDEs help close deals. They do demos. They’re customer-facing. Put them in sales.

The Reality: This creates the wrong incentives.

In the first episode of Forward Deployed Caffeine podcast, Milos from Leverage asked me “If you look at some decisions... would any of these decisions be different if you were a part of sales organization?”

I am not good at answering hypothetical questions. I am not a big fan of having FDEs report into the sales org, otherwise:

• Success = closed deals, not necessarily high-quality, successful deployments

• Incentive = say “yes” to everything to close the deal

• Focus = new logos over making existing customers successful

• Career path = sales engineer, not technical leadership

For early-stage companies (<20 people) where everyone wears multiple hats anyway, maybe this can work. Or companies selling simple products that don’t require deep customization.

Model 2: FDE in Customer Success or Professional Services

The Logic: FDEs make Customers Successful. That’s literally CS’s job. Perfect fit.

The Reality: FDEs become glorified support engineers.

The problems:

• FDEs could be charged by hours/days if they are part of Professional Services, then FDEs may not want to build automation to improve their productivity, and customers may want to keep the conversations/collaborations with FDEs as short as possible to save money.

• Engineering team sees FDEs as “not real engineers”

• FDE cannot take the learnings and update the product code. No direct line to product roadmap decisions. Feature requests go through multiple layers

• FDE builds the AI agent, not just configure in the web console, edit yaml file, or push the deploy button. There is a lot of engineering effort and expertise for prompt engineering, context engineering, model tuning, test/evaluation, mocking, security hardening.

In the second episode of Forward Deployed Caffeine podcast, as Anthony, one of the founding FDE at Cresta, puts it: “We act as that bridge between the customer and our product team and those standard software engineers.”

That bridge is structural, not just metaphorical. If FDEs sit in CS/PS, the bridge collapses.

Who this works for: Companies with simple products where “deployment” means configuration, not code. Or mature products where most work is troubleshooting existing features.

Model 3: FDE in Engineering ✓

The Logic: FDEs write code. They build products. They’re engineers.

The Reality: This is where the magic happens.

Why did Cresta choose engineering? As I keep saying in my podcast/blog/LinkedIn: “FDE stands for engineer, right? So we write a lot of code. I don’t really write many slides. Most of the time, all my team members, we write the code, we write the prompt, we refine the test framework, and we wire things together.”

Why Engineering Org Is the Right Answer (For AI)

Reason 1: You’re Part of the Product

In AI, the line between “platform” and “deployment” is blurry.

At least for Cresta, our current AI agent platform is primarily designed for FDEs (maybe FDPM and Sales Engineers) so that we can deliver in a high-quality, efficient, and time-sensitive way. There are too many myths, black magic, and surprises in AI, and most customers cannot handle this by themselves.

Think about what an FDE actually does:

• Writes production code

• Designs prompts (which are code in AI systems)

• Builds test frameworks

• Integrates with APIs

• Handles edge cases

• Ensures security and compliance

This isn’t just a configuration. This is software engineering.

Reason 2: Direct Feedback Loop to Product

Anthony describes the workflow: “When I’m telling the customer, let me go talk to our platform team and get back to you. And then we come back to them and we’re going to build this for you. We’re going to prioritize this for you.”

This only works when:

1. FDEs have technical credibility with platform engineers

2. FDE input carries weight in roadmap decisions

3. The communication path is short (not through multiple managers)

I’m explicit about this: The company’s direction for AI is driven by these FDEs. We’re the ones who interact with these customers every day, understand what their wishes are, what things we want to bring back to the platform.

Reason 3: The Iterative Development Cycle

Traditional SaaS: Build → Ship → Support → Learn → Build

AI deployment: Build → Deploy → Learn → Fix → Test → Deploy → Learn (repeat daily)

Milos shares an example: “Initially building a solution on top of our platform that was suiting the needs of the customer took 12 weeks. Then based on that solution, we figured out what were the biggest sort of components that the platform is missing... that allowed us to get to the next customer and build the same solution in eight weeks and then the third customer in about six weeks.”

This rapid improvement cycle only works when FDEs can:

• Push code to the platform

• Propose architectural changes

• Participate in technical design reviews

• Have peer relationships with platform engineers

Reason 4: Career Path and Hiring

If you want to hire strong engineers, they need to see a technical career path.

FDEs at AI agent companies like ours are almost like the new McKinsey. In the past, people sent a bunch of money to let those people from McKinsey come to your office... Now, because we are building agents for those airline companies, for healthcare, for those FinTech companies... we need to build a working solution.

But here’s the key difference from consultants: FDEs are building technical platforms, not PowerPoint decks.

The engineers you want to hire care about:

• Technical growth

• Learning from senior engineers

• Working on hard problems

• Building real systems

Anthony explains why he joined: “I was really looking to learn from more experienced developers, to get in a space where it’s more fast moving, where we’ve got a lot of people with great experience, great engineers.”

If FDE reports to sales, you’ll get sales engineers. If you want actual engineers, put them in engineering.

The Structure at Cresta: A Case Study

Here’s how it actually works at Cresta:

• I am the Head of FDE, reporting to VP of Engineering

• VP of Engineering reports to CEO

• Today, there are 15 FDEs report to me. There will be 20 to 40 more FDEs to hire this year and I am hiring FDE managers too.

• The FDE team and I work closely with Platform engineering teams, ML/AI research teams, Infrastructure teams

• As an engineering lead, I join product roadmap prioritization and weekly/monthly check-ins.

Collaboration:

• FDPMs (Forward-Deployed Product Managers) work with FDEs

• Solution engineers help with pre-sales

• CSMs handle ongoing relationships

I’m not just a FDE manager. I also contribute individually, but I don’t spend as much time as my engineers. But I observe and I try to see whether there’s any room you can improve in the process. So I would say it’s 50/50, half IC, half manager/leader.

The Counter-Argument: “But Sales Needs Them!”

Fair point. FDEs do help close deals. Anthony describes his impact: “By nature, our product is exposed to thousands of callers, thousands of customers. And so we need to build resilient AI agents, resilient prompts that are ready to handle any scenario.”

Customers see this value. They buy because of it.

But here’s the thing: FDEs help sales as a side effect of doing good engineering work.

The value chain:

1. FDE builds great deployment for Customer A

2. Learns lessons, feeds back to platform

3. Platform gets better

4. Next deployment is faster/better

5. Sales can show better demos, faster time-to-value

6. More deals close

If FDEs report to sales, you optimize for step 5 at the expense of steps 1-4.

The AI-Specific Factor: Why This Matters More for AI

Traditional software has clear boundaries:

• Platform team: builds the product

• Sales engineers: demo the product

• Implementation consultants: deploy the product

• Support engineers: fix the product

AI breaks all these boundaries.

Anthony explains: “We work on client-specific implementation. So instead of going for generalization, we’re going for specificity. We’re identifying patterns among those client deployments that we can then bring back to the platform and reuse in a meaningful way.”

Every deployment is:

• Partially custom code

• Partially platform features

• Partially prompt engineering

• Partially test framework

• Partially integration work

You can’t hand this off between teams. It has to be one person who can do it all.

And that person needs to be an engineer.

The Practical Test: Ask These Questions

Still not sure where FDEs should sit? Ask:

1. Can FDEs submit PRs to the core platform?

• Yes → probably engineering

• No → definitely not engineering (and that’s a problem)

2. Do FDEs participate in platform architecture reviews?

• Yes → engineering

• No → they’re isolated (bad sign)

3. When FDEs find a platform bug, what happens?

• File ticket → sales/CS org

• Fix it themselves or work directly with platform team → engineering org

4. How is FDE success measured?

• Deals closed → sales org

• Customer health scores → CS org

• Platform improvements and customer success → engineering org

5. What’s the career path for senior FDEs?

• Account executive → sales org

• CSM manager → CS org

• Staff engineer or engineering manager → engineering org

The Bottom Line

If you’re building AI products, your FDEs should report to engineering.

Not because of ideology or title prestige, but because the job requires:

• Writing production code

• Deep technical expertise

• Direct influence on product roadmap

• Peer relationships with platform engineers

• A culture of iterating and improving

As Milos puts it: “FDE is the person in the middle to wire things together. But we are not really part of the pre-sales or go-to-market because we are part of the product.”

The product. Not product marketing. Not product success. The actual product.

The Future: Will This Change?

As AI products mature, will we need FDEs at all?

Anthony shares the vision: “Something that is really important to an FDE role is that I’m always trying to make my job easier and make my job faster so I can take on more customers.”

The goal is self-service. Eventually.

But I’m realistic: In the near term, it is FDEs who make sure we can quickly build something enterprise-grade with all the security, with all the performance, business logic.

The near term might be 5 to 10 years. Maybe longer.

Until then, put your FDEs in engineering. They’ll thank you. Your platform engineers will thank you. And most importantly, your customers will thank you.

Because they’ll actually get working AI systems, not just promising demos.

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

Want to discuss FDE org structures? You can call (888) 390-9595 to ask questions to the virtual version of Jove

I would also encourage you to subscribe to his Forward-Deployed Caffeine podcast for more conversations about FDE roles, career paths, and the future of AI deployment.

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 out the course page

This week I bring you a guest post from Jove Zhong, Head of FDE @ Cresta! Based on recent episodes of his “Forward Deployed Caffeine” podcast, he shares what it takes to get your resume shortlisted for AI FDE roles.

Jove is hiring dozens of AI FDEs this year. He reviews hundreds of FDE resumes every week and in this article provides insights into the experience and skills he looks for in the candidates he hires as FDEs.

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

Over to you, Jove!

The 5-Second Resume Screen

I review hundreds of FDE resumes every week (never use AI). I spend 5 to 10 seconds per resume. Not because I’m cold, because speed is a hiring superpower!

So, let’s start with the uncomfortable truth: your carefully crafted 5-page resume? It gets 5 seconds of attention. Maybe 10 if you’re lucky.

By default I spend 5 seconds, 10 seconds for every single resume, having reviewed hundreds (if not thousands) of FDE applications. I guess maybe you can blame me, but I don’t really have enough time to spend doing research for every single resume.

So what catches an FDE hiring manager’s eye in those precious seconds?

The Non-Negotiables

1. Real Engineering Experience (Minimum 1 Year)

I don’t want to hire someone with less than 1 year full-time working experience. I used to set the bar at 2 years, but lowered it after seeing exceptional candidates who grew quickly.

Why the experience requirement? FDE is not really just a technical effort. You need to understand how to do customer facing. You have to know some of the business logic. You need to know how to say no, how to challenge others, how to push the current clients.

(Source: Do We Really Need FDEs?)

2. Hands-On AI/LLM Experience

This isn’t negotiable. The job posting says “AI experience,” and they mean it.

What they’re looking for:

• Experience with Python-based LLM frameworks

• Knowledge of observability frameworks

• Understanding of test evals and how to run them

• Actual agent building experience (not just prompt tinkering)

We don’t want to hire someone just good at Python and spend the other half year training them. Getting your hands dirty about using AI or even building agents is something we look for.

Anthony Mein, who joined as Cresta’s second full-time FDE, shares his journey: “I’ve been on the ground with LLM since day one since the transformer model was released. I remember the first day I saw ChatGPT come out, my coworker and I were trying it out for some little tasks and it was horrible at coding... but over time we would continuously check back and as you grow with the AI technology evolving, we’re also growing with the best practices.”

3. The Right Educational Foundation

Does university matter? Yes and no.

Whether the person is coming from a nice university... it doesn’t mean a lot, but it means something because you are already selected, right? You earn your ticket to go to one of the best universities in a nice kind of major, you already get some computer science.

But it’s not a dealbreaker if you’re not from a top-tier school. What matters more is:

• Computer science or technical major (preferred)

• Evidence of technical depth

• Actual projects and real-world experience

4. The Tech Stack Check

I scan for specific signals in your resume:

• What programming languages do you use?

• What frameworks have you worked with?

• Are you dropping buzzwords or demonstrating depth?

Red flag: If people are talking about a lot of buzzwords, for example, like ISO or those change management, those big words, not really about those technical terms, I’m worried about.

What impresses: Specific mentions of frameworks, tools, and technologies with context about how you used them.

The Secret Weapon: Founding Engineer Experience

Here’s something that really stands out: startup or founding engineer background.

If people already have some founding engineering background, even as a founder, a couple of things. One is they work very hard and in a very challenging environment before. They know nothing is easy.

Why founding engineers make great FDEs:

1. Ownership mindset: “I will make this happen in whatever cost it is”

2. Self-directed: Won’t wait for approval or task assignment

3. Comfortable with ambiguity: Used to figuring things out independently

4. High agency: They will drive things and they will fix things. It’s okay to break things, but as long as you can fix fast.

Milos Mandic, FDE at Leverage, embodies this profile perfectly: “It’s been 6 months at Leverage doing forward deployed engineering, but my career spans all the way back to 2015. About 10 years now in engineering space, a bit all over the place... software engineering, also product management, technical instruction, all those skills that I believe put you in a really good place to become a forward deployed engineer.”

What Doesn’t Go on the Resume

Keep It Short

Please, you don’t have to send a resume for like five, six pages, just one page or two pages is good enough.

Skip the Fluff

Focus on:

• University and graduation year

• Work experience with specific projects

• Technical stack and tools

• Real outcomes and impact

Don’t waste space on:

• Generic objective statements

• Long lists of soft skills

• Irrelevant hobbies (unless they demonstrate relevant skills)

Beyond the Resume: The Real Test

Even with a great resume, you’ll face:

1. Online coding test: We send the person an online test, making sure they can do the basic coding because sometimes people lie or buff a little bit on their resume.

2. Recruiter screen: Our recruiter talks to the person, making sure they can express themselves and they can share their lesson and their motivation.

3. Technical interviews: Multiple rounds with the team

The Mindset That Gets You Hired

More important than any single technical skill is demonstrating the right mindset:

Customer-Facing Comfort

You need to understand how to do customer facing. You have to know some of the business logic.

This isn’t a backend role where you can hide behind Slack messages. You’ll be on client calls, explaining technical concepts, managing expectations.

Healthy Skepticism About AI

Anthony puts it perfectly: “You need to have a healthy skepticism about AI code. As you said, you’re the ultimate owner of that. Whether the AI wrote it or not doesn’t matter if you’re the one approving it.”

The hiring team looks for candidates who:

• Understand AI capabilities AND limitations

• Can evaluate AI-generated code critically

• Know when to push back on AI suggestions

Continuous Learning Orientation

The field is evolving daily. “Best practices are changing every single day,” Anthony notes. “You need someone with deep expertise in the AI field that your customer might not necessarily have.”

Can you keep up? Do you actively follow:

• Latest model releases (GPT, Claude, Gemini)?

• New frameworks and tools?

• Emerging best practices?

• Research papers and industry developments?

The Interview Philosophy: Transparency Over Gatekeeping

What’s refreshing about my approach? I’m not trying to make hiring harder.

I’m very open to sharing about it because I don’t want to hide those criteria. I don’t want to make my hiring harder. I want to meet more promising candidates and bring those awesome talents to our team.

This is the opposite of the typical “secret interview tricks” mindset. The FDE space needs talent, and the best way to find it is to be clear about what you’re looking for.

Red Flags That Get You Auto-Rejected

1. Zero professional experience: If you have not graduated yet, please, you don’t have to send a resume to me.

2. No AI/LLM background: If you’re learning about LLMs for the first time on the job, it’s too late.

3. Pure management speak: Buzzwords without technical depth signals you haven’t been hands-on.

4. Can’t code: The online coding test is non-negotiable. I want to make sure you can do the basic coding.

What Success Looks Like: Anthony’s Journey

Anthony represents the ideal hire in many ways:

Background:

• Graduated college in 2022 (pre-ChatGPT era, so learned fundamentals the hard way)

• Previous role: One of two developers building full stack AR + AI application

• Learned from being in small team: “I was really looking to learn from more experienced developers, to get in a space where it’s more fast moving”

What stood out:

• Deep hands-on experience across the stack

• Early adopter of AI/LLM technology

• Customer-facing experience from previous role

• Genuine enthusiasm for the technology

• Clear communication skills

His advice for applicants: “Really getting your people skills up and being able to have friendly interactions with customers. FDE is a really tricky role... You have to know when to say no to a client. You have to manage client expectations and you also need to be really friendly about this as well.”

The Bottom Line

Getting hired as an FDE isn’t about gaming the system or knowing secret interview tricks. It’s about:

1. Having real engineering experience (1+ years minimum)

2. Demonstrating hands-on AI/LLM expertise (not just theoretical knowledge)

3. Showing customer-facing readiness (communication skills, business understanding)

4. Proving high agency (founding engineer mindset preferred)

5. Keeping up with the field (continuous learning, following latest developments)

As I summarize: FDE is filling the missing piece. There are so many challenges for AI and the customer or the platform engineer don’t really have enough time understanding each other and they will have to make things happen.

If your resume can tell that story in 5 seconds, you’ve got a shot.

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

I encourage you to subscribe to his Forward-Deployed Caffeine podcast for more conversations with FDEs from different companies and verticals.

Interested in FDE roles? Jove is hiring dozens of more FDE and managers:

• https://job-boards.greenhouse.io/cresta/jobs/5097513008 (US)

• https://job-boards.greenhouse.io/cresta/jobs/4595480008 (Canada)

• https://job-boards.greenhouse.io/cresta/jobs/5097513008 (EMEA)

• https://job-boards.greenhouse.io/cresta/jobs/5107283008 (APAC)

• https://job-boards.greenhouse.io/cresta/jobs/5099068008 (FDE Managers)