Analytica Software Engineer Interview Guide

The 60-second brief

Candidates describe Software Engineer work at Analytica as client project delivery across three kinds of system: modernizing older web applications, designing the architecture and infrastructure those applications run on, and keeping z/OS mainframe environments running. The requirements candidates report split by track: one needs modern web frameworks, the other z/OS utilities. Both ask for experience designing or maintaining large enterprise systems and for troubleshooting distributed or legacy systems. Cloud migration, DevOps, Agile in large organizations and client-facing or consulting experience are reported as extras. Candidates also list the day-to-day work as moving legacy systems toward cloud-ready designs, keeping infrastructure secure and maintainable, keeping deliverables aligned with business and functional leads, and taking part in code reviews and knowledge-sharing.

This guide is for engineers interviewing for a Software Engineer position at Analytica on either the web-modernization side or the mainframe side. It covers the stages candidates report (a technical screen, then a multi-part panel) and the five reported technical and experience questions, each with an answer outline: migrating a legacy application to a modern web architecture, z/OS reliability, infrastructure scalability versus short-term cost, debugging a production issue under time pressure, and adopting new technology without destabilizing established systems. It also covers the two reported design scenarios (breaking up a monolithic web application, high availability in a hybrid cloud) and practice coding, SQL and behavioral questions for the hands-on parts of the role.

Candidates report a technical screening that can follow the first recruiter contact within days, then a panel interview in several parts whose members include technical leads, functional managers and business stakeholders.

Focus areas

• Software Engineering
• Full-Stack Development
• System Architecture

Overview

Candidates describe the technical questions as real-world scenarios rather than abstract puzzles. Two of the reported questions are design questions (moving a legacy application to a modern web stack, and trading infrastructure scalability against near-term cost). One asks about your hands-on z/OS history. Two are experience questions about a production incident and about bringing new technology into stable systems. The reported design scenarios fit the same pattern: turning a monolithic web application into services, and building high-availability infrastructure across a hybrid cloud. Candidates list scalability patterns (load balancing, caching, database sharding), failure handling, and connecting modern services to existing z/OS infrastructure as the areas to be ready for.

That means most of your preparation goes into changing a system while a live one stays underneath. For each design question you should be able to say how traffic moves from old to new a slice at a time, where the system of record lives during the move, how you roll back, and what you would measure before calling a step done. Practise saying the numbers out loud: current peak load, the growth you design for, the capacity you actually buy, and the trigger that makes you revisit.

Your track matters. If you come from web development, you still need a credible account of how a modern service talks to a mainframe: wrapping CICS transactions or Db2 queries behind an API, keeping the mainframe as the system of record, and protecting online regions from web traffic spikes. If you come from the mainframe side, you need to explain JCL batch, CICS, Db2 recovery and abend diagnosis to someone who has never seen a dump, and to connect that work to the modernization projects around it.

Candidates report that the panel mixes technical leads with functional managers and business stakeholders. Write every answer in two layers: a plain statement of the problem, the decision and its business effect that anyone in the room can follow, then the mechanism (strangler routing, change data capture, Sysplex workload routing) for the engineers. If you name a tool, say what decision you made with it and why.

Where to focus your preparation

Candidates report two stages: a technical screen that can come soon after the first recruiter conversation, then a panel interview in several parts that brings in technical leads, functional managers and business stakeholders. Round-by-round content has not been reported, so the single focus area below covers both stages.

Preparation focus

Candidates report a technical screening first, sometimes within days of the recruiter's first call, followed by a multi-stage panel made up of technical leads, functional managers and business stakeholders. No one has reported which question comes up at which stage, so prepare the whole reported set for both. On the design side that means legacy-to-web migration, scalability versus cost, and the two reported scenarios (modernizing a monolith into services, and high availability across a hybrid cloud). On the experience side it means your z/OS work, a production incident under time pressure, and how you adopt new technology. Before the screen, ask the recruiter whether either stage includes writing code and whether the role sits on the web or the mainframe track, then weight your preparation accordingly. In the panel, open each answer with a summary a business stakeholder can follow and give the detail after it.

What to demonstrate

• Candidates report design scenarios on modernizing a monolithic web application and on high-availability infrastructure in a hybrid cloud
• Candidates report requirements that depend on track, so expect to show depth in your primary stack, whether modern web frameworks or z/OS utilities
• Trade-off reasoning on scalability patterns (load balancing, caching, sharding), failure handling and legacy z/OS integration
• Explaining technical decisions to a panel that candidates report includes functional managers and business stakeholders as well as technical leads

