Access Home Lab Solutions LLP Software Engineer Interview Guide

The 60-second brief

Access Home Lab Solutions LLP is described by candidates as a company working at the point where software meets healthcare and laboratory operations. The reported work involves medical data and the workflows around it, including internal tools for medical coding and analysis. The Software Engineer role is described as spanning cloud infrastructure, automation and data pipelines, with Python named as the likely working language. Candidates also describe collaboration with operations managers, code reviews and troubleshooting network-related performance problems. Nothing reported names specific products, customers or a team structure, so treat the stack as Python plus AWS or GCP and the domain as clinical and laboratory data.

This guide is for candidates interviewing for the Software Engineer role at Access Home Lab Solutions LLP. It follows the three reported stages (Recruiter Screening, Technical Assessments, Interviews with Leadership) and covers the three question families candidates report: Python coding and concurrency, cloud and network troubleshooting, and medical-domain knowledge such as medical coding, HCC coding, anatomy, physiology and pathology.

Candidates report three stages, a recruiter screening, technical assessments and interviews with engineering managers or operations leadership, spread over roughly three to five weeks.

Focus areas

• Python
• Coding Practice / Writing Code in Interviews
• Networking Fundamentals

Overview

The reported role is a mix that most software loops do not combine. Candidates describe day-to-day Python development alongside cloud infrastructure work, network troubleshooting and code reviews, all in service of laboratory and medical workflows. The requirements candidates list put Python (or a comparable high-level language), data structures and algorithms, clear communication and a methodical approach to debugging as must-haves. Healthcare experience, AWS or GCP hands-on time, and multithreading or multiprocessing are listed as nice-to-haves.

The reported questions follow that shape. Four are about code and concurrency: your strongest language, a Python program that shows your style, a basic Python task, and how you approach multithreading and multiprocessing. Three are about cloud and networking: the role of an AWS engineer, real-time network troubleshooting and configuration, and AWS versus GCP in production. Five are about the medical domain: medical coding or HCC coding, human body systems in a clinical context, anatomy, physiology and pathology, and how medical terminology shapes software design.

Prepare in that order of certainty. The coding and concurrency material is where you can be fully ready: write clean Python, know when threads help and when processes are needed, and be able to explain each choice. The cloud and network questions reward a repeatable method more than memorised facts. For the medical questions, you cannot become a clinician in a week, so aim for working vocabulary, an understanding of how coded data moves through software, and a plain statement of what you have not done. Candidates report a tip that honesty and a logical approach beat guessing on a specialised question, so rehearse saying what you know, what you would check and how you would find out.

Because the loop ends with managers or operations leadership, practise explaining technical decisions to a non-engineer. Have two or three stories ready about conflict, deadlines and collaboration, and one honest answer about your exposure to healthcare data.

The Access Home Lab Solutions LLP interview process

Candidates describe three stages over roughly three to five weeks. The descriptions below are what candidates report, plus how to prepare for each kind of stage.

Recruiter Screening

Candidates describe the first stage as a recruiter screening: an early conversation about your fit and about the role itself. Nothing specific is reported about its format, so treat it as a short, mostly conversational stage where your summary of yourself has to be tight. The role mixes Python, cloud work and a healthcare setting, so the useful preparation is deciding in advance how you will describe each of those three honestly, including where you have no experience.

What to demonstrate

• Fit for a role that combines software engineering with a healthcare and laboratory setting
• How clearly you describe your background and your strongest programming language
• Whether your experience lines up with the reported must-haves: Python or a comparable language, data structures and algorithms, debugging

How to prepare

• Write a short career summary that names your main language, one project with real Python or backend work, and any cloud (AWS or GCP) exposure.
• Decide your honest one-sentence answer on healthcare or medical-coding exposure, and a follow-on sentence about how you would learn the vocabulary.
• Prepare a clear reason for this domain, since the role is tied to medical and laboratory workflows rather than a generic product.
• List your constraints and questions for the later stages so you can ask what the technical and leadership stages will cover.

Technical Assessments

Candidates describe this stage as an evaluation of technical capability for the position. The technical themes reported for the loop are Python proficiency, concurrency, and cloud and network infrastructure, and the topic mix candidates list includes Python, writing code in interviews, networking fundamentals and multithreading. Expect to write code, explain your choices, and reason aloud through an infrastructure scenario. Because the reported coding task is described as a basic Python problem, correctness, clarity and testing matter more than exotic algorithms.

What to demonstrate

