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)

In this week’s article, I share how you can develop simple superpowers help you grow your careers faster

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

The people who advance fastest aren’t always the smartest or most experienced. They’re the ones who’ve mastered a few simple behaviors that make them indispensable.

Let me share three superpowers you can develop starting today.

Superpower #1: Turn “I Don’t Know” Into “I’ll Find Out”

Here’s a situation that happens every day in workplaces:

Manager: “Do you know how to do X?”

Most people respond in one of three ways:

Response 1: “Sorry, I don’t. I haven’t worked on it.”

This is a dead end. The conversation stops. Your manager now has to find someone else or figure it out themselves.

Response 2: “I don’t, but let me figure out how to do it.”

This is better. It shows initiative and willingness to learn.

Response 3: “I don’t, but I think Sarah knows—she worked on something similar last quarter. Let me connect with her and get back to you by tomorrow.”

This is the superpower.

You’re not just offering to learn. You’re showing resourcefulness. You’re building connections. You’re providing a timeline. You’re turning a gap in your knowledge into a solution.

The earlier you start investing in your network, the more it pays off later.

The key insight: Your value isn’t in knowing everything. It’s in being the person who can figure things out and make connections.

Superpower #2: Give Credit Generously

Picture this: Your team just delivered a major project successfully.

Response 1: “We did a great job on this project.”

Generic. Forgettable. Nobody feels special.

Response 2: “I worked really hard on this and delivered it on time.”

You’re making it about you. This might feel good in the moment, but it doesn’t build relationships.

Response 3: “This worked because Maria solved that critical database issue within tight timelines, and Dev’s design made it so intuitive that we had zero complaints from users. Couldn’t have done it without them.”

This is the superpower.

When you shine a light on others, something magical happens. People remember who made them feel valued. They want to work with you again. They recommend you for opportunities. They go the extra mile for you.

The key insight: Your reputation grows faster when you grow other people’s reputations.

And here’s the bonus: Leaders notice people who lift others up. Because that’s what leaders do.

Superpower #3: Save People Time

This one is subtle but powerful.

Someone asks you for information or a deliverable.

Response 1: “Here’s the report.” (Sends attachment.)

You completed the task. But you’ve created work for the recipient. They now have to read the entire thing to find what they need.

Response 2: “Here’s the report. Let me know if you have questions.”

Slightly better. You’re offering help. But they still have to dig through it first.

Response 3: “Here’s the report. Key finding: we can reduce costs by 30% if we migrate by Q2. Page 7 has the detailed breakdown. The main risk is the two-week training period for the team. Happy to discuss next steps whenever you’re ready.”

This is the superpower.

You’ve given them:

• The bottom line upfront

• Where to find details

• What to watch out for

• A clear next step

You’ve saved them 20 minutes. And you’ve shown that you think about their needs, not just your task.

The key insight: People remember those who respect their time.

Do this consistently, and you become the person everyone wants on their team. Because working with you is easier.

Why These Work

These three superpowers share something in common: They’re not about working harder or being smarter.

They’re about working differently.

They’re about shifting from:

• “I completed my task” to “I solved the problem”

• “I did my part” to “I helped the team succeed”

• “I delivered what was asked” to “I delivered what was needed”

The best part? You can start practicing these today. In your next meeting. In your next email. In your next conversation.

Your Turn

Pick one of these superpowers and try it this week.

When someone asks you a question you don’t know the answer to, connect them with someone who does.

When your team achieves something, name the specific people who made it happen.

When you send information, lead with the key takeaway.

Small changes. Big impact.

That’s how you accelerate your career.

What superpower will you develop first? Share in the comments.

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 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 the skills you need to get hired as FDE in top AI companies.

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

This is a follow‑up to my earlier article on transitioning from Developer/Architect to AI FDE roles. In that piece, I argued that the knowledge gap is smaller than you think if you already work as an Solutions Architect (SA) or Software Engineer (SWE).

In this article, I go one level deeper: I analyze what AI Forward Deployed Engineer–style roles actually look like at five of the most sought‑after companies—OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce—and distill the skills you really need to break into them.

You’ll notice a pattern: the core skills are the same, but each company has its own weightage for each of these skills that they look for in candidates.

The Common DNA: What All AI FDE Roles Expect

Before we pick apart company‑specific nuances, it’s worth summarizing the shared core of these roles.

Across these five companies, an AI FDE is expected to:

• Embed with customers or strategic internal teams, not just sit in a central platform group.

• Own end‑to‑end delivery: discovery, design, implementation, deployment, and post‑go‑live iteration.

• Work directly with modern LLM tooling: RAG systems, agents, vector stores, observability, and cost controls.

• Translate messy business requirements into durable technical systems and then back into business value.

• Operate under ambiguity, time pressure, and partial information.

As you can see, these are combination of SA, SWE and AI skills including both technical and behavioral skills.

OpenAI: Deep AI Fluency + Full‑Stack Ownership

Positioning: OpenAI’s forward‑deployed roles skew toward high‑stakes, high‑impact deployments with customers who are building on top of frontier models. The expectation is that you act as both a product engineer and a field architect.

What they really test for:

• LLM depth, not just API usage

  • Solid understanding of tokenization, context windows, function calling, system prompts, rate limits, and failure modes.

  • Ability to choose between RAG, fine‑tuning, and prompt‑engineering tradeoffs and justify them with cost/latency/quality reasoning.

• Full‑stack + infra skills

  • Comfortable shipping production systems: backend (Python/TypeScript), basic frontend (React/Next), infra (Docker, K8s, cloud).

  • Can design data pipelines for logging, analytics, safety signals, and feedback loops.