How to prepare

• Draw the migration of one legacy application you know to a modern web stack: routing layer, first slice, system of record, change data capture back to legacy tables and the rollback path
• Write a one-page hybrid-cloud availability design. Replication mode sets the recovery point (synchronous is near zero); failover automation sets recovery time. Cover the Direct Connect or ExpressRoute link (latency usually rules out synchronous replication over it), DNS or global load-balancer failover, and split-brain quorum
• Prepare a two-minute z/OS reliability account (or an honest adjacent-experience version) with abend, batch-window or recovery numbers
• Ask the recruiter which track the role is on and whether the screen or panel includes live coding

Where candidates lose points

Answering the legacy migration question with a big-bang rewrite and a single cutover weekend

Lead with incremental replacement: a routing layer in front of the legacy application moves one feature at a time, each entity keeps one system of record, new paths run in shadow mode and are diffed against legacy, and rollback is a routing change. Name the first slice you would move and why it is low-risk.

Bluffing z/OS detail you have not worked with, or giving a z/OS answer with no concrete mechanism

State your exact scope first (COBOL batch under JCL, CICS, Db2, operations or systems programming). Back reliability claims with real mechanisms such as return-code checks, restartable steps, GDG outputs, image copies and abend root-causing. If your exposure is thin, say so and map transferable experience instead of guessing at terms.

Treating scalability as microservices and Kubernetes from day one, or cost efficiency as picking the smallest instance

Separate decisions that are cheap to reverse (instance size and count) from expensive ones (data model, partition key, API contracts, tenancy). Keep the reversible ones lean and put design effort into the others. Bring numbers: current peak, forecast growth, the headroom you design for versus what you provision, and the utilization or latency trigger that makes you revisit.

An incident story that jumps from 'it broke' to 'I found the bug', with no mitigation and no follow-up

Structure it as detect, scope, check what changed, mitigate first (rollback, flag off, failover), then root cause, then prevention (test, alert, runbook). Name one hypothesis you ruled out and the evidence. Give time to detect, time to mitigate and how many users were affected.

Listing tools and frameworks instead of the decisions made with them, in jargon a business stakeholder on the panel cannot follow

For every tool you mention, say the problem, the alternative you rejected and the result. Rehearse each design answer twice: once in three sentences for a non-engineer (problem, decision, business effect), once in full technical depth, and open with the short version.

Questions & practice

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

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?

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?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

How would you approach the migration of a legacy application to a modern web architecture?

Medium · Technical & Domain Expertise

Approach

1. Assume a business-critical monolith (server-rendered pages or a thick client over one shared database) that must stay up during the move. First inventory features, integrations (batch jobs, file feeds, other apps reading its tables), peak load and latency baselines, and who owns each piece of data.
2. Reject the big-bang rewrite; use the strangler fig pattern: a reverse proxy or API gateway in front of the legacy app routes one feature or URL path at a time to the new stack while everything else falls through to legacy. The price is running two systems for a while instead of betting on one cutover.
3. Target shape: a React SPA whose static bundle sits on a CDN (or server-rendered pages with a CDN cache in front) calling versioned REST/JSON APIs; a stateless backend behind a load balancer, sessions in signed tokens or Redis, SSO via OIDC. Start as a modular monolith split by domain, not many microservices.
4. Before shifting traffic, pin down behavior with characterization tests built from recorded production inputs, then run the new path in shadow mode and diff its responses against legacy: for reads, or for writes only against an isolated copy of the data with payments, emails and outbound feeds stubbed out.
5. Keep exactly one system of record per entity. Ramp by percentage behind a feature flag, bucketed by customer or tenant so each user sees one version, with both paths writing the same store: the new code writes the legacy database through an anti-corruption layer. Rollback is then just a routing change.
6. Only once a slice serves all traffic, move its data to its own store and replicate its writes back to the legacy tables still in use with change data capture (e.g. Debezium into Kafka), not dual writes from app code, which drift silently. Alert on CDC lag and reconcile with row counts and checksums.

Follow-up

• How do you choose the first slice? Pick something real but low-risk (read-heavy, few write paths, a clean boundary) so you prove routing, deployment and monitoring before touching core transactions.
• What if the legacy code has no tests or documentation? Use access logs, job schedules and table usage to find which features are really used, retire dead ones instead of porting them, and confirm each surprising behavior with the business.
• How do login and sessions work while both systems serve users? Centralize authentication in one identity provider (SSO/OIDC) and have the gateway pass a token both stacks accept, so users never re-authenticate when a route moves.