• Working Python code: core language features, standard library use and readable structure
• Concurrency judgement: threads versus processes, shared state and where races appear
• Cloud and network reasoning: how you narrow down a connectivity or performance fault
• Clear explanation of the trade-offs behind your choices

How to prepare

• Write three small Python programs from scratch (a parsing task, a grouping or counting task, a string or list task), each with a few tests, and talk through them aloud.
• Build one demo that runs the same job with threads, a process pool and sequentially, and be ready to explain the timings using the GIL.
• Write a layered checklist for network troubleshooting (name resolution, reachability, ports, routing, firewall or security rules, application) and practise applying it to an invented outage.
• Make a one-page table of AWS and GCP equivalents for compute, storage, networking, identity and monitoring, with one real difference you can defend.

Interviews with Leadership

Candidates describe the final stage as discussions with engineering managers or operations leadership. The role involves translating operations managers' needs into software, so this is where explaining your work to people who are not engineers is most likely to matter. Candidates also report behavioral questions about conflict, deadlines and team collaboration, and the medical-domain questions belong to the same loop, so be ready to talk about healthcare exposure and learning plans in plain language.

What to demonstrate

• Fit with engineering and operations leadership
• Communication with both technical peers and operational managers
• How you handle conflict, deadlines and collaboration, as candidates report these themes
• Interest in and readiness to learn the medical and laboratory context

How to prepare

• Prepare three stories in a situation, action, result shape: a disagreement, a deadline that slipped or tightened, and a time you did not know something and found out.
• Practise explaining one technical decision (a data structure, a concurrency choice, a cloud service) to a non-engineer in plain language, covering the cost of getting it wrong.
• Rehearse a truthful answer on medical coding or HCC coding that states your exposure, shows what you understand, and names your first steps to learn more.
• Write questions to ask about how engineering and operations work together on lab workflows and how code reviews run.

Where candidates lose points

Bluffing on a specialised medical or infrastructure question instead of saying where your knowledge ends

Use a three-part answer: what you know for certain, how you would check the rest, and who or what you would consult. Candidates report that honesty with a logical approach is preferred over guessing, and this loop includes anatomy, pathology and HCC coding questions where a confident wrong answer is easy to give.

Answering the question about writing a Python program that shows your coding style with one long unstructured script

Pick a small, realistic task such as parsing and summarising records. Use functions with clear names, type hints, a docstring, sensible handling of bad input and a few tests, then explain why you chose a dict, a set or a generator. Style is shown by choices you can explain, not by length.

Saying threads make things faster without mentioning the GIL, shared state or process boundaries

Split the answer by workload. For waiting on network or disk, threads (or asyncio) help even in CPython. For CPU-bound work, use a process pool because the GIL blocks parallel bytecode in threads. Mention locks or queues for shared state, and the pickling cost of passing data between processes.

Troubleshooting a network problem by changing settings at random or restarting services

Work through the layers in order and say what each check rules out: DNS resolution, reachability, port and protocol, routing, firewall or security-group rules, then the application. Ask what changed recently and confirm your tooling output before trusting a symptom.

Treating the clinical questions as irrelevant to an engineering role, or reciting jargon with no link to software

Learn a small working vocabulary and always connect it to design: terminology becomes code sets and controlled vocabularies, body systems become categories and groupings, and sensitive clinical data needs careful access, validation and traceability.

Questions & practice

What programming language are you most comfortable with?

Medium · Technical Proficiency & Coding

Approach

1. Name one language and commit to it; for this role that is usually Python. Back it with evidence: a project you shipped, the Python version, and the libraries you used daily (for example pytest, requests, pandas, SQLAlchemy).
2. Show you understand the data model: names are references to objects, lists and dicts are mutable while tuples and strings are not, so passing a list into a function and appending to it changes the caller's list.
3. Quote the costs you rely on: dict and set lookups are O(1) on average, list.append is amortised O(1), list.insert(0, x) and x in list are O(n), and sorted() is Timsort at O(n log n) and stable.
4. Mention the tooling around the language: virtual environments, dependency pinning, type hints checked by mypy, a formatter and linter, and tests in pytest.
5. Close with an honest limit: the area you know less well (for example C extensions or async internals) and how you would close the gap.

Follow-up

• What is the difference between a list and a tuple, and when do you choose each?
• Why is a mutable default argument such as def f(x=[]) a bug, and how do you fix it?
• What is the GIL in CPython, and when does it affect your code?

