Presentation and customer skills

What an AWS SA does

Start here, because half the loop checks whether you understand the job. Many strong engineers fail it by sounding like a consultant who will build the system, or a salesperson who will close the deal. The SA is neither.

Who does what around the customer

The interviewers will ask "who else would you bring in?" This table is the answer.

How SAs are measured

AWS does not publish SA goals. What is public: SAs file product feature requests and AWS says most of its roadmap comes from customer feedback. What SA write-ups and promotion guides describe (inference, not official):

• Technical wins and adoption. Workloads that land on AWS and grow because of your design work.
• Customer outcomes. Features shipped, launches that happened, problems solved.
• Influence on AWS. PFRs filed and championed, feedback that changed a service.
• Scaling yourself. Reusable content: blog posts, reference architectures, workshops, talks.

The programs and mechanisms you will use

You do not need to recite these. You need to know which one fits which moment. Checked against AWS pages in September 2026. Funding amounts and names change often.

Working Backwards

This is the heart of Bill's team. If you can run a working backwards session well, you are doing the job on day one.

The five customer questions

How you would run a 90-minute session with Beacon's product leaders

Before: send a two-line pre-read ("Bring one dispatcher story that went badly. Bring your top three AI ideas."). Ask for a product lead, an engineering lead, someone who has sat in a 911 center, and someone from compliance.

Sample press release: Beacon Dispatch Assist

Fictional, for practice. Read it aloud once. It takes about two minutes.

Beacon launches Dispatch Assist, a second set of eyes for 911 call-takers

Available today to Beacon CAD customers, including agencies that run in AWS GovCloud (US). Call-takers stay in control of every decision.

RIVERTON, OHIO, March 2027. Beacon today launched Dispatch Assist, a feature inside Beacon CAD that helps 911 call-takers code incidents and write call narratives while they are still on the phone.

A call-taker handling a medical call types, listens, and codes at the same time. New hires take months to learn hundreds of incident codes, and a wrong code can send the wrong unit. Supervisors spend hours each week fixing narratives before they go to records.

Dispatch Assist reads the call-taker's notes as they type. It suggests the incident code, shows known hazards at the address from the agency's own premise history, and drafts the narrative. The call-taker accepts with one keystroke or ignores it. Dispatch Assist never dispatches a unit and never contacts a caller. Every suggestion and every decision is logged for review.

"Our customers told us they did not want a robot dispatcher. They wanted help with the paperwork so they can listen to the caller," said Dana Ortiz, CEO of Beacon. "Dispatch Assist does that, and it runs inside the same secure environment their CAD already uses."

In a 90-day pilot at a county 911 center, call-takers accepted the suggested code on most calls and supervisors reported fewer narrative corrections. [Pilot numbers to be filled in from the real pilot.]

"On my third week, I had a caller describing chest pain and a fall. Dispatch Assist showed the right code and flagged a dog at the address. I still made the call, but I was not guessing," said a call-taker at the pilot center.

Agency administrators can turn on Dispatch Assist from the Beacon admin console, choose which call types it covers, and review a weekly accuracy report. Agency data stays in the agency's Beacon environment and is not used to train any model.

The presentation round

What to expect

Reports from candidates and prep sites agree on the shape, and disagree on the details. Plan for this and confirm with the recruiter:

• Length: 30 to 60 minutes in the slot, of which your talk is 20 to 30 minutes and the rest is questions. Several candidates describe a 1-hour presentation block inside a 5-hour loop.
• Topic: usually your choice: "present a project you delivered: the challenge, your architecture decisions, the outcome." Some teams give a scenario instead, or a written work sample. Some send a slide template.
• Audience: a mixed panel of SAs, an SA manager, sometimes an account manager. Treat them as a customer: part technical, part business.
• Interruptions: expected and deliberate. They push past your scope to see how you handle challenge without getting defensive.
• What they score: clear story (problem, constraints, decisions, outcome), technical depth that survives questions, and the ability to adjust to technical and non-technical listeners. Leadership Principles come up here too.

How to pick a topic

Recommendation: Ask the Declaration

Of your projects, askthedeclaration.com is the best fit for this panel, for five reasons:

1. It is a public sector problem. Citizens asking questions about a founding legal document. A wrong paraphrase of the law is worse than no answer. That is the exact fear of a 911 director or a permitting office.
2. It has a measured eval. A gold question set, retrieval accuracy, and a measured gap between real answers and off-topic questions that sets an abstain threshold. The v2 upgrade moved recall from 93.3 to 97.8 percent with hybrid search and a reranker.
3. It has real design trade-offs. Retrieval-only vs generative, on-device vs hosted, small vs large embedding model (you measured bge-base and rejected it), opt-in generation because groundedness was only about 61 percent on the fallback model.
4. It is live and public. You can open it on screen. It is a public repo. The launch post drew 55K+ views.
5. It translates to AWS for Beacon. The same design becomes Bedrock Knowledge Bases with hybrid search, a reranker, and a grounding check, for Beacon's permitting portal. That slide proves you can take a lesson to a customer.