What are the primary trade-offs when designing for infrastructure scalability versus short-term cost efficienc

Medium · Technical & Domain Expertise

What are the primary trade-offs when designing for infrastructure scalability versus short-term cost efficiency?

Approach

1. Frame it as the cost of being wrong in each direction. Building for scale early buys headroom with engineering time, idle capacity and distributed-system complexity; optimizing for cost now keeps spend low but risks an outage or a rushed re-architecture when load arrives.
2. Capacity: reserved or committed capacity lowers unit price but locks you in; on-demand plus autoscaling tracks load but costs more per hour and reacts in minutes, so it needs a minimum floor; spot or preemptible instances are cheapest but can be reclaimed, so use them only for interruptible work.
3. Architecture: scaling up one bigger machine is cheap and simple until it hits a ceiling; scaling out needs stateless services, load balancing, partitioned data and more operational work. Redundancy is a cost choice too: a standby database in a second zone roughly doubles that database's bill.
4. Separate one-way from two-way doors. Instance size and count are easy to change later, so buy them lean; the data model, partition key, ID scheme, tenancy model and public API contracts are costly to change, so spend design effort there even while running on minimal infrastructure.
5. Use numbers: current peak load and a 12 to 18 month forecast. A common rule of thumb is to design so the architecture reaches about 10x without a rewrite, but provision for about 2x. Track unit cost (per request or per customer) and agree on triggers to revisit, e.g. sustained utilization above ~70%.
6. Weak answers equate scalability with microservices and Kubernetes from day one, or cost efficiency with the cheapest instance type. Engineering time is often the largest cost; cheap enablers like a stateless app tier, idempotent APIs, queues at boundaries and load tests keep options open.

Follow-up

• When would you commit to reserved capacity instead of autoscaling? Commit for the steady baseline you are confident will persist, and cover the variable peak above it with on-demand or spot capacity that autoscales.
• How do you know it's time to invest in scaling? Watch leading signals (utilization trending toward limits, p99 latency nearing the SLO, connection or storage ceilings) and load test to find the breaking point before customers do.
• Is a managed service a cost or a saving? Its invoice is usually higher than self-hosting, but it removes patching, upgrades and on-call work, so compare total cost including engineering hours.

Describe a time you had to debug a critical production issue under significant time pressure.

Medium · Technical & Domain Expertise

Approach

1. A strong story shows composure plus method: you stopped the damage, communicated, and found the real cause without guessing. Pick an incident where you personally drove the diagnosis and the impact was real; avoid stories where luck found the fix or where the point is someone else's mistake.
2. Set the stakes in two sentences: what broke, who was affected, how it was detected (alert or customer report), and why the clock mattered, e.g. "payment errors at 30% during a launch, with an SLA breach an hour away."
3. Walk the triage in order: confirm scope and start time, check what changed (deploy, config, traffic, a dependency), then use metrics, logs and traces to narrow to one component. Name a hypothesis you ruled out and the evidence that ruled it out; that shows reasoning rather than heroics.
4. Show that you mitigated before root-causing: rollback, feature flag off, failover, scaling out or shedding load, and why that choice was safe. Mention how you coordinated, such as one incident channel, a clear owner, and status updates to stakeholders at fixed intervals.
5. Close with the root cause, the permanent fix, and what stops a repeat: a regression test, a new alert, a runbook or a deploy guardrail. Quantify time to detect, time to mitigate, users or requests affected, and recurrences since. Without this follow-through the story reads as firefighting.

Follow-up

• Why roll back rather than fix forward? Roll back when the latest change is the likely cause and rollback is safe (no irreversible migration); fix forward only when rollback is impossible or riskier and the fix is small and verifiable.
• How did you know the mitigation, not a coincidence, stopped the errors? Show the error rate falling right at the rollback or flag flip and staying down under normal traffic, ideally confirmed by reproducing the fault in staging.
• How did you keep non-technical stakeholders informed? Send short updates on impact, current action and time of the next update, and hold off on naming a root cause until the evidence confirms it.

Suggested practice checklist

The plan follows the reported question set: one day each for migration design, scalability and hybrid-cloud availability, and track depth with z/OS integration, then hands-on practice for the engineering topics, experience stories, and a full panel-style rehearsal.

Day 1 — Pin down the format and your track

