Archon Resources Software Engineer Interview Guide

The 60-second brief

Candidates describe Archon Resources Software Engineer roles that sit between cloud infrastructure and industrial systems: some positions centre on Azure networking, others on industrial control systems, and the work supports the company's operational and enterprise services. The reports name no product line, customer list or team structure, so this guide does not guess at them. In this role you design, deploy and maintain software and configure network environments, working with product managers, operations teams and other engineers from requirements through to production.

This guide is for candidates interviewing for a Software Engineer position at Archon Resources, especially one with an Azure, cloud networking or industrial controls flavour. It covers the five technical questions candidates report (latency in Azure, controls security over modern network protocols, troubleshooting a distributed-system failure, Azure load-balancing choices and legacy-to-cloud migration), the one preparation stage reported, a seven-day plan, behavioral rehearsal and the questions to put to your recruiter.

No fixed round sequence is reported. Candidates describe a series of conversations that start with qualifications and move to specialised technical assessment, with design-style deep dives later, and most report finishing within 3 to 5 weeks.

Focus areas

• Microsoft Azure
• Networking
• Azure Networking Services

Overview

The reported questions are open-ended technical conversations rather than puzzles. Four are design or architecture questions: reducing network latency in a complex Azure environment, securing industrial controls that are being connected to modern network protocols, choosing between Azure load-balancing options, and moving legacy infrastructure to a cloud-native architecture. The fifth is a debugging question about a serious failure in a distributed system. None of them has a single correct answer, so the useful skill is to state assumptions, name the trade-off and justify the choice.

Candidates report that the topics cluster around Microsoft Azure, networking and Azure networking services, with security groups, virtual networking, monitoring, logging and incident response named as areas to be ready on. The role description also mentions controls engineering, the logic and hardware-software interaction of industrial systems, so decide early whether your background is cloud networking, controls, or both, and prepare the matching side in depth while keeping a working vocabulary for the other.

Candidates also report that people who stall are usually not missing knowledge; they cannot explain why they made a technical decision. Prepare every answer in the shape: requirement, options considered, choice, cost of the choice, how you would know it failed. Reported tips add that foundations of networking and software design come back even in senior loops, and that STAR structure helps with situational answers.

No coding stage is reported. Do not assume there is none; ask your recruiter, and keep one short refresher on a language you use so that a request to write or read code does not surprise you. For the Tulsa and Dallas locations candidates are also told to be ready to discuss working with local teams and site requirements, so have a view on how you adapt a design to a particular site.

Where to focus your preparation

Only a general progression is reported, not a named sequence of rounds, so the single entry below is a preparation focus rather than a fixed stage. Confirm the real format with your recruiter.

Preparation focus

Candidates do not report named rounds. They describe a series of discussions that begin with qualifications and move to more specialised technical assessment, with design-style deep dives later, and they say the emphasis can differ by team and location. Treat this stage as a technical conversation on Azure, networking and, for some roles, industrial controls. Answer each question by clarifying the environment, stating the requirement, comparing options and giving the reason for your pick. Ask the recruiter for the sequence, who you will meet and whether you will write code.

What to demonstrate

• Working knowledge of Azure virtual networking, security groups and load-balancing choices
• Security reasoning when industrial control systems meet modern network protocols
• A structured way of diagnosing a failure in a distributed system
• Ability to explain the reasoning behind a technical decision, not only the decision

How to prepare

• Rehearse out loud the five reported questions, each with a stated assumption, two options and a reason for your choice
• Prepare one real project where you can explain why you chose an approach, what it cost and what you would change
• Write a one-page troubleshooting sequence you can recite: scope, recent changes, evidence, hypothesis, fix, follow-up
• Ask your recruiter about the sequence, the team and location, and whether the role leans to cloud networking or controls

Where candidates lose points

Naming Azure services without saying why one fits the requirement

For the load-balancing and latency questions, anchor every service you mention to a requirement: traffic type, whether the service is regional or global, how health is checked, and what failure it survives. State what you would not choose and why.

Optimizing latency by intuition instead of measurement

Start with a baseline: where the time goes between client, network path, load balancer and backend. Say which measurements you would take, then reason about placement, routing and connection reuse, and describe how you would confirm the improvement.

Treating industrial controls security as ordinary office IT security