Why not the others as the lead: the Kendra search at Prudential is your strongest production story, but you cannot show it, so it goes inside the talk as proof of scale (slide 9). PROBE is excellent but abstract for a mixed panel, so it is the backup. The Bedrock CRM prototype is small; use it in objection handling and behavioral answers.

Title and one-line promise

"Answers you can cite: building a GenAI feature that knows when to say I don't know."

"In 25 minutes I will show you a live app I built, how I measured it, what broke, and how I would build the same thing on AWS for a GovTech customer whose answers have to hold up in front of a city council."

Slide by slide (11 slides, about 25 minutes)

Slide 1. Title and why you should care (1 minute)

• Title, your name, one line: "I lead engineering teams in regulated financial services and I build GenAI apps on weekends."
• The promise sentence above.

"Every one of your GovTech customers wants AI. Most of them are afraid of one thing: a confident wrong answer with their logo on it. This talk is about that fear, and a design that answers it."

Slide 2. The customer and the problem (2 minutes, plus live demo)

• Customer: a citizen or student who wants to know what the Declaration or the Constitution says, without reading all of it.
• Problem: chatbots paraphrase and invent. For a legal text, a paraphrase is a liability.
• Live demo: ask one good question, then one off-topic question ("What is the best pizza in New York?") and show it declines.

"Watch the second question. It does not guess. That refusal is the most important feature in this app, and it is also the one I had to measure hardest."

Slide 3. Working backwards: the tenets (2 minutes)

• The press release sentence: "Ask a question in plain English and get the exact passage, with its source, in under a second."
• Four tenets, in order of priority: cite the source; say I don't know rather than guess; cost nothing per question; work offline.

"I wrote these tenets before any code. When two of them fight, the higher one wins. That is how I decided every trade-off you will see next."

Slide 4. Architecture v1 (3 minutes) Whiteboard here

• Draw it: passages chunked by structure, embedded once at build time, shipped with the app; query embedded in the browser with MiniLM via Transformers.js; cosine similarity; return top matches.
• No generation step. Service worker for offline.
• Trade-off table: retrieval-only (no hallucination, no per-query cost, cannot combine articles) vs generative (can synthesize, can invent, costs per call).

Slide 5. How I measured it (3 minutes)

• Gold set: questions paired with the correct passage, checked against the source text first.
• Metrics: top-1 and top-3 accuracy, answer retrieval, and the honesty gap: real answers scored 0.55 to 0.77 similarity, off-topic capped at 0.35. The abstain threshold sits in that gap.
• The eval runs the same model the browser runs, so you measure the shipped system.

"The number I care about most is not accuracy. It is the gap between 0.35 and 0.55. That gap is what lets the app say I don't know with confidence."

Slide 6. What was not good enough, and v2 (3 minutes)

• Pure vector search missed exact-word questions and some multi-part questions.
• Change: hybrid retrieval (BM25 keyword plus vectors) and a cross-encoder reranker (ms-marco MiniLM).
• Result: recall 93.3 to 97.8 percent; multi-hop slice 100 percent.
• Rejected: a bigger embedding model (bge-base). You measured it and it did not pay for its size in the browser.

Slide 7. Adding generation, carefully (2 minutes)

• Opt-in generation in the browser with WebGPU (Llama 3.2 1B via WebLLM), feature-detected, with a fallback.
• Groundedness eval: about 61 percent on the fallback model. Not good enough to be the default.
• Decision: generation stays opt-in and every answer shows the cited passages.

"This is the slide I would show a customer's legal team. We measured the generative answer, it was grounded about 61 percent of the time on the small model, so we did not ship it as the default. The data made the decision, not the demo."

Slide 8. The same design on AWS, for Beacon (4 minutes) Whiteboard here

Switch customers: Beacon's permitting portal. A resident asks "Do I need a permit for a 7-foot fence?" The answer must cite the county's ordinance, or say "call the permit office."

• Ordinances into S3, then a Bedrock Knowledge Base with a vector store that supports hybrid search (OpenSearch Serverless is the usual pick).
• Rerank the top passages with a Bedrock rerank model.
• Generate through the Converse API so the model can change without code changes.
• Guardrails contextual grounding check blocks answers not supported by the passages. Below threshold: decline and route to a human.
• The eval set runs in CI. A change that drops recall or grounding does not ship.
• Per-county data separation: one knowledge base or metadata filter per tenant.

Slide 9. I have done this in production (2 minutes)

• At Prudential you led an Amazon Kendra semantic search integration from POC to production for 35,000+ advisors, replacing keyword search and cutting 20+ steps from advisor workflows.
• Two lessons that carry to Beacon: permissions belong in the retrieval layer (a user only retrieves what they can see), and adoption needs time with the real users, not only good relevance.

"The weekend app taught me how to measure. The Prudential rollout taught me that a search nobody adopts is a failed project, so I spent real time with operations people until it fit their day."

Slide 10. How I would run this with a customer (2 minutes)

1. Week 1: working backwards session. One feature, one press release.
2. Week 2: build the eval set with the customer's experts (for permitting, 100 real resident questions with the right ordinance).
3. Weeks 3 to 4: prototype against the eval set. PACE or an EBA if the feature is strategic.
4. Week 5: Well-Architected review with the GenAI lens, security review, cost per question estimate.
5. Then the customer's team builds for production, with you on call for design decisions.

