Collaboredge Software Engineer Interview Guide

The 60-second brief

Candidates describe the Collaboredge Software Engineer role as sitting between infrastructure management and platform engineering. Three tracks are named for it: the OUC Power Platform, ITS Infrastructure and Network Engineering. The topics candidates list for the loop include Software Engineering, Network Engineering, Power Platform (Microsoft), Field Networking with on-site support, and Troubleshooting. The work is described as running systems that other people depend on, and as moving older infrastructure toward cloud-based platforms. Reports do not name a specific product line or customer, so this guide does not guess at one. Treat the role as operations-heavy engineering: designing, deploying and maintaining environments, and writing scripts or code to do it.

This guide is for candidates interviewing for a Software Engineer position at Collaboredge, in any of the reported tracks (Power Platform, ITS Infrastructure or Network Engineering). It covers the two reported rounds, the nine reported questions on troubleshooting, migration, performance, security, deployment risk, architecture and scalability, and a seven-day plan. Ask your recruiter which track your loop belongs to, then weight the plan toward it.

Candidates report two stages over roughly two to four weeks: a Technical Screening, followed by Deep-Dive Rounds on architectural thinking, coding standards and cultural alignment.

Focus areas

• Software Engineering
• Network Engineering
• Power Platform (Microsoft)

Overview

The reported questions share one shape: they ask what you did or would do when a real environment misbehaves or has to change. Several are experience questions (a critical failure in a production network or platform, an outage with limited documentation, a complex architectural decision). The rest are method questions (migrating legacy data or infrastructure to the cloud, tuning for heavy traffic, securing an enterprise platform, shipping fast without breaking stability, finding the cause of an intermittent fault, designing when requirements keep shifting). Very few ask you to write an algorithm on a whiteboard, so most of your preparation is rehearsing structured spoken answers backed by real examples.

Candidates also report a caution that the role is not only about coding: operational readiness and keeping complex systems running in production matter. Requirements described for the role include domain proficiency (for example Power Platform architecture or network and ITS infrastructure), scripting or coding ability and experience in high-availability environments. Certifications, cloud migration projects and formal incident management are listed as extras. If you have any of those, make sure a story in your set shows it.

Build your prep around three assets. First, a troubleshooting routine you can narrate in order: establish what changed, bound the blast radius, mitigate, find the mechanism, verify, prevent a repeat. Second, three or four real projects you can describe with specifics: a migration, an outage, a security configuration, an architectural call with a rejected alternative. Third, a habit of stating trade-offs and security implications as you answer, since candidates report that explaining the reasoning behind a choice matters as much as the choice. Reported guidance suggests at least two to three weeks of focused preparation, so the seven-day plan here is a compressed version for when time is short.

The Collaboredge interview process

Candidates describe two stages. The sequence below is what candidates report, not a published schedule, so confirm details with your recruiter.

Technical Screening

Candidates describe the Technical Screening as an initial check of baseline technical skills. No format, length or interviewer is reported, so prepare for a conversation and for working through technical scenarios. The reported question types that fit this stage are domain questions (migration, performance, security, release risk) and troubleshooting questions. Have a short, accurate account of your own track, whether Power Platform, ITS infrastructure or network engineering, and be ready to explain why you made your technical choices instead of just naming tools.

What to demonstrate

• Baseline competency in the technical skills of your track
• Whether you can explain the reasoning behind a technical choice, not only the tool
• A structured way of working through a production problem

How to prepare

• Write a two-minute summary of your most relevant project, with the stack, your role and one trade-off you made
• Rehearse a fixed troubleshooting sequence: what changed, blast radius, mitigation, mechanism, verification, prevention
• Refresh the fundamentals of your track, such as network topology and protocols or Power Platform governance and environments
• Prepare short answers on migrating legacy data to the cloud and on securing an enterprise platform

Deep-Dive Rounds

Candidates describe the Deep-Dive Rounds as in-depth interviews on architectural thinking, coding standards and cultural alignment. The plural suggests more than one conversation, but the number and order are not reported. A coding-standards discussion is a good place to talk about scripts and automation you have written, how you review and test them, and how you manage dependencies in a complex deployment. For architecture, bring decisions with named alternatives and the reason you rejected them. For cultural alignment, expect experience-based prompts such as outages, mistakes and explaining technical choices to non-technical stakeholders.