• Customer‑facing ambiguity handling

  • You walk into “we want AI” conversations and shape them into concrete use cases, milestones, and guardrails.

  • You’re comfortable saying “no” to unrealistic expectations while offering a simpler path that still delivers value.

How to prepare for OpenAI‑style FDE interviews:

• Build and ship at least one real product on OpenAI APIs (not a toy chatbot): for example, a workflow assistant with RAG, role‑based access, analytics dashboard, and guardrails.

• Be ready with case studies that show: discovery → design tradeoffs → shipping under constraints → post‑launch iteration.

• Practice explaining LLM tradeoffs to a non‑technical VP in simple language.

Current FDE open roles at OpenAI

• https://openai.com/careers/search/?q=FDE

Anthropic: Safety‑First Applied AI + Long‑Term Customer Stewardship

Positioning: Anthropic’s forward‑deployed engineers lean heavily into applied AI with a safety and reliability lens. You’re expected to think about not just “does it work?” but “does it behave safely and predictably under pressure?”

What they really test for:

• Applied AI engineering with a safety mindset

  • Familiarity with Claude‑style models, safety policies, red‑teaming concepts, and failure‑mode thinking.

  • Ability to design flows that mitigate prompt injection, abuse, and misuse scenarios.

• Structured reasoning & evaluation

  • Designing evaluation harnesses, test datasets, and metrics for “quality” beyond simple accuracy: helpfulness, honesty, harmlessness.

  • Iterating on prompts and policies in a structured, data‑driven way.

• High‑trust, long‑term client relationships

  • You’re more steward than “hit‑and‑run” implementer; you help customers evolve their AI maturity over months, not just ship a single feature.

  • Strong written communication: architecture docs, safety considerations, decision logs.

How to prepare for Anthropic‑style FDE interviews:

• Build at least one “safety‑aware” AI feature: think moderation, red‑teaming tools, or evaluation dashboards that track failure modes, not just latency.

• Prepare stories where you caught risks early (data misuse, policy issues, security gaps) and navigated them with stakeholders.

• Practice walking through how you’d design an AI system for a regulated domain (finance, healthcare, gov) and what safety levers you’d include.

Current FDE open roles at Anthropic

• https://job-boards.greenhouse.io/anthropic?keyword=FDE

NVIDIA: Systems‑Level Performance + AI Infrastructure

Positioning: NVIDIA’s forward‑deployed/architect roles are closest to AI infrastructure and performance engineering. Instead of “which prompt?” the conversation is often “which GPU, which optimization, which deployment pattern?”

What they really test for:

• Strong systems & performance orientation

  • Comfortable reasoning about GPU utilization, batching, concurrency, throughput, and cost per token or per request.

  • Understanding of how model choices, quantization, and deployment frameworks impact latency and cost.

• Platform and ecosystem fluency

  • Familiarity with NVIDIA’s AI stack (CUDA basics, Triton, TensorRT, NIMs, etc.) is a strong plus.

  • Bonus points for comfort with multi‑cloud deployments and hybrid/on‑prem setups.

• Architect‑level customer guidance

  • You can sit with a customer’s infra team and co‑design reference architectures that fit their budget, latency needs, and compliance constraints.

  • You’re credible in conversations with both CTOs and senior infra engineers.

How to prepare for NVIDIA‑style FDE/architect interviews:

• Take an existing LLM application and run simple performance experiments: batching, caching, model size swaps; document how these affect latency/cost.

• Learn at least one NVIDIA‑branded component end‑to‑end (e.g., deploy a small model using Triton or a NIM‑style setup) and be able to explain the architecture.

• Prepare a “customer workshop” style narrative: how you’d guide a bank or telco from “we want AI” to a GPU‑backed architecture.

Current FDE open roles at NVIDIA

• https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite?q=Forward+Deployed+Engineer

Databricks: Data + GenAI + Enterprise Platforms

Positioning: Databricks’ AI Engineer / FDE roles sit at the intersection of data platforms and generative AI. Think “build AI on top of the lakehouse and ship it into customer workloads.”

What they really test for:

• Data engineering + GenAI hybrid

  • Strong skills in Spark, SQL, and data modeling, combined with hands‑on experience building RAG/LLM apps.

  • Ability to design retrieval over large enterprise datasets, not just a handful of PDFs.

• Platform thinking

  • You don’t just hack a one‑off script; you build reusable patterns that can be productized or repeated across customers.

  • You understand how feature stores, governance, and lineage matter for enterprise AI.

• Field engineering & enablement

  • You can work side‑by‑side with a customer’s data team, co‑building notebooks, pipelines, and MLflow/observability setups.

  • Strong skills in making complex architectures understandable through diagrams, demos, and “day‑2 operations” docs.

How to prepare for Databricks‑style FDE interviews:

• Build a full RAG system backed by a real data lake: ingest docs, create embeddings, store in a vector DB, expose as an API, and add monitoring.

• Practice telling the story of a data‑intensive project: ingestion → transformation → governance → AI feature → monitoring.

• Be ready to whiteboard how you’d integrate Databricks with a customer’s existing warehouse, BI tools, and downstream apps.

Current FDE open roles at Databricks

• https://www.databricks.com/company/careers/open-positions?department=Professional%20Services&location=all (search for FDE)

Salesforce: AI Agents, Business Workflows, and Enterprise “Last Mile”

Positioning: Salesforce’s AI FDE roles are deeply tied to AI agents and business workflows inside the Salesforce ecosystem. The emphasis is on customer outcomes, not just model sophistication.

What they really test for:

• Workflow‑centric AI design

  • You can map sales, service, or marketing workflows and decide where AI agents add value: drafting emails, suggesting next best actions, summarizing cases, etc.

  • You understand how to chain tools, data sources, and prompts into reliable “agentic” flows.