• Ask the recruiter whether the technical screen or the panel includes writing code, and whether the role sits on the web-modernization or the mainframe track.
• List three systems you have worked on that involved legacy code, infrastructure scaling or a production incident, with one number for each (load, latency, cost, outage length).
• Read all five reported questions and mark each as strong, partial or weak for your background.

Deliverable: The recruiter's answer on format and track, a three-system inventory with a number for each, and a strong/partial/weak rating for each reported question.

Day 2 — Legacy-to-web migration design

• Answer the legacy migration question aloud using strangler routing: inventory, first slice, shadow traffic with response diffing, percentage ramp behind a flag, routing rollback.
• Work the reported scenario of modernizing a monolithic web application into microservices: draw domain boundaries, decide which stays a modular monolith, and place change data capture back to legacy tables.
• Write answers to the three follow-ups: choosing the first slice, untested legacy code, and shared login across both stacks.

Deliverable: A recorded migration answer, one architecture diagram for the monolith scenario, and written follow-up answers.

Day 3 — Scalability, cost and hybrid-cloud availability

• Answer the scalability-versus-cost question with a worked example: current peak, an 18-month forecast, the capacity you would commit to versus autoscale, and your revisit trigger.
• Design high-availability infrastructure in a hybrid cloud: load balancing across zones, caching tier, replication between on-premises and cloud, failover steps, and the recovery point and time objectives each choice gives.
• Cover the hybrid-only parts of that design: the dedicated network link and what happens when it partitions, the WAN latency that pushes cross-site replication to asynchronous, and global DNS or global load-balancer failover with health checks and a quorum rule against split-brain.
• Write one paragraph on when you would shard a database and what partition key you would pick for a system you know.

Deliverable: A sized capacity example, a hybrid-cloud availability diagram with failover steps and the link-failure case, and a sharding paragraph.

Day 4 — Track depth and z/OS integration

• Answer the z/OS reliability question: scope in one sentence, one system and its reliability requirement, prevention (change control, return-code checks, restartable steps), detection and abend diagnosis, numbers.
• If your z/OS exposure is limited, write the honest version that maps batch pipelines, transactional databases and change control onto the same structure.
• Design how a web front end calls mainframe transactions and name the mechanisms: z/OS Connect for REST over CICS or IMS, CICS web services, MQ for asynchronous decoupling, Db2 REST services or change-data-capture replicas for read offload, with caching and rate limits protecting online regions and the mainframe as system of record.
• For the web track, prepare depth in your primary stack: one framework you can defend in detail, REST API versioning, authentication and sessions, and front-end performance.

Deliverable: A two-minute z/OS answer (or an adjacent-experience version), a web-to-mainframe integration diagram naming each mechanism, and a one-page web-stack depth sheet.

Day 5 — Hands-on engineering practice

• Solve the merge of partitioned event streams with bounded lateness using a min-heap keyed on timestamp, and state its complexity.
• Solve the idempotency fingerprint question (canonical key ordering, number and whitespace normalization, then hash) and the heaviest-tenants-under-memory-pressure question.
• Write the keyset pagination query and the per-tenant active cap that holds under concurrent creates, and explain the locking or constraint choice.

Deliverable: Three working coding solutions with complexity notes and two SQL solutions with a sentence on concurrency for each.

Day 6 — Experience stories

• Write your production-incident story as detect, scope, what changed, mitigation, root cause, prevention, with time to detect and time to mitigate.
• Write your new-technology answer: two specific learning sources, your adoption filter, one pilot you ran or declined, and its measured result.
• Write one story about a contract change that broke callers you did not own, and one about a design you argued against and lost.

Deliverable: Four written stories, each with a number and a named decision you made.

Day 7 — Panel-style rehearsal

• Run a mock with a friend acting as a business stakeholder: answer the migration, scalability and z/OS questions, opening each with a three-sentence version before the technical depth.
• Run the incident and new-technology stories under the same mixed-audience framing and cut any sentence that names a tool without a decision.
• Write three questions to ask the panel about current modernization work and how the web and mainframe tracks work together.

Deliverable: A completed mock covering all five reported questions, a list of the sentences you cut, and three questions for the panel.

Behavioural preparation

Three of the five reported questions are about your own experience: your z/OS work and how you kept it reliable, a production issue debugged under time pressure, and how you take up new technology without destabilizing established systems. Candidates report that the panel includes functional managers and business stakeholders alongside technical leads. Each story therefore needs a business-level outcome as well as the technical detail, and a decision that was clearly yours.