What to demonstrate

• Architectural reasoning and the trade-offs behind decisions
• Coding standards and scripting practice
• Collaboration and the ability to explain decisions in business terms

How to prepare

• Write up two architecture decisions in context, options, choice, rejected alternative and what you would change
• Prepare a rollout story that shows how you balanced rapid deployment against stability (staged rollout, rollback plan, change windows)
• Build a security checklist for platform configuration: least privilege, secrets handling, patching, logging, network segmentation
• Practise explaining a technical decision aloud in terms of operational efficiency and long-term maintenance

Where candidates lose points

Answering the troubleshooting questions with a list of tools instead of an ordered method

Memorise one sequence and use it for every fault story: establish what changed, bound the blast radius, mitigate, find the mechanism with evidence, verify recovery, prevent a repeat. Say why each step comes before the next, and name the evidence that confirmed each conclusion.

Naming a technology choice without the trade-off or the alternative you rejected

For each architecture or migration story, write one line each for the options considered, the deciding constraint and what the choice cost you. Reported guidance stresses the why behind decisions, so rehearse saying it out loud.

Treating the security question as a generic checklist read from memory

Tie each practice to a concrete configuration you set: role scoping, secret storage, patch cadence, audit logging, network segmentation. Mention what you would check first on a platform you inherited, and one security decision where you traded convenience for risk reduction.

Presenting speed and stability as opposites, or claiming you never had to choose

Describe the mechanism that let you do both: staged rollout, feature gating, a tested rollback, a change window, automated checks. Give a case where you slowed a release on purpose, and say what evidence made you do it.

Telling outage or mistake stories where the result is a fix but no lesson, no numbers and no change that stopped a repeat

End every story with the measurable outcome and the systemic change, such as a runbook, alert, test or approval step. If asked about a mistake, own it plainly and show what you changed afterwards.

Questions & practice

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?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

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?

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?

How do you approach the migration of legacy data or infrastructure to a modern cloud-based architecture?

Medium · Technical & Domain Proficiency

Approach

1. Start with an inventory and dependency map: every application, database, scheduled job and network path the legacy system touches, plus who owns each one. Hidden dependencies such as hard-coded IPs, file shares and nightly batch jobs are what break a cutover.
2. Choose a strategy per workload rather than one for the whole estate: rehost (lift and shift) for speed, replatform onto managed services where operations cost matters, refactor only where the old design blocks scaling. Say what each choice costs in time and risk.
3. For data, describe a bulk initial load followed by change data capture to keep the target in sync until cutover. Avoid application dual-writes unless you can handle partial failure, because a write that succeeds on one side and fails on the other leaves the two stores silently diverged.
4. Validate before switching: row counts, per-table checksums or hashed samples, and a period of shadow reads that compares old and new results. Define the cutover sequence (freeze writes, final sync, repoint DNS or connection strings) and a tested rollback path.
5. Migrate incrementally where possible (strangler-fig pattern: route one capability at a time to the new system) so each step is small and reversible.

Follow-up

• How would you migrate a database that cannot take more than a few minutes of write downtime?
• What do you do if validation shows a small percentage of rows differ after the final sync?
• How do you handle the network side: hybrid connectivity, DNS and firewall rules while both environments run?

Explain your process for optimizing system performance when faced with high-traffic constraints.

Medium · Technical & Domain Proficiency

Approach

1. Measure before changing anything: p50, p95 and p99 latency, throughput, error rate, and saturation per resource (CPU, memory, disk I/O, network, connection pools). The USE method (utilization, saturation, errors) gives a checklist for each resource.
2. Locate the bottleneck with evidence: profiling, slow-query logs, query plans and traces. Little's Law (concurrent requests = arrival rate x time in system) explains why a slow dependency exhausts threads or connections as traffic rises.
3. Apply the fix that matches the bottleneck: indexes or removing N+1 queries for the database, connection pooling, caching hot reads with a TTL and stampede protection, moving slow work onto a queue, or scaling stateless tiers horizontally behind a load balancer.
4. Protect the system at the edge: rate limiting, timeouts with bounded retries and jitter, and backpressure or load shedding so overload degrades a feature instead of the whole service.
5. Prove the result with a load test at and beyond expected peak, compare tail latency before and after, and keep the dashboards and alerts that would catch a regression.