Write a Python program of your choice that demonstrates your coding style.

Medium · Technical Proficiency & Coding

Approach

1. Pick a small program with real input handling, for example: read a CSV of test results, validate each row, and print per-category counts and averages. It shows parsing, validation, aggregation and error handling in under a hundred lines.
2. Structure it as typed functions with docstrings, a dataclass for a parsed record, argparse for the input path, pathlib for files, and an if name == "main": guard so the module can be imported and tested.
3. Stream the file with csv.DictReader inside a with block and aggregate in one pass into a dict or collections.defaultdict: O(n) time and memory proportional to the number of groups, not the number of rows.
4. Decide what a malformed row does (skip and count it, or fail fast with the line number) and say why; never swallow exceptions with a bare except.
5. Ship a few pytest cases: an empty file, a header-only file, a row with a missing or non-numeric value, and a normal file whose expected totals you computed by hand.

Follow-up

• How would the program change if the input file were 20 GB?
• How would you test the malformed-row path without touching the filesystem?
• What would you change to turn this script into a reusable library module?

Can you solve this basic Python programming task provided by the interviewer?

Medium · Technical Proficiency & Coding

Approach

1. Restate the task and pin down the input and output before writing code: types, whether input can be empty, duplicates, negative numbers, case sensitivity and Unicode for strings.
2. Recognise the common shapes of a basic Python task and their standard tools: frequency counts with collections.Counter, pair-sum lookups with a dict of seen values in O(n), order-preserving de-duplication with dict.fromkeys, anagram checks with Counter equality in O(n) or sorting in O(n log n).
3. Say the brute-force version and its complexity first, then the improvement and what it costs in memory (for example a nested loop at O(n^2) time versus a set at O(n) time and O(n) extra space).
4. Write runnable, idiomatic code: enumerate instead of range(len()), comprehensions where they stay readable, and no reliance on side effects; remember that slicing such as s[::-1] builds a new O(n) copy.
5. Walk through two or three test inputs out loud, including an empty input and a single element, and fix any off-by-one you find before saying you are done.

Follow-up

• What is the time complexity of x in a list compared with x in a set, and why?
• Can you solve it in O(1) extra space, and what does that cost in time?
• How would you handle an input stream too large to hold in memory?

How do you approach multithreading and multiprocessing in your applications?

Medium · Technical Proficiency & Coding

Approach

1. Start by classifying the workload. In CPython the GIL lets only one thread execute Python bytecode at a time, so threads help I/O-bound work (network calls, disk, database waits, during which the GIL is released) but not pure-Python CPU-bound work.
2. For CPU-bound work use multiprocessing or ProcessPoolExecutor: each process has its own interpreter and memory, so arguments and results must be picklable and pay a serialisation cost; keep tasks coarse and size the pool near os.cpu_count().
3. Prefer concurrent.futures as the default interface (ThreadPoolExecutor or ProcessPoolExecutor with map or submit plus as_completed), and mention asyncio when there are thousands of concurrent network connections.
4. Protect shared state explicitly: counter += 1 is not atomic across threads, so use a threading.Lock or hand work through queue.Queue; avoid deadlocks with a fixed lock order and timeouts. Across processes, use multiprocessing.Queue, Manager or shared_memory.
5. Name the operational pitfalls: the spawn start method (default on Windows and macOS) re-imports the main module, so process creation needs an if name == "main": guard; exceptions in workers surface only when you call result().

Follow-up

• Why can adding threads make a CPU-bound Python job slower rather than faster?
• How would you make a shared counter safe across threads, and then across processes?
• When would you choose asyncio over a thread pool for many network calls?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Can you explain your understanding of human body systems in a clinical context?

Medium · Domain Knowledge & Medical Informatics

Approach

1. Be direct about your level, then show working knowledge of the major organ systems: cardiovascular, respiratory, nervous, digestive, musculoskeletal, endocrine, renal and urinary, immune and lymphatic, integumentary and reproductive.
2. Tie each system to the data software actually handles, such as lab panels: kidney function through creatinine, BUN and eGFR; liver through ALT, AST and bilirubin; endocrine through glucose, HbA1c and TSH; blood through a complete blood count; cardiac injury through troponin.
3. Connect it to classification: ICD-10-CM chapters are largely organised by body system, for example circulatory diseases in I00-I99 and respiratory diseases in J00-J99, so a system-level view maps directly onto how diagnoses are grouped.
4. Draw the engineering consequences: reference ranges depend on age, sex and the testing lab, and units differ (glucose in mg/dL or mmol/L, where 1 mmol/L is about 18 mg/dL), so results need stored units and ranges, not hardcoded thresholds.