• Ecosystem fluency

  • Enough understanding of Salesforce platform primitives (objects, flows, Apex, integration patterns) to wire AI into real orgs.

  • Comfortable mixing declarative tools with code and external AI services.

• Elite customer‑facing skills

  • You spend a lot of time with business stakeholders: directors of sales, heads of service, program managers.

  • You can peel back the layers of “we want an AI bot” into root business problems and define measurable outcomes.

How to prepare for Salesforce‑style FDE interviews:

• Build an “agentic” AI prototype around a business workflow: e.g., an AI that triages support tickets and drafts responses while logging everything into a CRM.

• Practice explaining AI capabilities in pure business language: pipeline impact, CSAT, handle time, revenue lift.

• Prepare examples where you shaped requirements, pushed back on purely “flashy demo” ideas, and delivered something that actually moved metrics.

Current FDE open roles at Salesforce

• https://careers.salesforce.com/en/jobs/?search=forward+deployed+engineer&pagesize=20#results

Skill Map: How the Five Companies Differ

Here’s a simple way to visualize the emphasis areas. All five require all of these skills, but the “dial” is turned up differently.

Use this to target your preparation. You don’t need to be equally strong on everything to start; you need one or two companies where your natural strengths line up with their focus areas.

A 6–8 Week Targeted Plan for These Five Companies

If my earlier article was about “closing the general AI FDE gap,” this is the company‑specific version.

Weeks 1–2: Core LLM + One Deep Project

• Revisit LLM fundamentals and RAG.

• Build one serious end‑to‑end app and treat it as your “OpenAI/Anthropic case study”:

  • Backend API, basic frontend, RAG, observability, cost tracking, and a simple safety policy.

Weeks 3–4: Pick a “Platform Anchor”

Choose one based on your target:

• OpenAI: Build an end‑to‑end app on OpenAI APIs: for example, a customer‑support assistant with RAG over real docs, role‑based access, analytics dashboard, and basic safety/guardrail checks.

• Anthropic: Build a Claude‑based internal assistant (e.g., policy QA or contract reviewer) with an evaluation harness that tracks quality, safety failures, and red‑team prompts.

• NVIDIA: do a small performance‑oriented deployment, experiment with latency and throughput, document tradeoffs.

• Databricks: build a RAG system on top of a small lakehouse‑style dataset.

• Salesforce: build a workflow‑centric agent that automates part of a sales or support process (with a mock CRM if needed).

Weeks 5–6: Storytelling and Behavioral Prep

• Turn your projects into 3–4 crisp case studies: problem → constraints → decisions → results → lessons.

• Practice behavioral stories that highlight: discovery, production debugging, stakeholder management, expectation management.

• Tailor your resume bullets and LinkedIn to explicitly mention “AI Forward Deployed Engineer–style work” and name these companies as your target pattern.

If you already have SA/SWE experience, this plan is less about learning everything from scratch and more about relabeling and aiming the skills you already use daily.

The Bottom Line

AI FDE roles at OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce are deep enough in AI and engineering to ship, and deep enough in customer reality to matter.

If you’re a seasoned SA or SWE, you’re already 60–70% of the way there. The remaining 30–40% is:

• Gaining AI fluency

• Picking 1–2 ecosystems to anchor on them (the focus of each of them is bit different)

• Learning to talk about your work through the lens of “forward‑deployed impact,” not just “feature delivery.”

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

Here is what is covered in the 3+ hour course:

Check the course page for more details.

Enroll for Interview Preparation Course

In this week’s article, I share when you as candidates should be prepared to showcase behavioral skills during the interview process and provide you resources to prepare.

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

Here’s something that surprises most technical professionals: behavioral skills aren’t just evaluated during the dedicated behavioral interview round. They’re being evaluated from the very first question, often before the technical interview even starts.

Many candidates believe behavioral assessment happens in a separate block, usually near the end of the interview process. In reality, hiring teams are evaluating your behavioral competencies across every single interview. Your ability to be hired at the right level depends on consistent performance across three distinct evaluation moments, and each requires different preparation.

The Three Moments When Behavioral Skills Are Evaluated

First, there’s the opening conversation. This starts with your recruiter call and continues into the first technical interview. Then, behavioral evaluation happens throughout your technical interviews themselves. Finally, there’s the dedicated behavioral interview round. Each moment assesses different aspects of your competencies and requires different strategies.

Most candidates focus only on the third moment. They prepare answers to “Tell me about a time when...” questions but neglect the other two. This is a critical mistake. The interviewer who speaks to you first forms an impression that influences how every other interviewer perceives you. The technical interviewer who watches you explain your architectural choices is simultaneously assessing your judgment and decision-making process. By the time you reach the dedicated behavioral round, the narrative about you is already partially written.

Let’s look at each moment, what’s being evaluated, and how to prepare.

Moment 1: Tell Me About Yourself

The question “Tell me about yourself” appears everywhere. It’s asked by the recruiter on your initial call. It’s asked by the technical interviewer at the beginning of the coding round. It’s asked by the hiring manager. It’s asked by the panel interviewer before the system design discussion. Some candidates face this question five times in a single interview loop, sometimes with slightly different framings like “Walk me through your resume” or “Tell me about your background.”

Most candidates completely underestimate its importance. When you’re asked “Tell me about yourself,” the interviewer isn’t looking for your resume recited out loud. They’re assessing several behavioral competencies simultaneously.

Can you communicate concisely? Do you highlight impact or just responsibilities? Do you show self-awareness about your growth? Do you understand what matters for this specific role? Can you tell a coherent story about your career progression?