Follow-up

• Your cache hit rate is high but p99 latency is still bad: where do you look next?
• How would you tell whether the database or the application tier is the real constraint?
• What happens to your design when a cached key expires under peak traffic?

What security best practices do you implement when configuring enterprise-level platforms?

Medium · Technical & Domain Proficiency

Approach

1. Anchor the answer on least privilege and identity: role-based access, separate admin accounts, MFA, and periodic access reviews. Say how you remove access when people change roles, not only how you grant it.
2. For Microsoft Power Platform, cover environment strategy (separate dev, test and production environments), data loss prevention policies that sort connectors into Business, Non-Business and Blocked groups, Dataverse security roles, and limiting who can create environments or share apps.
3. For network infrastructure, cover segmentation (VLANs and firewall rules between zones), disabling unused ports and services, SSH instead of Telnet, SNMPv3 instead of v1/v2c community strings, and centralised AAA through TACACS+ or RADIUS.
4. Handle secrets and data: keep credentials in a vault or managed identity rather than in scripts or flows, encrypt in transit with TLS and at rest, and rotate keys on a schedule.
5. Make it verifiable: audit logging sent to a central store, configuration baselines checked for drift, and a patching cadence. Name a trade-off, such as strict connector blocking slowing down citizen developers, and how you handled the exceptions.

Follow-up

• A business team needs a connector your data loss prevention policy blocks: how do you decide and what do you put in place?
• How would you detect a configuration change that weakened security after go-live?
• What is the risk of a service account that many flows or scripts share, and how would you fix it?

How do you balance the need for rapid deployment with the requirement for system stability?

Medium · Technical & Domain Proficiency

Approach

1. Reframe the trade-off: small, frequent changes are usually safer than large infrequent ones because each change has a smaller blast radius and a clear rollback.
2. Describe the safety net that makes speed possible: CI with automated tests, infrastructure and configuration as code reviewed like application code, and environments that mirror production (for Power Platform, solutions promoted from dev to test to production as managed solutions).
3. Release progressively: feature flags, canary or blue-green deployments, and automatic rollback when error rate or latency crosses a defined threshold. For network changes, use maintenance windows, saved pre-change configs, pre- and post-change checks, and a timed rollback such as a commit-confirm.
4. Use a measurable rule to decide when to slow down, for example an error budget tied to an availability target: while it is healthy, ship; when it is spent, prioritise reliability work.
5. Close with a concrete example: what you shipped, the guardrail you relied on, and a case where the guardrail caught a bad change.

Follow-up

• Which changes would you never push through the fast path, and why?
• How do you roll back a change that includes a database schema migration?
• What would you do if the team keeps exhausting its error budget?

Walk me through a complex architectural decision you made. What were the trade-offs?

Medium · Problem-Solving & Architecture

Approach

1. Set the context in a few sentences: the system, the load or constraint that forced a decision, and what failure would have cost. The decision itself should be one you owned or strongly shaped.
2. Lay out at least two real options and the criteria you compared them on (latency, operational burden, cost, team skills, migration risk, reversibility). An answer with only one option is a description, not a decision.
3. State what you gave up explicitly, for example choosing a managed queue over self-hosted Kafka trades replay and partition control for less operational work, or caching aggressively trades freshness for load reduction.
4. Give the outcome with numbers you measured, and how you recorded the reasoning (an architecture decision record or design doc) so others could revisit it.
5. Finish with what you would change now and which signal would make you reverse the decision.

Follow-up

• Who disagreed with the decision, and what was their strongest argument?
• How did you validate the choice before committing to it fully?
• If the load grew tenfold, which part of that decision would break first?

Describe a situation where you had to work with limited documentation to resolve a system outage.

Medium · Problem-Solving & Architecture

Approach