1. Describe a time you had to debug a critical production issue under significant time pressure.
2. Describe a change you shipped to an endpoint or interface whose callers you did not own: how you found out who actually read it, what you released first, how long you gave them, and how you decided removal was safe.
3. Describe a design you argued against and lost: the specific failure you predicted, the evidence you brought, what you did once the decision went the other way, and whether the prediction came true.

Explain your experience with z/OS environments and how you ensure system reliability.

Hard · Technical & Domain Expertise

Approach

1. Show that your z/OS work is hands-on and specific and that reliability comes from deliberate practice, not luck. Open with your scope in one sentence: which subsystems (COBOL batch under JCL, CICS, Db2 for z/OS, IMS, RACF) and which role (application developer, systems programmer, operations).
2. Anchor on one system and the requirement that defined reliability for it, e.g. "a nightly batch cycle that had to finish before the online CICS regions opened." Name the job dependencies in the scheduler, the batch window, and what a miss cost downstream.
3. Name the prevention mechanisms you actually used: promotion through test and QA LPARs under change control, COND or IF/THEN checks so later steps skip on bad return codes, rerunnable steps that write new GDG generations, and Db2 image copies plus logs so RECOVER can restore a table space.
4. If your role touched the platform, add the availability layer: Parallel Sysplex with Db2 data sharing and CICSPlex SM workload routing, so work moves to a surviving LPAR during an outage or rolling maintenance, and GDPS or synchronous disk mirroring for site-level recovery.
5. Show detection and diagnosis: SMF and RMF data for CPU and I/O trends, alerting on abends, reading the dump for an S0C7 (invalid packed-decimal data) or an x37 out-of-space abend, and fixing the cause (input validation, space allocation) instead of just resubmitting the job.
6. Quantify: abends per month before and after, batch finish time versus the window, time to recover, CPU or MSU savings. If your exposure is limited, say so and map adjacent experience (batch pipelines, transactional databases, change control); a bluff on z/OS detail fails at the first follow-up.

Follow-up

• How do you rerun a failed batch job safely? Use RESTART=stepname on rerunnable steps whose GDG outputs are coded DISP=(NEW,CATLG,DELETE); a generation an earlier step made in the first run is now (0), not (+1), so fix those references.
• How would you expose mainframe transactions to a web front end? Wrap CICS transactions or Db2 queries behind a REST API layer, keep the mainframe the system of record, and add caching and rate limits so web spikes don't swamp online regions.
• What do you do with an S0C7 at 2 a.m.? Identify the bad record from the job output and dump, bypass or correct it per the runbook, restart from the failed step, then add upstream validation so it can't recur.

How do you stay updated with emerging technologies while maintaining stability in established systems?

Easy · Technical & Domain Expertise

Approach

1. The question has two halves: show that you keep learning, and that you have a filter before anything new touches a system people depend on. An answer that is only a list of newsletters, or only "if it works, don't touch it," covers half of it.
2. Keep the learning part short and specific: two or three real sources and a cadence, such as release notes for the tools you run, conference talks or RFCs in your area, and a side project to try things hands-on. "I read the PostgreSQL release notes each major version" beats "I read blogs."
3. Describe your adoption filter: start from a real problem, not novelty; run a time-boxed spike with success criteria; weigh maturity, support, operational cost, team skills and the cost of backing out. Record the decision in an architecture decision record so the reasoning outlives the meeting.
4. Explain how new technology enters a stable system safely: first on a non-critical service or internal tool, behind an interface or feature flag, rolled out gradually with a rollback path. Stability also means currency: keep existing runtimes and dependencies on supported, patched versions.
5. Give one concrete example, e.g. "piloted a new tool on one internal service for a quarter, measured the result, then expanded," with numbers such as incidents during rollout, latency or cost change, or hours saved. A well-argued decision not to adopt something is as strong as a successful adoption.

Follow-up

• Which technology did you decide not to adopt, and why? Describe the problem it promised to solve, what your spike showed, and which cost (operational burden, immaturity, missing skills) outweighed the benefit.
• How do you keep long-lived systems from falling behind on versions? Stay on supported LTS releases, schedule regular small upgrades instead of big jumps, and automate dependency updates backed by a test suite you trust.
• How would you persuade a risk-averse team to try something new? Start from the failure they fear, show how the pilot bounds it (one service, a reversible change, a priced exit cost), and let them set the bar for success before it starts.

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

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?