Follow-up

• Which lab tests would you expect for suspected kidney disease, and how would you store the results?
• Why should a reference range not be hardcoded per test in the application?
• How would you handle the same test arriving in different units from two labs?

Are you familiar with the fundamentals of anatomy, physiology, and pathology?

Medium · Domain Knowledge & Medical Informatics

Approach

1. Define the three terms cleanly: anatomy is the structure of the body, physiology is how it functions normally, and pathology is the study of disease and the abnormal changes it causes.
2. Carry one example through all three, such as diabetes mellitus: the pancreas and its beta cells (anatomy), insulin regulating glucose uptake (physiology), and autoimmune beta-cell loss in type 1 or insulin resistance in type 2 (pathology), with fasting glucose and HbA1c as the lab evidence.
3. Translate it into validation logic: separate values that are abnormal but real (a very high glucose) from values that are physiologically impossible or data errors (a negative hemoglobin, a wrong unit); flag the first, reject or quarantine the second.
4. If your background is thin, say so and give a concrete learning plan: a medical terminology primer (roots, prefixes, suffixes such as -itis for inflammation and -ectomy for removal) and the ICD-10-CM chapter structure.

Follow-up

• Give one result that is abnormal but valid and one that should be rejected as a data error. How does your code tell them apart?
• How does a chronic condition differ from an acute one in the way records accumulate over time?
• How would you learn enough terminology in your first month to review data issues on your own?

How does medical terminology influence the design of healthcare-related software?

Medium · Domain Knowledge & Medical Informatics

Approach

1. Store coded concepts, not free text: a code, its code system and version, plus display text. Name the standard systems: ICD-10-CM for diagnoses, CPT and HCPCS for procedures, LOINC for lab tests, SNOMED CT for clinical terms, RxNorm for medications.
2. Handle synonyms and abbreviations with mapping tables and normalisation, so a search for heart attack finds myocardial infarction, and treat ambiguous abbreviations (MS can mean multiple sclerosis or morphine sulfate) as needing context rather than guessing.
3. Plan for versioning: ICD-10-CM is revised every year (effective October 1 in the United States), so historical records keep the version they were coded with and reports map across versions explicitly.
4. Use the hierarchies: codes have parents and children, so a rule such as all diabetes diagnoses becomes a range or hierarchy query (E08-E13 in ICD-10-CM) instead of a hand-kept list.
5. Design for interoperability and privacy: HL7 v2 and FHIR carry codes as system-plus-code pairs (for example a FHIR Observation coded with LOINC), and clinical data needs access control, audit logs and encryption, under HIPAA where it applies.

Follow-up

• How would you model diagnoses so the annual code-set update does not break historical reports?
• How would you build search that matches lay terms to clinical terms?
• What would you do with free-text notes that carry no codes at all?

What is the role of an AWS engineer in a modern cloud-based architecture?

Medium · System Infrastructure & Cloud

Approach

1. Describe the role through what it owns: network layout (a VPC with public and private subnets across Availability Zones, security groups, NAT), compute choice by workload (EC2, ECS or Fargate, Lambda), and data stores (S3, RDS or Aurora, DynamoDB).
2. Put security first: IAM least privilege, roles for workloads instead of long-lived access keys, encryption with KMS, CloudTrail for audit, and the shared responsibility model (AWS secures the infrastructure; you secure configuration, identities and data).
3. Make everything reproducible: infrastructure as code with Terraform, CloudFormation or CDK, reviewed like application code and deployed through CI/CD, so environments do not drift.
4. Cover operations: CloudWatch metrics, logs and alarms, Multi-AZ databases and auto-scaling groups for availability, backups with restores that have been tested, and cost control through tagging, rightsizing and Savings Plans.
5. Anchor it with one concrete architecture, for example a Python API on ECS behind an Application Load Balancer, RDS Multi-AZ in private subnets, and S3 for files, then say what you would monitor on it.

Follow-up

• How would you give an application access to an S3 bucket without storing access keys?
• When is Multi-AZ enough, and when is a multi-region setup worth its cost?
• The monthly bill jumped 40 percent. How do you find the cause?

What are the key differences between AWS and GCP in a production environment?

Medium · System Infrastructure & Cloud

Approach