1. Show the order: stabilise first (roll back the last change, fail over, restart a stuck component), then diagnose. Say what you did to limit impact before you understood the cause.
2. Explain how you rebuilt understanding from the live system when the docs were missing: running configs, process lists, listening ports and open connections (ss or netstat), logs, recent change history, and packet captures (tcpdump or Wireshark) to see what actually talks to what.
3. Describe how you narrowed the problem: forming one hypothesis at a time and choosing checks that rule out half the possibilities, and who you pulled in (original authors, vendors, other teams) and when.
4. Keep a timestamped log of actions during the outage so the fix is reproducible and the post-incident review is accurate.
5. End with the lasting fix: the runbook, diagram or monitoring you wrote afterwards, so the next on-call engineer does not start from zero.

Follow-up

• What was the riskiest action you took without full documentation, and how did you limit the risk?
• How did you communicate status to stakeholders while the cause was still unknown?
• What did the documentation you wrote afterwards contain?

How do you design for scalability when requirements are evolving rapidly?

Medium · Problem-Solving & Architecture

Approach

1. Clarify what is known and what is likely to change: expected load range, read-to-write ratio, data growth, and which requirements are stable. Design for roughly an order of magnitude of growth, not for every hypothetical.
2. Keep the parts that scale simple: stateless services that scale horizontally, state in managed stores, and asynchronous queues between components so a slow consumer does not block producers.
3. Put clear interfaces around the parts most likely to change so they can be replaced without rewriting callers, and defer hard-to-reverse choices (sharding key, data store) until access patterns are known.
4. Plan for evolution in data and APIs: versioned APIs, backward-compatible schema changes using expand-and-contract migrations, and idempotent operations so retries are safe.
5. Back it with capacity monitoring and load tests so you know your current headroom and which component hits its limit first, then revisit the design when that limit gets close.

Follow-up

• When would you choose to shard, and how would you pick the shard key?
• A new requirement doubles write volume next quarter: what changes in your design?
• How do you avoid over-engineering for scale that may never come?

How do you identify the root cause of an intermittent issue in a distributed system?

Medium · Problem-Solving & Architecture

Approach

1. Pin down the symptom precisely: which requests fail, the error type, how often, since when, and whether it clusters by host, region, client, time of day or payload size. Intermittent failures usually have a hidden common factor.
2. Correlate across services with distributed tracing and a request or correlation ID in every log line; check clock sync (NTP) before trusting cross-host timelines.
3. Work through the usual intermittent causes and test each one: one bad instance behind a load balancer, connection or thread pool exhaustion, timeouts and retry storms, stale DNS or cached endpoints, garbage-collection pauses, race conditions, and on the network side packet loss, MTU mismatch or a flapping link.
4. Add instrumentation where you are blind, then try to reproduce: replay traffic, load-test, or inject faults (latency, dropped connections) to confirm the mechanism instead of guessing.
5. Confirm the fix by watching the failure rate over a window long enough to have shown the old frequency, and add an alert or test that would catch a recurrence.

Follow-up

• The issue happens about once a day and you cannot reproduce it: what do you add first?
• How would you separate a cause from something that merely changed at the same time?
• What would make you suspect the network rather than the application?

Suggested practice checklist

The seven days follow the reported loop: map your track and the two stages, build a troubleshooting method, cover migration, security, performance and release risk, then rehearse architecture and outage stories and finish with a full mock.

Day 1 — Pick your track and map the loop

• Confirm with the recruiter whether your loop is Power Platform, ITS Infrastructure or Network Engineering, and note any on-site or location requirements
• List the Technical Screening and Deep-Dive Rounds, and write which of the nine reported questions you could answer well today and which you could not
• Write your two-minute project summary and a list of four projects you can talk about in depth

Deliverable: A one-page loop map with your track, a readiness mark on each reported question, and a written two-minute project summary plus four candidate stories.

Day 2 — Troubleshooting method

• Write your fixed diagnosis sequence on one page, then apply it to a made-up intermittent fault in a distributed system, listing what each check rules out
• Answer aloud how you would find the cause of an intermittent issue, covering instrumentation, correlation with changes and how to tell cause from coincidence
• Write your first version of the production-failure story with the symptom, layers checked, mitigation, mechanism, result and prevention

Deliverable: A one-page troubleshooting sequence, a recorded spoken answer on intermittent faults, and a written production-failure story.

Day 3 — Migration and security

