AWS SysDE II Virtual Onsite
Preparation Guide

Schedule

Interviewer profiles

The STAR-R shape

1. 1
   Situation - one or two sentences. The context, the stake, the constraint. Keep it tight; do not bury the story.
2. 2
   Task - what you personally owned. Name your responsibility, not the team's.
3. 3
   Action - the meat. What you did, in order, with the trade-offs you made. Use "I" and concrete verbs.
4. 4
   Result - the number. A measurable outcome: latency, error rate, devices, cost, revenue, time saved.
5. 5
   Reflection - what you learned and what you would do differently. This answers "what did you take away" before it is asked.

Principles matrix

The table maps each Leadership Principle to a company to anchor your story. These are starting points - pick the story that is strongest and most real, not the one that looks best on paper.

Tailored story banks

TCP/IP

# See the handshake and any retransmits on port 443
sudo tcpdump -ni eth0 tcp port 443

# Show established sockets and their state
ss -tlnp

# Show retransmits and out-of-order segments specifically
sudo tcpdump -ni eth0 "tcp[13] & 8 != 0"

BGP

DNS

# Full resolution path, shows the TTL and the server that answered
dig +trace example.com

# Ask a specific server directly, bypass the cache
dig @8.8.8.8 example.com

# Show what is cached locally
resolvectl query example.com

Load balancing

End-to-end troubleshooting

# 1. Does the name resolve?
dig +short example.com

# 2. Can you reach the host at the network layer?
ping -c 3 example.com

# 3. Where does the path stop?
traceroute -n example.com

# 4. Is the port open and serving?
nc -vz example.com 443

# 5. What round-trip time and retransmits are happening?
curl -w "connect: %{time_connect} ttfb: %{time_starttransfer} total: %{time_total}" -o /dev/null https://example.com

A design skeleton that works for all three

1. 1
   Clarify - restate the problem, then ask: what is the write rate, the read rate, the durability target, the blast radius of a failure?
2. 2
   Estimate scale - put real numbers on the table: devices, samples per second, retention, query load. Say the numbers out loud and sanity-check them.
3. 3
   Draw the data flow - producers, ingestion, storage, consumers. Label each hop and what it buffers or drops.
4. 4
   Design for failure - what happens when a node dies, a zone goes down, a device goes offline? That is the design, not the afterthought.
5. 5
   Close the loop - monitoring, alerting, and the feedback that makes the system self-healing.

Telemetry pipeline

agents (batch)  ->  ingestion (buffer)  ->  storage (tsdb)  ->  query
     |                        |                     |
  sample lost?            backpressure?          downsam + retention

Device fleet management

Manufacturing infrastructure

What they are testing

• Read input defensively - never assume the shape of a line or a record.
• Prefer generators / streaming over loading everything into memory.
• Make every script idempotent - running it twice is safe.
• Fail loudly: print the error and the context, then exit nonzero.
• Keep it readable: name things, split functions, no clever one-liners.

Python - streaming a log

import sys, re
from collections import Counter

pattern = re.compile(
    r"^(?P<ts>\S+) \S+ (?P<level>\w+) (?P<msg>.*)$"
)

def main():
    counts = Counter()
    for line in sys.stdin:
        line = line.rstrip("\n")
        m = pattern.match(line)
        if not m:
            # never crash on a bad line - report and keep going
            print(f"skip: {line!r}", file=sys.stderr)
            continue
        counts[m.group("level")] += 1
    for level, n in counts.most_common():
        print(f"{level}: {n}")

if __name__ == "__main__":
    main()

Bash - idempotent orchestration

#!/usr/bin/env bash
set -euo pipefail

# Idempotent: only act if the target is missing
ensure_dir() {
  local dir="$1"
  if [[ ! -d "$dir" ]]; then
    mkdir -p "$dir"
  fi
}

# Fail loudly with context
restart_service() {
  local svc="$1"
  if ! systemctl restart "$svc"; then
    echo "failed to restart $svc" >&2
    return 1
  fi
}

