8. My Role as a Senior Developer at Amazon

Role Summary

As a Senior Software Development Engineer (SDE-III) on the MangaAssist project, I am not just writing code — I am the technical owner of a critical subsystem and a force multiplier for the entire team. My job is to make the right technical decisions, ship reliable software, and ensure the team moves fast without breaking things.

Ownership Areas

graph TD
    subgraph "I Own Directly"
        A[Chatbot Orchestrator<br>Service Design & Implementation]
        B[API Contracts<br>All service interfaces]
        C[RAG Pipeline<br>Architecture & Integration]
        D[System Architecture<br>End-to-end design]
    end

    subgraph "I Influence / Review"
        E[Intent Classifier<br>Integration & latency requirements]
        F[Frontend Chat Protocol<br>WebSocket contract]
        G[Guardrails Pipeline<br>Rules & validation logic]
        H[Data Pipeline<br>Event schema & analytics]
    end

    subgraph "I Delegate"
        I[Frontend Widget<br>to FE Engineers]
        J[ML Model Training<br>to Applied Scientists]
        K[Infrastructure / CI-CD<br>to DevOps]
        L[Dashboard & Reporting<br>to Data Engineers]
    end

What I Personally Build

1. Chatbot Orchestrator (Core Service)

This is the brain of the system. I write the orchestration logic because it touches every subsystem and requires deep understanding of the full architecture.

Specifically, I: - Design the state machine that routes intents to services. - Implement parallel fan-out to recommendation, catalog, and RAG services. - Build the prompt assembly logic (combining context, history, retrieved data, and system instructions). - Implement timeout, retry, and circuit breaker patterns for each downstream dependency. - Write the conversation memory management (DynamoDB read/write, summarization triggers).

2. API Contracts

I define every API contract between services before anyone writes implementation code.

Why me: API contracts are the hardest thing to change later. A wrong contract creates months of tech debt. As the person who sees the full system, I'm best positioned to get the interfaces right.

Deliverables: - OpenAPI specs for /chat/message, /chat/init, /chat/feedback, /chat/escalate. - Internal service contracts: Orchestrator → Intent Classifier, Orchestrator → Recommendation Engine, Orchestrator → RAG Pipeline. - WebSocket message protocol (frontend ↔ backend).

3. RAG Pipeline Architecture

I design and build the retrieval-augmented generation pipeline because it's the core differentiator — bad RAG means wrong answers.

Specifically, I: - Choose the embedding model and chunk strategy. - Design the indexing pipeline (what gets indexed, how often, what metadata to attach). - Implement the retrieval + reranking logic. - Tune the prompt template that combines retrieved chunks with user context. - Build the evaluation harness to measure retrieval quality (recall@k, answer accuracy).

What I Delegate

Cross-Team Collaboration

With Product Manager

• Translate vague requirements into technical specs.
• Push back on scope when needed ("That's V2, not MVP").
• Propose A/B experiments for measuring chatbot impact.
• Jointly define success metrics.

With Applied Scientists

• Provide real user queries for training data.
• Set latency budgets they must work within (intent classification < 50ms).
• Review prompt engineering approaches.
• Co-design the evaluation framework.

With UX Designer

• Explain what's technically feasible for streaming, product cards, and quick chips.
• Provide constraints: "We can show 3–5 products per response, not 20."
• Review designs for technical feasibility before implementation.

With Amazon Catalog / Order / Recommendation Teams

• Negotiate API access and SLAs.
• Define what data we need and in what format.
• Handle dependency risks (what if their service is slow or down?).

With Amazon Customer Service Team

• Design the escalation handoff protocol.
• Define what context is passed to human agents.
• Agree on SLAs for handoff.

Technical Leadership Responsibilities

Architecture Decisions

I make (or approve) every significant technical decision: - Use DynamoDB (not Redis) for conversation memory — why: managed, durable, TTL built-in. - Use WebSocket (not SSE) for streaming — why: bidirectional, better mobile support. - Use a two-stage intent classifier (rules + ML) — why: fast, cheap, accurate enough for MVP. - Use OpenSearch Serverless (not Pinecone) for RAG — why: stays within AWS, managed, IAM integration.

Each decision is documented in a design doc with alternatives considered, trade-offs, and a clear recommendation.

Code Review

I review every PR that touches: - The orchestrator service. - API contract changes. - Prompt templates. - Guardrail rules. - Database schema changes. - Anything that touches PII or security.

Mentoring

• Pair-program with junior engineers on complex integration points.
• Run weekly architecture office hours.
• Write internal wiki documentation on "how the chatbot works end-to-end."
• Conduct post-mortems after incidents and turn them into learning opportunities.

Operational Excellence

• Write the runbook for the chatbot service.
• Define on-call procedures and escalation paths.
• Set up alarms for: P99 latency > 5s, error rate > 1%, guardrail block rate > 10%.
• Own the weekly operational review (WBR metrics).

Metrics I Own

Handling Ambiguous Requirements

Amazon is famous for "working backwards from the customer." When requirements are unclear, I:

1. Write a one-pager clarifying my understanding and share it with PM.
2. Build the simplest version first and get feedback.
3. Use data to resolve debates — if we're unsure whether users want proactive recommendations, we A/B test it.
4. Bias toward reversible decisions — choose options that are easy to change later.
5. Escalate when needed — if two teams disagree on an API contract, I bring it to the manager with a recommendation.

Driving Launches

For launch, I own the launch readiness checklist:

• All services deployed and healthy
• Load test passed at 2x expected traffic
• Guardrails tested with adversarial inputs
• Runbook reviewed by on-call team
• Dashboards and alarms in place
• Feature flag configured for gradual rollout (1% → 10% → 50% → 100%)
• Rollback plan documented and tested
• PM sign-off on metrics and success criteria
• Legal/compliance review complete (PII handling, content moderation)

My Role in This Project — Full Picture

Beyond the technical ownership described above, my role as SDE-III on MangaAssist covers three interlocking dimensions: building, leading, and growing the team.

What I Build

I personally write the hardest, highest-risk code — the orchestrator, the RAG pipeline, and all API contracts. I write this code not because no one else can, but because mistakes here cost months to fix. Every other service depends on these foundations being correct.

What I Lead

I make every significant technical decision and document the reasoning. I own cross-team negotiations (catalog, orders, recommendations, CS teams). I drive launch readiness and own the post-launch operational metrics. When something breaks at 2am, I'm the escalation point for the on-call engineer.

What I Grow

Every interaction with a junior engineer or intern is a coaching opportunity. The measure of a senior engineer at Amazon is not just what they ship — it's how fast the engineers around them improve.

Guiding Interns

Amazon routinely has interns (SDE interns, ML interns, research interns) join product teams like MangaAssist. As the senior engineer, I am the primary technical mentor for any intern on my team.

How I Onboard an Intern

gantt
    title Intern Onboarding Timeline (12-week internship)
    dateFormat  WEEK
    section Week 1-2 - Foundation
    System walkthrough & architecture doc read    :w1, 1w
    Dev environment setup + first PR (minor bug fix) :w1, 1w
    Shadow code reviews and design discussions       :w2, 1w
    section Week 3-4 - Ramp-Up
    Assigned intern project scoped and spec'd        :w3, 1w
    First feature implementation begins              :w4, 1w
    section Week 5-10 - Execution
    Core project development + weekly 1:1s           :w5, 6w
    Mid-point check-in and scope adjustment          :w7, 1w
    section Week 11-12 - Wrap-Up
    Demo prep + final PR review                      :w11, 1w
    Intern presentation + return offer recommendation:w12, 1w

What Projects I Give Interns

Intern projects on MangaAssist are real, production-bound features — not toy projects. But they are scoped to be self-contained so the intern can own them end-to-end.

How I Review Intern Code

My code review approach with interns is different from how I review senior engineers:

With a senior engineer: I write concise comments and expect them to know why.

With an intern: - I write the comment and the explanation. Example: "Use Decimal here instead of float because DynamoDB's Number type is precise; Python floats introduce rounding errors." - I tag comments as [must fix], [suggestion], or [learning note] so they know what's blocking merge vs. what's educational. - I never reject a PR without pointing to a specific resource (code example, internal wiki page, AWS doc). - I approve their PRs after no more than 2 review rounds — if something still isn't right on round 3, I pair-program through it rather than iterate on comments.

How I Set Interns Up for Success

Before Week 1: - I pre-scope the project with clear acceptance criteria. - I write a starter doc: system context, links to relevant code, list of services they'll touch. - I ensure their dev environment provisioning request is filed before they arrive.

During the internship: - I never give them a blocker and walk away. If they're stuck on IAM permissions, AWS CDK config, or a confusing API, I unblock them within 24 hours. - I involve them in one real design review to expose them to how senior engineers think through tradeoffs. - I cc them on relevant architecture decisions so they see the reasoning, not just the outcome.

What I do NOT do: - I don't assign them tasks that are "nice to have" and would never ship. Their work goes to production. - I don't pair-program for them — I pair-program with them. There's a difference. - I don't wait until week 12 to give feedback. Feedback is weekly and specific.

Intern Assessment Framework

At Amazon, the return offer recommendation carries real weight. I write my recommendation based on four dimensions:

Example: What a Strong Intern Interaction Looks Like

Situation: Intern is building the feedback pipeline. They come to the weekly 1:1 and say: "I stored the feedback in DynamoDB with userId as the partition key. But I'm not sure how to query all feedback for a given mangaId."

What I do: 1. Ask: "What's your access pattern — do you need to query by mangaId frequently, or is this for an offline analytics job?" 2. Explain the problem: "A GSI on mangaId would work for frequent queries, but if this is just analytics, scanning via Kinesis → Redshift is cheaper and simpler." 3. Let them decide: "Given your project scope, which option makes more sense? Let's think through the tradeoffs." 4. Follow up next week: "Did the approach you chose hold up, or did you hit any edge cases?"

This is the pattern I follow: ask → explain → let them decide → follow up. I don't hand them answers. I hand them frameworks.

Summary: What "Senior" Means on This Project