Slide 11. Close (1 minute)

• Three takeaways: measure before you ship; the ability to decline is a feature; design so the model can change.
• "I would love your questions, and especially where you would push back."

Timing plan

Ten likely interruptions, with answers

Backup topic: PROBE, measuring AI behavior

Use this if the panel wants something more enterprise, or if the Declaration demo cannot run. PROBE is live at framework.swapniltamse.com. Title: "Turning 'be fair' into a number you can defend."

Customer conversations

The panel may run a mock customer meeting, or ask "how would you start with a new ISV?" Your edge: you have sat on the customer side for 15 years. Use it. You know what it feels like when a vendor talks at you.

Discovery questions: CTO vs engineering lead

How to run a first meeting

1. Before: read their website, product docs, public case studies, job posts (they reveal the stack), and any AWS account notes. Talk to the account manager for 15 minutes.
2. Open (5 min): introductions, confirm the time, and agree the goal. "My goal today is to understand where you are going, and leave with one next step we both think is worth doing."
3. Listen (25 min): discovery questions. Take notes in their words. Ask one follow-up for every answer.
4. Reflect back (5 min): "What I heard is... did I get that right?" This is where trust starts.
5. Offer (10 min): one or two ideas, each with a trade-off. No slides unless they ask. A quick whiteboard is fine.
6. Close (5 min): one concrete next step with an owner and a date. For example, a working backwards session in two weeks.
7. After (same day): a short email with what you heard, the next step, and anything you promised. Then do what you promised.

Beacon's portfolio, sorted:

Objection handling

The pattern for every objection has four steps. Practice it until it is automatic.

1. Acknowledge. Say the concern back. It is almost always reasonable.
2. Ask. One question to find the real concern under it.
3. Answer with a mechanism. A specific control, number, or design, not a promise.
4. Offer a next step. Small, concrete, low risk for them.

Influence and hard moments

These map to Leadership Principles like Earn Trust, Have Backbone; Disagree and Commit, and Customer Obsession. Keep each answer calm, specific, and short.

Telling a customer no

Setup: Beacon's product VP wants the benefits portal to auto-approve or deny applications with AI, to cut backlog.

"I understand the backlog is hurting families and your customers. I want to help with that. I cannot recommend an AI that makes the final decision on someone's benefits. When it is wrong, a family loses support, and you will not be able to explain why to a state auditor."

"Here is what I can help you build this quarter: the AI reads the application and documents, checks for missing items, and prepares a summary with the rules it thinks apply and why. The caseworker decides in two minutes instead of twenty. Same backlog relief, and a human owns every decision."

Disagreeing with an AWS service team

Setup: the service team says the GovCloud feature Beacon needs is "not a priority." You believe it affects many GovTech ISVs.

"I understand you have to rank this against many requests. I want to make sure you have the full picture. Beacon alone covers 40 agencies that require GovCloud [example], and I have heard the same ask from two other GovTech ISVs this quarter. The workaround costs them a lower-accuracy model and a split code path."

"Could we get 30 minutes with the PM and one customer engineer? If after that it still is not a priority, I will tell the customers plainly and help them plan around it."

That is Have Backbone; Disagree and Commit. You push with data, then you commit and help the customer work around it.

Escalating a blocker

Setup: Beacon's quota increase for a Bedrock model in GovCloud has been stuck for two weeks. Their launch is in three.

1. Do the homework first: case numbers, what was tried, dates, the business impact in one line.
2. Tell the customer what you are doing and when they will hear from you.
3. Escalate through the right path with your manager copied: account manager, then the service team or support escalation.
4. Write it in three lines: what is blocked, what it costs, what you need by when.

"Blocked: Beacon's Bedrock quota increase in GovCloud West, case open 14 days. Impact: launch to 12 agencies on October 30 slips. Ask: a decision by Friday, or a clear no so we can plan the fallback model."

A customer executive who is angry

Setup: Beacon's CEO calls. Dispatch Assist gave a wrong suggestion in a live demo at a sheriffs' conference, in front of a customer. She says "your AI embarrassed us."

1. Let her finish. Do not defend or explain in the first two minutes.
2. Acknowledge the impact, not blame: "That was in front of a customer. I understand why you are angry."
3. Get facts: "Can you tell me exactly what happened? What was typed and what it suggested?"
4. Commit to a specific next step and time.
5. Follow up before the time you promised.

"I am sorry that happened in front of a customer. I want to understand it fully. Can you send me the input and what it showed? By tomorrow at noon I will have my team and yours look at it and tell you whether it was retrieval, the prompt, or the model, and what we change."

"For the next demo, I suggest we run it on a fixed set of scenarios we have tested, and show the confidence score and the human accept step on screen. That turns a scary moment into your best trust story: the call-taker is always in charge."

Role-play drills

Practice these out loud, ideally with someone playing the customer. Set a timer. Record yourself once and listen back for filler and for how soon you start talking about AWS services.