Your answer shapes how the interviewer perceives you before any technical question is asked. If you ramble for five minutes without clarity, they’ve already formed an impression. If you jump between random accomplishments without connection, they’re questioning your communication skills. If you focus entirely on what you did without explaining the impact, they’re seeing a junior mindset.

Here's an article with a framework to help you prepare your answer for "Tell me about yourself.":

Moment 2: Behavioral Skills During Technical Interviews

Many candidates don’t realize that behavioral assessment happens throughout technical interviews, not just when answering explicit behavioral questions.

During a coding interview, the interviewer might ask “Why did you choose this data structure?” or “How would you optimize this further?” These are behavioral moments. They’re assessing how you think about tradeoffs, whether you consider constraints, how you handle feedback, whether you communicate reasoning clearly.

During a system design interview, when you’re drawing architecture on the whiteboard, behavioral evaluation is happening constantly. Can you explain your decision-making process? Do you consider the viewpoint of your interviewer? Do you ask clarifying questions before diving in? Do you acknowledge tradeoffs or do you present your solution as obviously optimal? Do you listen when challenged or do you defend rigidly?

The technical answer is only part of the evaluation. How you arrive at that answer, how you explain your reasoning, and how you discuss tradeoffs all signal your seniority level.

Read this article to discover how behavioral skills can help you stand out in technical interviews:

Moment 3: Dedicated Behavioral Interview Questions

It’s where you have the most time and space to demonstrate behavioral competencies in depth. It’s where you seal the narrative that’s been building throughout the interview and get hired at right level.

Here are few resources to help you prepare for behavioral interviews:

What This Means for Your Preparation

You need to prepare for all three moments, not just the behavioral round.

First, master your “Tell me about yourself” answer. This is your opening act. Make it strategic, concise, and tailored to the role. Practice it until it feels natural, not robotic. Know multiple versions for different interview contexts.

Second, develop the ability to articulate your thinking during technical interviews. Learn to explain not just what you decided, but why. Practice talking through your decision-making process, your assumptions, your tradeoffs. When an interviewer pushes back or asks a clarifying question, see it as an opportunity to demonstrate your thinking, not as an attack.

Third, prepare deep answers for behavioral questions. Depending on the company you are preparing for, have five to fifteen well-developed stories that you can adapt to different questions. Know the underlying behavioral competencies you’re demonstrating with each story.

The candidates who get hired at the right level aren’t necessarily the smartest in the room. They’re the ones who communicate clearly across all three moments. They tell a coherent story about their career, their judgment, and their impact from the first question to the last.

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 each of these three moments, I have a self-paced course for you.

Here is the full curriculum along with the time duration of each section that is covered in the 3+ hour course:

1) Build a Strong Foundation (33:22)

• How to introduce yourself in an interview? (13:39)

• How to stand out in technical interview using behavioral skills? (02:53)

• Examples of technical interview answers showcasing behavioral skills (10:44)

• How to handle technical questions for which you do not know the answer (06:06)

2) Gain expertise on STAR format (01:16:31)

• What is STAR (Situation, Task, Action, Result) format (09:07)

• How to use STAR format effectively to answer behavioral questions (11:56)

• The Three Pillars of Senior-Level Responses (Scope and Impact) (11:22)

• The Three Pillars of Senior-Level Responses (Technical Depth and Complexity) (08:09)

• The Three Pillars of Senior-Level Responses (Leadership and Collaboration) (08:43)

• Effectively use the Three Pillars of Senior-Level Responses in STAR format (06:25)

• Key themes you should be preparing for your behavioral interviews (07:40)

• Number of stories you should be preparing for behavioral interviews (13:19)

3) Become an Expert Interviewee (26:09)

• How long an answer should be (05:06)

• How to answer follow-up questions? (05:21)

• How to handle scenario questions for which you don’t have experience (10:59)

• How to read the clues by the interviewer and course-correct (04:43)

4) Real answers that landed MAANG+ jobs (27:36)

• Real answers that landed MAANG+ jobs (Customer/User Focus Story) (06:59)

• Real answers that landed MAANG+ jobs (Success Story) (03:09)

• Real answers that landed MAANG+ jobs (Failure Story) (09:30)

• Real answers that landed MAANG+ jobs (Conflict Story) (07:58)

5) Next steps and Action plan to get a dream job in next 6 months (16:58)

• Next steps and Action plan to get dream job in next 6 months (12:24)

• Take home exercise (04:34)

In the course, you’ll learn following:

✅ Deliver high-impact STAR-format responses
✅ Craft compelling technical achievement stories
✅ Effectively communicate leadership experiences
✅ Blend technical depth with strong behavioral skills
✅ Prepare mentally for four to eight rounds of interviews
✅ Stay authentic while following structured frameworks
✅ Navigate past failures and conflicts with confidence
✅ Deliver senior-level responses to get hired at the right level

Check the course page for more details.

Enroll for Interview Preparation Course

In this week’s article, I share how to use your existing skills and gain new skills to transition to an AI Forward Deployed Engineers (FDE) role.

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

Last quarter, I wrote an article on how the Forward Deployed Engineer (FDE) role represents a unique intersection between Software Engineers (SWE) and Solutions Architects (SA), a hybrid discipline combining technical depth with customer facing consulting skills.

In this article, I’ll address how SA/SWE professionals are uniquely positioned to excel in this emerging AI FDE space. It's not just about learning LLMs or Agentic AI. Frankly, that’s the easy part and can be done anyone. It's about translating the strengths that made you successful in your existing roles into a new domain.

Understanding the Forward Deployed Engineer

Forward Deployed Engineers are technical professionals who work directly at client sites or within specific business units, serving as the crucial link between engineering teams and end-users.