Open with what differs: uptime and safe operation matter, devices may not accept frequent patching, and many control protocols were not designed with authentication. Then cover segmentation, controlled gateways between the two networks, monitoring and access control.

Jumping to a fix when asked to troubleshoot a distributed-system failure

Narrate a sequence: confirm the symptom and its scope, find what changed recently, check logs and metrics, split the system to isolate the failing part, mitigate first, then find the root cause and write the follow-up actions.

Describing migration as a one-step lift-and-shift

Give phases: inventory dependencies, pick workloads by risk, run old and new side by side, cut over in small steps, keep a rollback, and say how you would judge success. Mention what you would leave unchanged and why.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

How do you optimize network latency within a complex Azure cloud environment?

Medium · Technical Domain Expertise

Approach

1. Measure before tuning: separate network time from application time with Network Watcher Connection Monitor for path latency and loss, SockPerf (Linux) or latte (Windows) for VM-to-VM round trips, and request traces that split DNS, TLS handshake, time to first byte and server processing.
2. Fix placement first, because distance dominates: keep chatty tiers in one region, and in one availability zone if the latency budget is tight. Use a proximity placement group to co-locate VMs in one datacenter, and say that this costs zone-level resilience.
3. Turn on Accelerated Networking (SR-IOV) on supported VM sizes. Traffic then bypasses the host virtual switch, which cuts latency, jitter and host CPU. Then look for hairpins: UDRs that force east-west traffic through a firewall or NVA, or traffic leaving through a public endpoint when VNet peering or a private endpoint would keep it on the Azure backbone.
4. For users far from the region, end TLS close to them with Azure Front Door (anycast edge, caching) and use ExpressRoute rather than an internet VPN for hybrid paths that need predictable latency. In the application, reuse connections (keep-alive, pooling, TLS session resumption) and batch chatty calls. Fewer round trips often beat a faster pipe.

Follow-up

• How would you prove the slowdown is in the network and not in the database or the application?
• Proximity placement groups and zone redundancy pull in opposite directions. Which would you pick for a latency-sensitive control service, and why?
• Every packet between two subnets goes through a firewall appliance and adds latency. What would you change, and what security would you give up?

Can you explain the security considerations when integrating industrial controls with modern network protocols

Medium · Technical Domain Expertise

Can you explain the security considerations when integrating industrial controls with modern network protocols?

Approach

1. Start from the threat model: many control protocols (Modbus/TCP, classic DNP3) have no authentication or encryption, so anyone who can reach the device can send commands, including writes. Availability and safety come before confidentiality on the plant floor, so you cannot always patch, reboot or run active scans against PLCs.
2. Segment using the Purdue model and the zones-and-conduits approach of ISA/IEC 62443: put an industrial DMZ between IT and OT, allow no direct path from the internet or the corporate network to controllers, and allowlist each conduit by source, destination, port and, where a protocol-aware firewall can do it, by function code (for example, block Modbus write codes 5, 6, 15 and 16 from the IT side).
3. Prefer protocols with built-in security for new integration. OPC UA supports signing and encryption with X.509 certificates, and MQTT can run over TLS with client certificates. For legacy protocols, wrap the link (VPN or TLS gateway) instead of exposing it. Send telemetry outbound only, through a broker or gateway, or a data diode if the site needs a one-way path.
4. Lock down remote access and monitoring: vendor access only through a jump host with MFA, time-boxed sessions and recording; passive OT network monitoring (port mirroring, no active scanning) that alerts on new devices and unexpected writes; certificate and credential rotation that does not require downtime.

Follow-up

• How would you get sensor data into a cloud analytics platform without opening any inbound port into the OT network?
• A PLC runs firmware with a known vulnerability and cannot be patched for a year. What compensating controls would you put in place?
• What would you monitor to tell a legitimate setpoint change from a malicious one?

What are the key differences between various Azure load-balancing solutions, and when would you choose one ove

Medium · Technical Domain Expertise

What are the key differences between various Azure load-balancing solutions, and when would you choose one over the other?

Approach