• Outline a legacy-to-cloud migration plan: inventory, dependencies, data copy and cutover approach, rollback, validation, decommissioning
• Write a security checklist for configuring an enterprise platform in your track, with one concrete setting per item
• Answer both questions aloud and cut each answer to a version that fits in a few minutes

Deliverable: A migration plan outline, a security checklist, and two recorded spoken answers.

Day 4 — Performance and scalability

• Write a performance-tuning routine: measure first, find the constraint, change one thing, re-measure, and record what you ruled out
• Work the SQL practice question on why an index is ignored, as an example of reading a slow query rather than guessing
• Solve the rolling failure-rate practice coding question, then answer how you would design for growth when requirements keep changing

Deliverable: A tuning routine, a worked explanation of the index question, a working solution to the rolling failure-rate question, and a spoken scalability answer.

Day 5 — Release risk and architecture decisions

• Write how you balance rapid deployment with stability: staged rollout, rollback, gating, change windows, and one case where you held a release back
• Write two architecture decisions in options, constraint, choice and cost format, and answer the architectural-decision question aloud with one of them
• Do the deadline-and-debt behavioral practice prompt and compare its structure with your own rollout story

Deliverable: A release-risk answer, two written architecture decision records, and one recorded architecture answer.

Day 6 — Outage stories under pressure

• Write the limited-documentation outage story: what you did to learn the system, who you asked, what you documented afterwards
• Rehearse the production-failure story with a timer so it stays tight and numbers are accurate
• Practise the outage-owner practice prompt from page to postmortem and note what your own stories lack

Deliverable: A written limited-documentation story, a timed production-failure story, and a list of gaps found in your outage stories.

Day 7 — Full mock and questions to ask

• Run a full mock covering one troubleshooting answer, one migration or security answer, one architecture decision and one outage story, ideally with another person listening
• Review the recording for missing trade-offs, vague numbers and answers that never state your own contribution
• Write two questions to ask your interviewers about the team and the environment it runs

Deliverable: A completed mock with written corrections and two questions to ask.

Outage, trade-off and ownership stories

Candidates report that the deep-dive stage includes cultural alignment, and the reported experience questions center on outages, limited documentation and architectural decisions. For this role, that means stories where you personally diagnosed, decided or recovered something in production, with numbers and a lasting fix. Reported guidance also suggests the STAR structure and owning your mistakes.

1. Describe a situation where you had to work with limited documentation to resolve a system outage.
2. Walk me through a complex architectural decision you made. What were the trade-offs?
3. Tell me about a mistake that reached production. What did you change afterwards so it could not recur?
4. Describe a time you had to explain a technical decision to a non-technical stakeholder in terms of business value or operational efficiency.
5. Tell me about a release where you had to choose between shipping quickly and keeping the system stable. What did you decide, and what did it cost?

Can you describe a time you had to troubleshoot a critical failure in a production network or platform environ

Medium · Technical & Domain Proficiency

Can you describe a time you had to troubleshoot a critical failure in a production network or platform environment?

Approach

1. Choose an incident where you carried the diagnosis, in a production network or platform environment: an outage, a degraded service or a bad configuration push. Open with the symptom as it was detected and who was affected, in two or three sentences, then move quickly to what you did.
2. Spend the Action part on method. Say what you checked first and why, how you split the problem by layer (physical or link, routing and DNS, authentication and permissions, the platform or connector itself, the most recent change), and what each check ruled out.
3. Separate mitigation from root cause. State what you did to restore service first (rollback, failover, disabling a change) and then how you proved the mechanism with evidence such as logs, a packet capture, change history or a monitoring graph.
4. Give the Result with the figures you really remember: time to mitigate, time to resolve, number of users or systems affected. Do not round up or invent numbers. Finish with the prevention step you put in place, for example an alert, a runbook or a change-control rule.
5. The usual way this story fails is a team-level narrative where you never say what you personally did, or a story that stops at the fix with no verification and no prevention. Rehearse it aloud so the Situation takes under a quarter of your time.

Follow-up

• How did you decide between rolling back and fixing forward, and what did each option risk?
• What did you tell non-technical stakeholders during the incident, and how often?
• What monitoring or alerting would have caught this earlier, and did you add it?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

• At what page depth does the offset version breach your latency budget, given your page size and row counts?
• What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?

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?