Unlike traditional engineers who primarily work within the confines of their own organization’s development environment, FDEs embed themselves in the operational context where technology meets real-world challenges.

Also, the FDE role represents a significant evolution from traditional customer-facing SA roles.

FDEs maintain a continuous, hands-on presence throughout the entire customer lifecycle. They don't just design solutions or oversee implementations. They actively participate in day-to-day operations, troubleshoot issues in real-time, and evolve systems based on actual usage patterns.

FDEs implement solutions using existing product capabilities, identify limitations or opportunities during deployment, and then contribute code and features back to the core product to address these gaps. They serve as both the implementer and the product developer, ensuring that products evolve in direct response to real-world customer needs rather than theoretical requirements.

The Rise of AI FDE roles

A LinkedIn search for AI FDE roles shows hundreds of roles in the London area alone from companies of all sizes.

Enterprise AI deployment is a $200B+ opportunity, yet majority of pilot projects stall at production. Why? Because shipping AI to production is not about model accuracy. It’s the same skill set that define the traditional role that ship software to production. That’s where roles of SA and SWE shine and FDE helps in closing the gap in AI world.

• Understanding customer reality (SA strength): Knowing why a customer wants AI, not just how to build it

• Shipping under constraints (SWE strength): Building RAG pipelines, agents, and APIs that actually work in production

• Bridging the gap (FDE strength): Translating ML capabilities into business language and managing expectations when demos look flashy but production is messy

The best AI FDEs we’re seeing are not AI researchers but they’re SA/SWE hybrids who learned the fundamentals of AI. That’s probably you!

The Strengths You Already Have (And How to Leverage Them)

If You’re an SA

Your superpower: Understanding customer ecosystems, discovering hidden requirements, and turning vague business pain into technical specs.

In the AI world: This becomes use case discovery. Instead of “build a CRM integration,” you’re asking: “Should we use RAG, fine-tuning, or agents? What data quality do we have? What’s the cost-accuracy tradeoff?”

Translate this by learning:

• LLM fundamentals (tokenization, context windows, temperature): The technical language of AI products

• RAG architecture: Why retrieval beats fine-tuning 80% of the time; how chunking and embeddings work

• Cost/latency tradeoffs: How to explain why a customer’s “perfect AI solution” needs 3 versions (fast/cheap, accurate/slow, balanced)

Your unfair advantage: You already know how to ask discovery questions. Most AI projects fail at discovery, not implementation.

If You’re an SWE

Your superpower: Shipping code under pressure, debugging production chaos, and building systems that scale.

In the AI world: This becomes production deployment. You’re building the infrastructure that keeps RAG pipelines, agents, and LLM services running at 99.9% uptime.

Translate this by learning:

• LLM APIs and libraries (OpenAI, Anthropic, LangChain): The frameworks for building with AI

• Vector databases and embeddings: The new infrastructure layer (Pinecone, FAISS, Weaviate)

• Deployment patterns: FastAPI + Docker + monitoring for LLM services (you’ve done this with REST APIs—LLMs just add complexity)

• Observability for AI: Tracking token costs, latency, and “hallucination” rates (your logging skills transfer directly)

Your unfair advantage: You understand production. You’ve debugged 3am outages. Most AI prototypes are still struggling with “why does the demo work but production fails?”. That’s your bread and butter.

The Knowledge Gap (It’s Smaller Than You Think)

Here’s what you do need to learn, and why it’s not as daunting as it seems:

Total ramp time: With to 5-8 weeks for dedicated ramp up you will be unstoppable.

What You Already Know That Transfers Directly

Your existing skills are more valuable in AI FDE roles:

Discovery & Listening → Identifying which LLM use case actually solves the customer’s problem

System Design → Designing RAG systems that handle 10M enterprise documents

Debugging Production Issues → Figuring out why the customer’s AI feature returns garbage

Cost Optimization → Understanding why token costs explode at scale

Stakeholder Management → Explaining why fine-tuning isn’t the answer to every problem

Documentation → Writing runbooks that help customers operate AI systems independently

Shipping Under Pressure → Prioritizing between accuracy, speed, and cost in 2-week sprints

These aren’t “nice-to-have” skills in AI FDE. They’re the primary differentiators. And you already have them. You just need to map them to AI Domain.

Your Learning Path

For AI FDE roles, you don’t need to go deep on ML theory. Go wide on understanding the AI fundamentals and shipping AI.

Timelines for each stage might very depending on your specific situation. Each Stage can be a week or month or more. But it’s definitely doable with consistent efforts.

Stage 1: AI Foundations + First Shipped Demo

• Spend 3-4 days on LLM fundamentals (tokenization, APIs, prompt patterns)

• Build a working chatbot (Streamlit + OpenAI) in a weekend

• Deploy it somewhere (Vercel, Render) and add monitoring

• Outcome: Your first “production AI” app (even if it’s simple)

Stage 2: RAG Deep Dive + Enterprise Architecture

• Learn embeddings, vector databases, and retrieval patterns

• Build a RAG system on real documents (PDFs, Notion, Slack exports)

• Deploy with FastAPI + authentication + cost tracking

• Outcome: You understand why RAG is the workhorse of enterprise AI

Stage 3: Agents + Customer Handoff

• Learn agent frameworks (LangChain agents, ReAct)

• Build an agent that integrates with a real API (Salesforce mock, Stripe, etc.)

• Write a complete handoff package (runbooks, troubleshooting, training)

• Outcome: You can build and hand off complex AI systems

Stage 4: Portfolio + Interview Prep

• Package your 3 projects into a case study portfolio

• Practice technical interviews (system design + field scenarios)

• Tailor your resume: emphasize discovery, production debugging, cross-team communication