1. Sort the options on two axes: global or regional, and layer 4 or HTTP(S). Azure Load Balancer is regional layer 4 (TCP/UDP, public or internal). Application Gateway is regional layer 7. Azure Front Door is global layer 7 at Microsoft's edge. Traffic Manager is global and DNS-based.
2. Azure Load Balancer passes packets through without terminating connections, so backends see the client IP for inbound flows. It has very low overhead, uses health probes and suits non-HTTP services or internal tiers. The Standard SKU supports zone-redundant frontends. It cannot route by URL or terminate TLS.
3. Application Gateway terminates TLS and routes by host or path. It supports cookie-based session affinity, an optional WAF and, on v2, autoscaling. Use it for HTTP apps inside a region or for private web workloads. Front Door adds anycast entry points worldwide, caching, a WAF and fast failover between regions, which suits public HTTP apps serving users in many regions.
4. Traffic Manager only answers DNS queries (priority, weighted, performance, geographic, multivalue and subnet routing), so it works for any protocol. Failover is limited by DNS TTL and by client-side DNS caching, and it never sees the traffic itself.
5. Explain how they combine: Front Door in front of Application Gateway in front of the backends for a global web app, or Traffic Manager in front of regional Load Balancers for a non-HTTP global service. State the cost of each extra hop in latency and money.

Follow-up

• Why can a Traffic Manager failover take longer than a Front Door failover, and how would you shorten it?
• A TCP service needs the original client IP and has users in several regions. Which combination would you choose?
• How would you design health probes so that a backend with a broken dependency is pulled from rotation, without one slow dependency taking every backend out at once?

How do you approach the migration of legacy infrastructure to a cloud-native architecture?

Medium · Technical Domain Expertise

Approach

1. Start with discovery: inventory servers, applications and data stores, and map dependencies (for example with Azure Migrate dependency analysis or flow logs). Hard-coded IPs, shared databases, batch jobs and licensing are what break a migration, so find them before anything moves. Record performance and cost baselines so you can judge the result.
2. Decide per workload instead of using one strategy for all of them: rehost (lift and shift), replatform (managed database, PaaS), refactor or rearchitect, replace with SaaS, retain on-premises or retire. Give each decision its reason: time pressure, operational burden, or a need for elasticity.
3. Build the landing zone before the first workload moves: hub-and-spoke networking with an IP plan that does not overlap on-premises ranges, hybrid connectivity (VPN or ExpressRoute), identity, policy, logging and backup. Retrofitting these after workloads are live is much harder.
4. Move in waves, smallest and least coupled first. Move chatty dependencies together so a cloud app does not call an on-premises database across the WAN on every request. For applications that need rework, use the strangler fig pattern: route traffic piece by piece to new components behind a stable facade.
5. Plan every cutover: replicate data continuously, lower DNS TTLs ahead of time, freeze writes or run in parallel, define go/no-go checks, and write down a rollback path, including what happens to writes that already landed in the new environment. Right-size after a few weeks of real metrics.

Follow-up

• A legacy application makes hundreds of small queries per page to a database that must stay on-premises for now. What do you do?
• Writes have already landed in the cloud database when you need to roll back. How do you recover?
• How do you decide whether a workload is worth refactoring or should just be rehosted?

Describe your process for troubleshooting a critical failure in a distributed system.

Medium · Technical Domain Expertise

Approach

1. Stabilise before you diagnose. Size the blast radius with the four golden signals (latency, traffic, errors, saturation) per service and region, then mitigate first if users are hurt: roll back, fail over, shed load or disable a feature flag. Record what you did and when.
2. Build a timeline of changes before you form a theory: deploys, config and feature-flag changes, certificate expiry, DNS, scaling events, dependency incidents. Then line the timeline up against the first anomaly in metrics, not the first alert, because alerts lag.
3. Follow one failing request end to end with distributed traces or correlation IDs and centralised logs (for example KQL queries in Log Analytics) to find the first hop that fails or slows. Check the instrumentation itself: a missing metric or a skewed clock can make a healthy service look broken.
4. Test the usual distributed failure modes one at a time: timeouts longer than the caller's own timeout, retry storms that multiply load, connection-pool or thread exhaustion, a single hot partition, partial network partitions. Pick checks that rule out a whole group of causes whichever way they come out.
5. Close with a blameless postmortem: separate the trigger from the root cause, list the detection gap (why monitoring did not catch it sooner), and give each action item an owner, such as a missing alert, a circuit breaker, or a retry budget with backoff and jitter.