1. Map the equivalents first: EC2 and Compute Engine, S3 and Cloud Storage, Lambda and Cloud Run functions, EKS and GKE, RDS and Cloud SQL, Redshift and BigQuery, CloudWatch and Cloud Monitoring with Cloud Logging.
2. Then the structural differences: a GCP VPC network is global with regional subnets, while an AWS VPC is regional with subnets per Availability Zone; GCP organises resources as organization, folders and projects, while AWS uses Organizations, organizational units and accounts.
3. Contrast identity and access: AWS attaches JSON policies to identities and resources, while GCP grants roles through IAM bindings that inherit down the resource hierarchy; both support service identities for workloads.
4. Contrast load balancing and pricing: GCP's global external HTTP(S) load balancer serves one anycast IP across regions, whereas AWS load balancers are regional and go global through CloudFront or Global Accelerator; GCP offers automatic sustained-use discounts on some VM types, AWS relies on Savings Plans, Reserved Instances and Spot.
5. Finish with how you would choose: team experience, managed services you need, existing contracts, and compliance (both providers offer HIPAA-eligible services under a business associate agreement), rather than claiming one is better overall.

Follow-up

• How would you limit lock-in if a system had to run on both clouds, and what does that abstraction cost?
• What would migrating a production database from one provider to the other involve?
• How does granting a service access to a storage bucket differ between the two IAM models?

How do you approach real-time network troubleshooting and configuration?

Medium · System Infrastructure & Cloud

Approach

1. Scope before touching anything: one host or many, one destination or all, since when, and what changed (a deploy, a firewall rule, DNS, a certificate). Then work up the stack one layer at a time.
2. Check in order: interface and address (ip addr, ip link), default route (ip route), DNS (dig or nslookup, and resolv.conf), reachability (ping, remembering ICMP is often blocked, so a failed ping proves little), path (traceroute or mtr), then the port (nc -vz host port, curl -v) and TLS (openssl s_client -connect host:443).
3. Read the symptom: connection refused means a reset came back (nothing listening, or an active reject), while a timeout means packets are being dropped (firewall, security rule or routing). Small requests working while large ones hang points to an MTU or path-MTU problem.
4. In a cloud network, check security groups (stateful), network ACLs (stateless, so return traffic on ephemeral ports needs its own rule) and route tables, and use VPC flow logs to see ACCEPT or REJECT; tcpdump on the host shows whether packets arrive at all.
5. For configuration changes on a live system, change one thing at a time, keep a rollback ready, verify with the same test that showed the failure, and record what was changed.

Follow-up

• Ping works but curl to the service times out. What do you check next?
• How would you tell a DNS problem from a routing problem in under five commands?
• A connection works from one subnet but not another in the same VPC. Where do you look?

Suggested practice checklist

Each day targets one of the reported question families: Python coding, concurrency, network and cloud troubleshooting, AWS and GCP, medical-domain knowledge, then a full mock for the leadership stage. Question links point at the reported questions practised that day.

Day 1 — Map the loop and fix your starting answers

• Write the three reported stages (Recruiter Screening, Technical Assessments, Interviews with Leadership) and list which reported question families could appear in each kind of stage.
• Write your honest answer to the question about your most comfortable programming language, including two projects and one weakness.
• Rate yourself from one to five on Python, concurrency, networking, AWS or GCP, and medical vocabulary, and pick the weakest two for extra time.

Deliverable: A one-page loop map, a written answer on your strongest language, and a ranked skill list.

Day 2 — Python fundamentals and a program that shows your style

• Write three basic Python tasks from scratch: count items with a dict or Counter, group records by a key with defaultdict, and transform strings or lists with comprehensions and sorted with a key function.
• Write one 40 to 60 line program that parses a small CSV of invented lab results and summarises it, with functions, type hints, a docstring and tests.
• Explain aloud why you chose each data structure and how the program handles malformed rows.

Deliverable: Three working solutions plus one tested program, each with a spoken explanation of its trade-offs.

Day 3 — Multithreading and multiprocessing in Python

• Write a demo that runs an I/O-bound job and a CPU-bound job with threads, a process pool and sequentially, then record the timings.
• Write a shared counter that loses updates without a lock, then fix it with a lock and again with a queue.
• Prepare a spoken answer covering the GIL, ThreadPoolExecutor versus ProcessPoolExecutor, asyncio, and the cost of pickling data.

Deliverable: A timing table for both workloads, a race demo with its fix, and a rehearsed answer on multithreading versus multiprocessing.