• Outcome: Interview-ready for AI FDE roles!

The Behavioral Edge That Actually Matters

Here’s what separates the top 10% of AI FDEs from the rest:

Discovery mastery: You ask the right questions before coding. “What’s your data quality?” “Who owns this decision?” “What does success look like in 6 months?”

Bias toward shipping: You know that a working prototype beats a perfect design doc. You get feedback in production and iterate.

Production paranoia: You ask the questions most engineers don’t: What happens when the API fails? How do we monitor for hallucinations? What’s our rollback plan?

Stakeholder translation: You explain technical tradeoffs in business language. “We could use fine-tuning, but that costs $50K upfront and takes 6 weeks. RAG is ready in 2 weeks for $2K/month and we can iterate faster.”

Expectations management: You know that AI demos look perfect, but production is messy. You set realistic timelines and deliver on them.

These aren’t skills you need to learn. You already have them. You just need to apply them to AI.

The Honest Truth About the Transition

Getting into AI is not a career restart. It’s a lateral move using your existing strengths in a new domain.

You won’t be starting from zero. Your discovery skills, production debugging skills, and stakeholder management will get you there in 3-6 months.

The knowledge gaps are real but narrow. LLMs are new, but the patterns—retrieval, caching, observability, authentication—are old. You know these.

Your SA/SWE background is your competitive advantage. The market is hot for people who understand production, customers, and complexity. The only thing missing is a little bit of AI fluency.

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

This week we share a quick guide on demonstrating your AI-driven productivity in interviews.

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

AI questions have become standard in tech interview loops. Not because companies expect you to be an AI engineer. Because they want to know if you’ve adapted to how work is changing.

The problem: most candidates either undersell (”I use ChatGPT sometimes”) or overclaim (”I’m basically an AI expert”).

Both hurt you. Underselling makes you seem behind. Overclaiming invites follow-up questions you can’t answer.

This guide gives you what you need: what interviewers actually assess, how to answer at the right level for your role, and what to say if you haven’t used AI much.

Vamsi and I are hosting a FREE lightening talk on Friday, January 16th where we will dive deep into strategies for preparing for big tech interviews and have special offer for you to try the Revarta Platform.

Register for FREE interview prep session

What Interviewers Actually Assess

When interviewers ask about AI, they’re evaluating four things:

Adaptability: Are you someone who adopts new tools, or someone who resists change?

Critical thinking: Do you understand tradeoffs, or do you see AI as magic?

Judgment: Can you identify when AI helps versus when it creates problems?

Verification habits: Do you trust AI outputs blindly, or do you check what matters?

The subtext in every AI question: Are you the kind of person who will thrive as AI reshapes how we work?

Strong answers demonstrate all four. You’ve adopted AI (adaptability), you’ve learned what it’s good and bad at (critical thinking), you know when to use it and when not to (judgment), and you catch errors before they become problems (verification).

Example that hits all four: “I use AI to accelerate research and first drafts. What took 4 hours now takes 45 minutes. But I learned early that it’s confidently wrong about 15% of the time, so I built a verification step into my process. Now I know which outputs I can trust and which need checking. The biggest shift was realizing that how I structure my requests matters more than which tool I use.”

Three Levels of Answers

Not every role requires the same depth. Here’s how to calibrate.

Level 1: Safe and Competent

Use this if: You’re in a non-technical role, your company restricts AI, or you haven’t used it extensively.

Template: “I use AI for [1-2 specific tasks]. What I’ve learned is that it’s helpful for [type of work] but I always [verification step]. I’m continuing to explore [area you’re developing].”

Example: “I use AI mainly for drafting and brainstorming. It helps me get past the blank page faster. What I’ve learned is that I have to edit heavily. The AI writes generically, and my job is to add specifics and judgment. I treat it like a first draft from a junior colleague.”

Level 2: Strong and Differentiated

Use this if: You’re a PM, analyst, or operational role where AI literacy is expected.

Template: “I use AI for [specific tasks] with a deliberate process. The biggest mistake I made early on was [learning moment]. Now I [improved approach].”

Example: “I use AI for research synthesis and first drafts. The biggest mistake I made early on was trusting outputs without verification. I cited a fabricated statistic in a presentation. Now I verify any specific claim before using it externally. What I’ve learned is that how I frame the request matters more than which tool I use.”

Level 3: Technical Depth

Use this if: You’re an engineer or data scientist where deeper knowledge is expected.

Example: “I use different approaches depending on the task. For complex analysis, I use chain-of-thought prompting, asking the model to reason step by step. For company-specific information, I use a RAG-style approach, retrieving relevant documents as context rather than relying on training data. For any workflow I depend on, I build basic evaluations to measure whether my approach actually works.”

Role-Specific Guidance

Engineers/Architects

Show technical understanding and disciplined verification.

“I use Copilot daily, but with guardrails. It’s excellent for boilerplate and test scaffolding. For complex logic, I treat suggestions like code review comments—potentially useful, but requiring evaluation. I never commit code I can’t explain.”

Product Managers

Demonstrate that you use AI to accelerate PM work (research, specs, analysis) while thinking critically about limitations.

“As a PM, I use AI most heavily in discovery—synthesizing research, analyzing competitors, drafting specs. Where I don’t use it: prioritization decisions and stakeholder communications where nuance matters. What I’ve learned about AI products: impressive demos don’t equal reliable production use. When evaluating AI features, I focus on failure modes.”

Analysts

Emphasize verification habits, because analysis errors have consequences.

“I use AI to accelerate exploratory analysis—cleaning scripts, segmentation approaches, pattern identification. What I’ve learned: AI finds patterns but can’t determine which patterns matter. That requires business context. For any finding I plan to share, I trace back to raw data manually.”