Follow-up

• The rollback did not fix it. What do you check next?
• How would you tell whether client retries are causing the outage or only making it worse?
• Two services both show errors at the same moment. How do you decide which one failed first?

Suggested practice checklist

Seven days that follow the five reported questions and the Azure, networking and controls topics. Day 1 settles the format; days 2 to 5 cover one question group each; day 6 covers behavioral answers; day 7 is a full mock.

Day 1 — Confirm the format and choose your focus

• Write the questions you will ask your recruiter: sequence, who you meet, whether code is expected, and whether the role leans to Azure networking or controls
• List the five reported questions and mark each as strong, shaky or untouched for your background
• Choose your primary side (cloud networking or industrial controls) and note the vocabulary you need from the other

Deliverable: A list of recruiter questions and a ranked map of the five reported questions with your confidence on each.

Day 2 — Azure latency and load balancing

• Draw an Azure virtual network with subnets, security groups and a backend tier, and mark where latency can be added
• Write a measurement plan: what you would capture, where, and how you would read the numbers
• Build a comparison table of Azure load-balancing options by traffic layer, scope and health checking, then give a scenario for each
• Answer aloud: how do you optimize network latency within a complex Azure cloud environment, and how do you choose between load-balancing solutions

Deliverable: A diagram, a measurement plan, a comparison table and two recorded spoken answers.

Day 3 — Securing industrial controls on modern networks

• Outline the threats when a control network meets IP-based protocols: exposed devices, weak authentication, flat networks
• Write a layered defence: segmentation, gateways, access control, monitoring, change management
• Prepare the secure-hybrid-cloud scenario: identity, network boundaries, logging across the on-premises and cloud sides
• Answer aloud, naming the trade-off between security controls and keeping the system running

Deliverable: A one-page layered-defence outline and a spoken answer to the controls security question.

Day 4 — Troubleshooting a distributed system

• Write your standard sequence: scope, recent changes, signals, hypothesis, mitigation, root cause, follow-up
• Take one outage you have seen and retell it in that sequence, naming the evidence at each step
• Add the reliability practices candidates are told to know: monitoring, logging and incident response
• Answer aloud: describe your process for troubleshooting a critical failure in a distributed system

Deliverable: A one-page troubleshooting sequence and one outage retold with evidence at each step.

Day 5 — Migrating legacy infrastructure to cloud-native

• List what to inventory before moving anything: dependencies, data, traffic, access, compliance
• Outline a phased plan with parallel running, cutover steps, rollback and success checks
• Cover common pitfalls in large network deployments, such as address overlap and routing surprises
• Answer aloud, then repeat all five reported questions in sequence to check consistency

Deliverable: A phased migration outline and spoken answers to all five reported questions.

Day 6 — Behavioral stories with the why

• Write three STAR stories, each stating the options you weighed and the reason for your choice
• Prepare a story about picking up an unfamiliar tool or method on a project whose requirements shifted

Deliverable: Three STAR stories with decision reasoning, plus notes from the three behavioral drills.

Day 7 — Full dry run and questions to ask

• Run a mock where a friend asks the five reported questions in random order and one behavioral prompt
• Record yourself and check that each answer states assumptions, options, a choice and a way to test it
• Write your questions for interviewers about the team, the stack and how work moves from requirement to production

Deliverable: A recorded mock, a list of gaps to fix and your questions for interviewers.

Explaining the why behind your decisions

No behavioral questions are reported by name, but candidates are advised to use the STAR method, and they report that explaining the reasoning behind technical decisions matters. For this role, prepare stories where you chose between options, diagnosed a failure, worked with product or operations colleagues, and owned a deliverable through to production.

1. Walk through a technical decision where you picked one approach over others. What were the options, and why did you choose yours?
2. Tell me about a time you diagnosed a failure in a system made of several services or sites. What did you check first, and how did you confirm the cause?
3. Describe a project where requirements shifted midway and you had to learn an unfamiliar tool or method quickly.
4. Tell me about turning a business request from a product manager or operations team into a technical specification.
5. Describe a deliverable you owned from inception to production. What did you do to limit technical debt?
6. Tell me about a peer review in which you disagreed with the feedback. How did you resolve it?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

• What threshold on that alert would have proved you right, and did anyone ever look at it?
• If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?