ensure_dir /var/lib/app
restart_service app

LiveCode tips

• Say the plan before the code: 'I will read the stream, filter, then aggregate'.
• Write the happy path first, then add error handling - do not front-load edge cases.
• Narrate your reasoning as you type; silence reads as uncertainty.
• If you hit a wall, say what you are considering and why, then pick one.
• Finish with a self-review: what would you change, and what would you test?

cgroups & namespaces

procfs

# What is the process doing right now?
cat /proc/$(pgrep -f mydaemon)/status

# Where are its file descriptors pointing?
ls -l /proc/$(pgrep -f mydaemon)/fd

# Memory pressure at a glance
cat /proc/meminfo | head

strace & perf

# What syscalls, and where is it stuck?
strace -f -p $(pgrep -f mydaemon) -e trace=network

# Where is the CPU going?
perf record -g -p $(pgrep -f mydaemon) -- sleep 10
perf report

systemd & journalctl

# What is the state?
systemctl status app.service

# What did it log, from the last boot?
journalctl -u app.service -b

# Follow it live while you reproduce
journalctl -u app.service -f

The troubleshooting order

1. 1
   Is the process alive and in the right state? (ps, systemctl status)
2. 2
   What is it doing right now? (strace, /proc/PID/status)
3. 3
   Where is the CPU / memory / I/O going? (perf, systemd-cgtop)
4. 4
   What did it log? (journalctl)
5. 5
   What changed since it last worked? (deploy, config, network, resource limits)

The incident lifecycle

1. 1
   Detect - the alert fires. What metric, what threshold, what blast radius? Good detection is a question of coverage and signal, not noise.
2. 2
   Triage & page - who owns it, what is the severity, who is on the bridge. A clean handoff beats a heroic solo.
3. 3
   Mitigate - stop the bleeding first: roll back, fail over, drain, throttle. Mitigation is not the fix; it is buying time.
4. 4
   Communicate - status to stakeholders in plain terms: what is down, what is being done, what the ETA is. No jargon, no blame.
5. 5
   Resolve & verify - confirm the system is actually healthy, not just quiet.
6. 6
   Postmortem - a blameless write-up: timeline, root cause, contributing factors, and concrete actions. The goal is the next incident is shorter, not who to blame.

Metrics that matter

Scenario cards

Before you start

• Sleep properly the night before - the bar raiser rewards a rested mind.
• Set up your space and test audio, video, and a stable connection an hour early.
• Have water, a notepad, and a pen within reach.
• Open your STAR story bank and your system-design skeleton as reference, not to read from.

During the loop

• Answer every behavioral question in the STAR-R shape, with a real number.
• In design and coding, say your plan before you commit to it.
• When you do not know, say so plainly and reason to the answer - honesty reads as confidence.
• Pace yourself: five sessions is a marathon. Breathe between them.
• Ask at least one sharp question in every session - it signals genuine interest.

Ask the interviewers

• What does a typical week look like for a SysDE on Manufacturing Infrastructure Services?
• What is the biggest operational challenge the team is facing right now?
• How does the team balance on-call load with feature work?
• What does success look like in the first six months in this role?
• What is the team building next, and what is the hardest part of it?

Practice against these

• Walk me through how you would design telemetry for a fleet of 100,000 devices.
• A device is not reporting. How do you isolate whether it is the device, the network, or the pipeline?
• Write a script that parses a log and reports the top error by frequency, idempotently.
• A service is slow after a deploy. What is your troubleshooting order?
• Tell me about a time you owned an incident end to end. What did you do, and what did you learn?
• How would you roll out a firmware update to a device fleet without breaking the field?

• Amazon Leadership Principles
• AWS Well-Architected Framework
• RFC 793 - Transmission Control Protocol
• RFC 4271 - A Border Gateway Protocol 4
• RFC 1035 - Domain Names - Implementation and Specification
• Linux man pages
• AWS Systems Manager - fleet management
• AWS IoT - device fleet management