Marketing / Non-Technical

Show adoption without naivety.

“I use AI for first drafts and ideation. It expands the options I consider. What I’ve learned: AI writes generically. The value I add is voice, specificity, and judgment about what resonates with our audience. I’m careful about facts—AI confidently makes things up.”

What to Say If You Haven’t Used AI Much

Maybe your company restricts AI tools. Maybe you haven’t had good use cases. Don’t panic.

Template: “I haven’t used AI extensively because [honest reason]. But I’ve [steps to learn]. My impression is [thoughtful observation].”

Example: “My current company has strict AI policies because of client data concerns. But I’ve experimented personally. I used AI to help analyze a home renovation project. My impression: it’s powerful for structuring information but requires verification and judgment. I’m curious what applications have worked well in this role.”

This is honest without being defensive. It shows intellectual engagement despite limited use.

Common Mistakes

Overclaiming: “I’m basically an AI expert” invites follow-ups you can’t answer. Be precise: “I’m a regular user with a reliable process” is credible.

Underselling: “I just use ChatGPT sometimes” makes you seem behind. Even modest use can sound thoughtful: “I’ve learned that quality depends on how specific I am about what I need.”

Making it your whole identity: You’re interviewing for PM or Engineer, not “AI User.” Weave AI naturally into stories. Lead with the business problem and outcome, not the tool.

Ignoring limitations: “AI handles everything” signals you haven’t used it seriously. Showing limitations builds credibility: “I learned to verify Y because it makes confident errors.”

Quick Reference

Before your interview, prepare:

• One specific example of effective AI use (with outcome)

• One thing you learned about AI’s limitations

• Your answer for “How do you verify AI outputs?”

In the interview:

• Match depth to role expectations

• Show judgment, not just usage

• Be honest about what you don’t know

• Lead with business impact, not the tool

The goal isn’t to sound like an AI expert. It’s to sound like someone who uses tools thoughtfully, learns from experience, and adapts as technology changes.

That’s what interviewers are actually assessing.

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

Vamsi is the founder of Revarta, an AI-powered interview practice platform. He’s conducted over 1,000 interviews at Amazon, Google, Nvidia, Adobe, and Remitly.

We are hosting a FREE lightening talk on Friday, January 16th where we will dive deep into strategies for preparing for big tech interviews and have special offer for you to try the Revarta Platform.

Register for FREE interview prep session

In this week's article, I'm sharing my goals for 2026 publicly with you all to keep myself accountable :)

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

Every end of year, there’s that moment where you sit down and think about what you actually want to accomplish in the next 12 months. Not the vague “be a better person” kind of goals, but concrete ones that make you slightly uncomfortable. That moment of honest reflection is what led to my 2026 list.

I’ve learned over the years that goals work best when they’re attached to something real - a passion, a metric you’re chasing, or a problem you’re obsessed with solving.

Here are the 10 goals I’m committing to this year.

Fair warning: I’m not expecting to hit all of them. But the process of pursuing them? That’s where the real work happens.

1. Continue Growing as an Individual Contributor

The Goal: Lead high-impact initiatives, mentor people, and scale my influence as an Individual Contributor (IC).

Every now and then, a conversation about career progression includes someone asking, “Don’t you want to become a manager?”

The impact you can make as a Manager is bigger, the career growth is faster, they say. I understand the appeal, but I’m at a stage where being an IC genuinely excites me.

My focus for 2026 is threefold: lead initiatives that outlast me, continue mentoring people in the organization, and find clever ways to scale my own impact.

This means being intentional about the projects I take on, selecting ones that solve real problems and create scalable solutions. It also means being a mentor who actually shows up for people, not just in 1-on-1s but in actively opening doors for them.

2. Grow LinkedIn Following to 50,000

The Goal: Increase from 42,000 to 50,000 followers (an addition of 8,000).

Current Status: I added 12,000+ followers last year, so hitting this target might seem like lowballing.. But it might actually be lofty.