Day 4 — Network troubleshooting and the role of an AWS engineer

• Write a layered troubleshooting runbook: name resolution, reachability, ports, routing, firewall or security-group rules, application, with a command or check for each layer.
• Apply the runbook aloud to two invented outages, such as a service that is reachable by IP but not by name, and one that times out only from one subnet.
• Outline what an AWS engineer owns in a cloud architecture: networking, identity and permissions, compute, storage, monitoring, cost and recovery.

Deliverable: A one-page runbook, two narrated outage walkthroughs, and a written outline of the AWS engineer role.

Day 5 — AWS versus GCP in production

• Build a table of equivalent services for compute, object storage, managed databases, networking, identity and monitoring across AWS and GCP.
• Pick three production differences you can defend, such as how networks are scoped, how identity and permissions are modelled, and how monitoring and billing are organised, and check each against the providers' documentation.
• Say which provider you have actually used and describe one real incident or deployment you handled on it.

Deliverable: A verified service-equivalence table, three defensible differences, and one real example from your own work.

Day 6 — Medical vocabulary and the clinical questions

• Write one paragraph each on human body systems, anatomy, physiology and pathology in your own words, at the level a software engineer needs to read clinical data.
• Learn about 30 clinical word parts (prefixes, suffixes, roots) and write how a controlled vocabulary or code set would show up in a data model.
• Write your honest answer on medical coding and HCC coding, covering ICD-10-CM codes, HCC categories, hierarchies, code-set versions and your first learning steps.
• Answer aloud how medical terminology influences healthcare software design, with three concrete design consequences.

Deliverable: Four short written explanations, a clinical word-part sheet, an honest HCC answer and a spoken design answer.

Day 7 — Mock loop and leadership stories

• Run a mock in order: introduce yourself, solve a basic Python task, explain a concurrency choice, then walk through a network outage, all spoken aloud.
• Write three situation, action, result stories on conflict, a deadline and a time you did not know the answer, then rehearse each.

Deliverable: A recorded mock, three polished stories, and a list of the answers that still need work.

Domain honesty and working with operations teams

Candidates report behavioral questions about conflict, deadlines and team collaboration, even within technical conversations, plus the need to communicate with operations managers as well as engineers. The reported medical-coding question is a hybrid: it needs an honest account of your experience and a story that shows how you handle unfamiliar domains. Prepare stories where you made the decision, and give a specific result.

1. Tell me about a time you disagreed with a teammate about a technical approach. What did each of you want, and how did you settle it?
2. Describe a deadline that tightened while you were mid-project. What did you cut or move, and who did you tell?
3. Tell me about a time you were asked something you did not know. What did you say, and how did you find the answer afterwards?
4. Describe a time you explained a technical constraint to a non-engineer, such as an operations manager. How did you check they understood?
5. Tell me about a time you had to learn an unfamiliar domain quickly to build something correctly.

What is your experience with medical coding or HCC coding?

Medium · Domain Knowledge & Medical Informatics

Approach

1. Answer the literal question in your first sentence: you have done medical or HCC coding hands-on, you have worked with coded data as an engineer, or you have neither. Candidates report that honesty beats guessing on specialised topics, so a bluffed answer is the mistake that sinks this question.
2. If you have hands-on experience, tell it as a story where you made the decisions. Say what records or encounters you coded, that ICD-10-CM diagnosis codes roll up into HCC categories, that a hierarchy lets a more severe condition in a family replace a milder one, and that the resulting categories feed a risk-adjustment score. Name what you checked: that documentation supported each diagnosis and that you used the correct code-set version for the year.
3. If your experience is adjacent, use a situation, action, result story about the closest real work: a lookup or mapping table, validation of code values, or a pipeline that consumed versioned reference data. Give a concrete result such as errors caught or reconciliation time saved, then say plainly what is new to you.
4. Show a learning plan with specific first steps: read a published ICD-10-CM to HCC mapping, learn the common prefixes and suffixes of clinical terms, ask a certified coder to review ten of your examples, and turn their corrections into automated tests.
5. Finish with the software angle, since this is an engineering loop: coded data needs validation for unknown or retired codes, a record of which mapping version produced each result, and a way for a human coder to override and audit a result.

Follow-up

• A new mapping version arrives. How would you test that records you already processed do not change unintentionally?
• A certified coder and your code disagree on one case. How do you settle it, and what do you change afterwards?
• What would you learn first to become productive in this domain, and how would you check you had learned it?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?