LinkedIn’s algorithm has shifted dramatically toward AI content, videos, memes and selfies. The platform is flooded with AI-generated content, making it harder for thoughtful posts to gain traction. Growing by another 8,000 in this environment requires either going all-in on video/selfies/memes (not my style) and AI content (which doesn't feel authentic) or being incredibly strategic about what I share.

I'm going to keep this as my goal because it forces me to think about what kind of content actually resonates and whether I'm willing to adapt (and surpass the cringe mountain) without abandoning my voice.

3. Scale BeSA to 50,000 Participants

The Goal: Grow the free mentoring initiative, BeSA (Become a Solutions Architect), from 18,000+ to 50,000+ participants.

The Context: BeSA started in 2022, and after 8 batches over 4 years, we’ve reached over 18,000 people. That’s real impact. The next batch in Q1 2026 starts on February 21st, focusing on “Agentic AI on AWS”, a topic that’s incredibly timely.

Last year, we experimented with digital badges and certifications, and it was a huge hit. People wanted tangible proof of their learning. For 2026, we are doubling down on providing value through both technical and behavioral skills to help people upskill in their cloud and AI career journeys.

Growing to 50,000 participants is ambitious, but it’s tied to something I’m genuinely passionate about. Every person who goes through BeSA is someone working toward a more fulfilling career in tech. That’s worth pushing for.

As always, BeSA is going to remain FREE!

4. Scale Big Tech Careers Newsletter to 50,000 Subscribers

The Goal: Grow Big Tech Careers newsletter from 23,000+ to 50,000+ subscribers while maintaining weekly long-form articles.

Why Long-Form? I love writing detailed posts. Yes, it’s harder than churning out quick LinkedIn updates. Yes, it requires more bandwidth. But long-form writing forces me to actually think through what I believe and align my thoughts.

Currently sitting at 24K subscribers, I want to continue publishing one article every week and double the subscriber base. And yes, it’s staying free.

Writing helps me think, and sharing that thinking helps others. Win-win.

If you like to read long form articles on how to grow in your career using behavioral skills, please do subscribe.

Subscribe now

It will be a perfect symphony if I'm able to reach a 50K audience across LinkedIn, 50K learners on BeSA, and 50K readers on Big Tech Careers newsletter!

5. Fix the Weight Cycling Pattern Once and For All

The Goal: Stop the pattern of gaining and losing 8-10 kg per year. Build a sustainable approach to health and fitness.

The Real Talk: This is my most lofty goal, and I’m not afraid to say it.

For the last few years, I’ve been stuck in a cycle. I get into a good routine of eating healthy, working out consistently, sleeping well. Life is great. Then life happens. A big project deadline, personal chores, travel, stress, and suddenly the routine vanishes. I’m back to skipping workouts, eating poorly, losing sleep, and wondering why I’m back where I started.

The pattern itself isn’t the problem. The problem is that I treat routine as an on-off switch instead of something with flexibility built in.

This year, the goal is about building a system that survives chaos. Because life will happen. My focus has to be to stop letting it derail me completely. I need to normalize the ups and downs while maintaining a baseline of healthy choices.

6. Scale My Big Tech Interview Prep Course and Launch a Cohort Mentoring Program

The Goal: Build a career growth coaching program and turn my side hustle into real side income.

The Honest Part: This side hustle currently pays for the occasional nice meal. I’m passionate about it, but I chronically under-invest in it. Frankly, given other priorities, I don’t spend nearly enough time on this and I know it.

But I genuinely want to help people nail their interviews, get promoted and advance their careers. The gap between my passion and my actual effort is something I need to close.

Here’s where I’m being public about needing help: If you know how to scale online courses or coaching businesses, I want to work with you. I’m open to hiring the right people to help me build this. I’m also looking for partners or collaborators who can help me systematize what I’ve learned about career development into a successful business.

This goal is only achievable if I stop trying to do everything myself.

7. Publish the second edition of Cloud Career Journeys Book

The Goal: Complete and publish second edition of Cloud Career Journeys book.

The Context: I never thought I’d write a book, let alone two. After finishing the first one, I was convinced I’d never do it again. The process was exhausting. But then an opportunity came along that I was too passionate to pass up.

Here we are - working on second edition. A book is a legacy. It’s a way to reach people I’ll never meet and help them navigate their careers.

This time, the book will take a very special direction, one we as authors are deeply passionate about. We'll be exploring stories and lessons from a unique perspective that rarely receives enough attention in our industry.

We're also welcoming a brilliant third author to our team, whom we'll introduce soon. The truth is, this second edition wouldn't exist without their vision and the incredible amount of hard work they've been putting in behind the scenes since they first suggested the idea almost a year ago.

More details are coming soon, but this is real. It’s happening.

8. Get Back Into Running and Complete a Half Marathon

The Goal: Run Half Marathon in 2026.

The Backstory: I injured my ankle running the London Marathon a few years ago. I stopped long-distance running after that - partly caution, partly fear that it would happen again.

But running is when I think clearest. It’s therapeutic. I miss it.

This year, I’m reclaiming it. I’ve already booked the London Landmarks Half Marathon for April 6th. That gives me roughly 3 months to build from where I am now to running 21 kilometers. I’m slowly building momentum to hit 10K first, then scale up to the half marathon distance.

It’s ambitious but achievable. And more importantly, it’s something I genuinely want to do.

Sometimes goals aren’t about productivity or income. Sometimes they’re about reclaiming parts of yourself that got lost along the way.

9. Do Proper Financial Planning

The Goal: Stop procrastinating and create a comprehensive financial plan.

The Honest Part: I’ve been terrible at this. Years of procrastination. No excuses, just the reality that I’ve avoided it.

This year, I’m putting it on the list because sometimes the unsexy goals are the most important ones. Financial clarity reduces stress, opens up options, and gives you more freedom to pursue the things you actually care about.

10. Hit At Least 70% of These Goals

The Goal: Accomplish at least 7 out of 10 goals by December 31st 2026.

This meta-goal is more important than all the others combined.

I could have set 10 modest goals and likely crushed all of them. Instead, I’ve set goals that genuinely stretch me. Some are achievable with focus. Some require significant effort. Some depend on variables beyond my control (like LinkedIn’s algorithm, or how my body responds to training).

The real win will be the attempt itself. It’s being the kind of person who sets ambitious goals publicly, misses some, crushes others, and learns from all of it. Hitting 70% means I’ve pushed myself and made real progress on things that matter.

The Closing Thought

2026 is here. The goals are set. Some are modest. Some are genuinely lofty. And I’m under no illusions that all of them will happen exactly as planned.

Life will happen. Projects will shift. Priorities will change. New opportunities will come up. But that’s exactly why I’m putting this list out there. It’s a north star, not a rigid plan. It’s how I’m choosing to invest my time and energy this year.

If you’re setting goals for 2026, I’d encourage you to think deeply about your passions and realities and set accordingly.

Goals are about growth, not perfection. And growth is measured by movement, not by flawless execution.

Here’s to 2026. Let’s make it count.

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

When you are ready, here is how can I help you:

• Behavioral Interview preparation course. Use coupon code HAPPYNEWYEAR to get 30% off. Valid till 5th Jan 2026.

• 1:1 long term career coaching to help fast track your career growth

For more details, send email at info@bigtechcareers.com