Interview guides · a B&A

a B&A Software Engineer Interview Guide

a B&A Software Engineer interview guide: 4 reported rounds, Java, SQL, Pega and PeopleSoft topics, architecture and security questions, and a 7-day plan.

The 60-second brief

Candidates describe a firm that delivers software and systems work for client environments, federal and commercial. Typical projects they list are custom enterprise applications, integrations with third-party platforms, and secure systems. PeopleSoft and Pega appear by name, and some roles sit on projects that require a TS clearance. Job titles reported under this heading run from Junior Java Developer to Lead Application Architect, with Database Developer, Software Developer-Business Analyst and Systems Engineer in between. Candidates describe the day-to-day work as translating business requirements into technical specifications and then into software.

This guide is for candidates interviewing for a Software Engineer position at a B&A, at any level from junior Java developer to application architect. It covers the four reported rounds, the architecture, database, security and integration questions candidates describe, the leadership and behavioral prompts, and a seven-day plan that works through them. It does not cover any one team's internal practices, because candidate reports do not describe them.

Candidates report four rounds spread over roughly 3-5 weeks (one report says 3 to 6): Technical Screening, Deeper-Dive Interviews, Collaborative Evaluation and Practical Discussions. The reports describe each stage only in broad terms.

Focus areas

Pega Development
PeopleSoft Development
Java

Overview

The work candidates describe is full-lifecycle: turning business requirements into technical specifications, then design, prototyping, deployment and long-term maintenance, with technical debt to find and fix along the way. Collaboration with stakeholders, project managers and other engineering teams comes up repeatedly. For preparation this means one interview can move from a SQL query to a system diagram to a story about a stakeholder, so you need all three ready, and a short list of resume projects you can describe at any depth.

The topic mix candidates report is Pega development, PeopleSoft development, Java, software architecture and .NET (C#). The requirements they describe list Java, .NET or an equivalent language, SQL and database design, and experience with enterprise development lifecycles as must-haves. TS-cleared experience, AWS or Azure, and Pega or PeopleSoft familiarity are listed as nice-to-haves. Choose your primary language and be ready to explain why you pick one pattern over another in it. If you are on the Pega track, review case types and stages, data pages and REST or SOAP connectors, rule resolution and the class hierarchy, guardrail scores, and the CSA and CSSA certification levels. If you have never touched Pega or PeopleSoft, prepare the integration reasoning (data mapping, failure handling, versioned interfaces) so you can discuss those platforms from first principles.

The reported questions are mostly spoken, open-ended ones: monolith versus microservices in a large enterprise application, high availability and data integrity in a database schema, security with sensitive data in a government-facing environment, integrating a legacy system such as PeopleSoft with a modern web application, a high-concurrency design, performance versus security, choosing a technology stack, and disaster recovery and failover. Example scenarios candidates cite also include tuning a SQL query for a high-volume transactional database, managing dependencies in a large Java project, zero-downtime updates and a secure protocol between two microservices. Practise saying a design out loud with trade-offs, and keep your hands-on SQL sharp.

Leadership prompts are reported as well: technical disagreements, conflicting deadlines, explaining an architectural decision to a client, and building a code-review culture. Candidates are advised to use the STAR structure and to expect detailed questions about every project on their resume, particularly the architectural challenges. If the position needs a clearance, bring current documentation and expect to state your clearance status at the first screen.

The a B&A interview process

These are the four stages in the order candidates list them. Reports describe each in a sentence, so the guidance below ties each stage to question types without claiming which question appears where.

Technical Screening

Candidates describe this first stage as an assessment of baseline technical proficiency. The requirements they report put Java or .NET, SQL and database design at the base of the role, and candidates for clearance-dependent roles are advised to be ready to discuss their status at the initial screen. Use this stage to get core-stack fundamentals fluent: be able to write or read code in your main language, explain a query plan, and give enterprise-specific trade-offs instead of a textbook list when you define an architecture concept.

What to demonstrate

Baseline technical proficiency, as candidates describe this stage
Java, .NET or equivalent language fundamentals, which the reported requirements list first
SQL and database design fundamentals

How to prepare

Pick your main language and refresh collections, concurrency, exception handling and how you manage dependencies in a large project.
Write a SQL query, look at its execution plan, add an index and compare, so you can tune a query for a high-volume transactional table.
Prepare a one-minute explanation of monolith versus microservices that covers deployment, data ownership, transactions and operating cost.
If a clearance applies, have your documents and your current status ready to state plainly.

Deeper-Dive Interviews

Described as a series of interviews on architectural thinking, problem-solving and cultural alignment. Candidates list design patterns, security-first design and integration patterns among the architecture topics. Expect to move between a design discussion and a story about how you worked. Because several interviews make up this stage, keep your answers consistent: the same project should show the same decisions however many times you retell it.

What to demonstrate

Architectural thinking and trade-off analysis
Problem-solving skills on ambiguous requirements
Cultural alignment, which reports say this stage covers

How to prepare

Build a short design vocabulary: layered and service-oriented structures, adapters around legacy systems, queues, caching, and where authentication and authorisation sit.
For every resume project, write the architectural challenge, the options you weighed and why you chose one.
Rehearse security and integration discussions: sensitive data handling, and wrapping a legacy system such as PeopleSoft behind a stable interface.
If you are on the Pega track, review case types and stages, data pages and connectors (REST or SOAP), rule resolution and class hierarchy, guardrail scores, and the CSA and CSSA certification levels.

Collaborative Evaluation

Candidates report that several team members take part in this stage, giving a broader view of your skills than any one interviewer. Plan for different audiences: an engineer may want implementation detail while a project manager or analyst wants impact and risk. The requirements candidates describe stress working with stakeholders, project managers and other engineering teams, so the way you explain and collaborate matters alongside technical depth.

What to demonstrate

Technical skills seen from more than one person's viewpoint
Collaboration across engineering, project and business roles
Ability to explain a decision to people with different backgrounds

How to prepare

Give each of your main projects two tellings: a detailed one for engineers and a short outcome-and-risk one for a non-technical listener.
Practise explaining a complex architectural decision to a client without jargon, and write down the trade-off you asked them to accept.
Prepare answers on prioritising conflicting deadlines and on raising code quality through peer review.
Practise sketching a design on a whiteboard or shared screen while talking through it.

Practical Discussions

Candidates describe this stage as conceptual discussion that moves toward the practical realities of the job. Expect to connect high-level reasoning to how work is done in practice, with examples from your own projects.

What to demonstrate

Moving from high-level concepts to concrete working practice
The practical realities of the role, as reports describe this stage

How to prepare

Prepare a technology-stack selection process you can narrate: requirements, constraints, team skills, security posture, and how you would test the choice.
Rehearse performance versus security trade-offs with an example where you accepted a cost on one side.
Candidates advise asking about the team's biggest technical challenge and how it balances innovation with security, so write three questions along those lines.
Prepare an example of a project where delivery was shaped by security or operational constraints, and what you did about them.

Where candidates lose points

Answering monolith versus microservices with definitions only

Frame it for a large enterprise application: deployment independence against operational overhead, data ownership per service, transactions that now span services, team structure, and the cases where a well-structured monolith is the better choice. End with the criteria you would use to decide.

Treating security as a closing remark in a design answer

Reported questions pair performance with security and mention government-facing data. In each design answer, say what data is sensitive, how it is protected in transit and at rest, who may access it, what is logged for audit, and what the security measure costs in latency.

Describing legacy integration as just building an API on top

For the PeopleSoft-style question, cover data mapping, an adapter or anti-corruption layer so the legacy model does not leak into the new application, what happens when the legacy call fails or times out, retries that cannot apply twice, and how to migrate in stages.

Telling a performance story with no measurement

Open with the baseline number, name the tool that located the cause, show the change, and report the same metric afterwards. If you cannot give numbers for a project, choose one where you can.

Being unable to go deep on a resume project

Candidates are advised to speak in detail about every listed project, especially its architectural challenges. For each one, write the problem, the options you considered, your own contribution and what you would change; remove items you cannot defend.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

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

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.
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.
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.
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?

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

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.
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.
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.
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

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.
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.
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.
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?

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

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.
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.
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.
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?

Explain the difference between monolithic and microservices architectures in the context of a large-scale ente

Medium · Technical and Domain Expertise

Explain the difference between monolithic and microservices architectures in the context of a large-scale enterprise application.

Approach

Define both precisely: a monolith is one deployable unit with in-process calls and usually one database; microservices are independently deployable services that each own their data and talk over the network (REST, gRPC or a message broker).
Give the monolith's real strengths for an enterprise app: one ACID transaction can span modules, debugging is a single stack trace, one build and one deploy. Its costs: every change redeploys everything, the whole app scales as one unit, and module coupling grows unless boundaries are enforced.
Give the microservices costs as concretely as the benefits: independent deploy, scaling and fault isolation, paid for with network latency, partial failure, no cross-service joins, eventual consistency (sagas with compensating actions, the transactional outbox), versioned contracts and distributed tracing.
Name the middle ground: a modular monolith with enforced package boundaries, split along bounded contexts. Extract a service only when a part has a different scaling profile, release cadence or security boundary.
For migrating an existing system, describe the strangler fig pattern: route one capability at a time to the new service behind a facade, keep the old path until traffic and data reconcile, then retire it.

Follow-up

How would you keep an order and its inventory reservation consistent across two services without a distributed transaction?
How would you trace one slow request that crosses five services?
Which part of a large Java monolith would you extract first, and how would you decide?

How do you ensure high availability and data integrity when designing a complex database schema?

Medium · Technical and Domain Expertise

Approach

Put integrity in the schema, not only in application code: primary keys, foreign keys, NOT NULL, UNIQUE and CHECK constraints, correct types (DECIMAL for money, never floating point), and 3NF for transactional tables. Denormalise only deliberately, with a named mechanism that keeps the copy in sync.
Handle concurrent writes explicitly: know the default isolation level (READ COMMITTED in PostgreSQL, Oracle and SQL Server), and protect read-modify-write with SELECT ... FOR UPDATE, a conditional UPDATE ... WHERE, or optimistic locking on a version column.
For availability, describe primary-replica replication and its trade-off: synchronous replication gives zero data loss on failover at the cost of write latency; asynchronous is faster but can lose the last transactions. Pair it with automatic failover (SQL Server Always On, Oracle Data Guard, Patroni for PostgreSQL) and connection retry logic.
Backups are part of the design: full backups plus transaction-log or WAL archiving for point-in-time recovery, copies kept off the primary site, and scheduled test restores, since an untested backup proves nothing.
Plan schema changes that do not take the system down: expand and contract (add a nullable column, backfill in batches, switch reads and writes, then add the constraint and drop the old column), and build indexes online (CREATE INDEX CONCURRENTLY in PostgreSQL, ONLINE = ON in SQL Server Enterprise).

Follow-up

An asynchronous replica is promoted after the primary fails: what data can be lost, and how would you find it?
How would you add a NOT NULL column to a very large, busy table without a long lock?
Where would you add an audit trail, and would you use triggers, temporal tables or application-level logging?

What security best practices do you implement when working with sensitive data in a government-facing environm

Medium · Technical and Domain Expertise

What security best practices do you implement when working with sensitive data in a government-facing environment?

Approach

Start by classifying the data (PII, financial, or controlled government information) and deciding which controls each class needs; the answer should then follow the data through storage, transit, access and logging.
Access: least privilege with role-based access, MFA for people, narrowly scoped service accounts for systems, separation of duties for production changes, and periodic access reviews that remove stale accounts.
Encryption: TLS 1.2 or later in transit, encryption at rest with keys held in a KMS or HSM and rotated on a schedule, and FIPS 140-validated cryptographic modules where the contract requires them. Secrets live in a vault, never in source or config files.
Secure coding: bind parameters for every query (no string-built SQL), input validation and output encoding against injection and XSS, the OWASP Top 10 as a review checklist, and SAST plus dependency scanning in the CI pipeline so a known CVE blocks the build.
Audit and compliance: log who accessed which record without logging the sensitive values themselves, ship logs to a central tamper-evident store, and map controls to the framework the system is assessed against (for US federal systems, typically NIST SP 800-53, with FedRAMP for cloud services and STIGs for hardening).

Follow-up

How do you keep sensitive fields out of logs, stack traces and error responses?
How would you rotate a database credential used by a running application without downtime?
A critical CVE appears in a dependency the week of a release: what do you do?

How do you approach the integration of legacy systems, such as PeopleSoft, with modern web applications?

Medium · Technical and Domain Expertise

Approach

Inventory the supported integration surfaces before writing code. For PeopleSoft that means Integration Broker service operations (REST or SOAP) and Component Interfaces, which run the component's PeopleCode business logic; writing straight into PeopleSoft tables bypasses that validation and is the shortcut to avoid.
Put an anti-corruption layer between the two: the web app calls a stable internal API that translates to the legacy contract, so legacy field names, codes and quirks never leak into the modern code base and the legacy side can change behind it.
Choose synchronous or asynchronous per flow: synchronous reads when the user needs current data; queued, asynchronous writes for anything the legacy system processes slowly or in batch. Give every write an idempotency key, retry with exponential backoff, and route repeated failures to a dead-letter queue someone actually monitors.
Keep the two systems' data honest: change data capture or scheduled extracts into a read store for reporting, plus a reconciliation job that compares counts or checksums and flags drift instead of trusting that every message arrived.
Secure and test the seam: a dedicated least-privilege integration account, contract tests against the legacy interface, and, if the end goal is replacement, a strangler fig rollout that moves one capability at a time.

Follow-up

The legacy system goes offline every night for batch processing: how does the web app behave during that window?
How would you detect and repair records that have drifted between the two systems?
When is reading directly from the legacy database acceptable, and when is it not?

Walk me through the design of a scalable system that handles high-concurrency requests.

Medium · System Design and Architecture

Approach

Pin the numbers first: peak requests per second versus average, read/write ratio, latency target (p99, not the mean), and which operations need strong consistency. The design for a read-heavy lookup service differs from one taking concurrent writes on the same records.
Keep the application tier stateless behind a load balancer so it scales horizontally; move session state into a shared store such as Redis or into signed tokens. Size thread and connection pools to what the database can take, since the pool, not the app server, is often the first limit.
Split the paths: reads served through a cache (cache-aside with a TTL, CDN for static content) and read replicas; writes buffered through a queue to absorb bursts and processed by workers, with the data partitioned by a key that spreads load evenly.
Make concurrent writes correct, not just fast: atomic conditional updates (UPDATE ... SET stock = stock - 1 WHERE stock > 0), optimistic locking with a version column, and idempotency keys so a client retry after a timeout cannot apply twice.
Protect the system under overload: rate limiting (token bucket), timeouts on every outbound call, circuit breakers and bulkheads, and backpressure that rejects early with a 429 or 503 rather than queuing forever. Validate the design with a load test that watches p99 latency and error rate.

Follow-up

One record receives half of all writes: how do you deal with that hot key?
A popular cache entry expires and thousands of requests hit the database at once: how do you prevent the stampede?
A client times out and retries a payment request: how do you guarantee it is applied exactly once?

How do you balance trade-offs between system performance and security requirements?

Medium · System Design and Architecture

Approach

Frame it as risk management: classify the data, threat-model the system (STRIDE is a usable checklist), and separate controls that compliance makes mandatory from ones that are tunable. Only the tunable ones are part of the trade-off.
Measure before trading anything away: profile where latency actually goes. Security controls are rarely the bottleneck once they are implemented well, and many costs have a fix that keeps the control.
Give concrete examples. TLS cost falls with keep-alive connections, session resumption and TLS 1.3 (a one-round-trip handshake; its 0-RTT mode allows replay, so it suits only idempotent requests). Locally verified signed tokens avoid a per-request call to the identity provider, at the cost of slower revocation, which short token lifetimes limit.
Name the trade-offs that are real: field-level encryption stops the database from indexing or range-querying that column (deterministic encryption or a blind index allows equality lookups but leaks which rows match); caching authorization decisions speeds requests but delays revocation; password hashing with bcrypt or Argon2 is slow on purpose and must not be tuned for speed.
Close with governance: write the decision and the residual risk down (an architecture decision record), get the risk owner to accept it explicitly, and set a trigger for revisiting it.

Follow-up

A team wants to cache authorization results for ten minutes to cut latency: what do you say?
How would you support search on an encrypted column?
When is terminating TLS at the load balancer acceptable, and when do you need encryption all the way to the service?

Describe your process for selecting a technology stack for a new project.

Medium · System Design and Architecture

Approach

Start from requirements and constraints, not preferences: functional needs, non-functional targets (load, latency, availability), and environment constraints such as on-premises versus cloud, any software a client environment does or does not permit, and accreditation or security requirements.
Weigh the factors that decide most enterprise projects: what the team already knows (Java or .NET), what it must integrate with (for example PeopleSoft or Pega), licensing and support costs, the vendor's long-term-support lifecycle, the library ecosystem, and the security track record and patch cadence of each candidate.
Make the comparison explicit: a weighted decision matrix across those criteria, then a short spike or proof of concept on the riskiest requirement rather than on the easiest one.
Separate reversible from irreversible choices: a logging library is easy to swap, a primary database or a platform commitment is not, so spend the evaluation effort on the latter. A proven, well-understood option usually wins unless a requirement rules it out.
Record the outcome in an architecture decision record: the options considered, why the winner won, the known downsides, and what would make the team revisit it.

Follow-up

Tell me about a stack choice that turned out wrong: when did you notice, and what did you do?
How would you choose between Java and .NET for a new service in an organization that runs both?
How do you stop each new project from adding yet another framework?

How do you handle disaster recovery and system failover in a distributed architecture?

Medium · System Design and Architecture

Approach

Start with the business targets: RPO (how much data loss is tolerable) and RTO (how long recovery may take), set per system, because they decide the strategy and its cost.
Map targets to a strategy tier: backup and restore (cheapest, slowest), pilot light, warm standby, or active-active across sites. State the trade-off: lower RPO and RTO cost more in standing infrastructure and complexity.
Cover the data layer: synchronous replication for zero data loss within a region, asynchronous across regions (which means RPO above zero), point-in-time recovery from transaction logs, and immutable or offline backup copies so ransomware or an operator error cannot destroy every copy.
Describe the failover mechanics and their main hazard: health checks driving DNS or load-balancer failover (mind the DNS TTL), leader election through a consensus system such as etcd or ZooKeeper, and fencing so an old primary cannot keep accepting writes and cause split brain.
Make recovery repeatable and proven: stateless services, idempotent operations, infrastructure as code to rebuild an environment, written runbooks, regular DR drills that measure the actual RTO, and a failback plan as well as a failover plan.

Follow-up

The network between your two sites partitions: how do you prevent both sides from acting as primary?
Your asynchronous replica is thirty seconds behind when the primary is lost: what do you tell the business, and what do you do about the missing writes?
How often would you run a DR test, and what must the test prove to count?

Describe a situation where you had to explain a complex architectural decision to a client or stakeholder.

Medium · Behavioral and Leadership

Approach

Structure it with STAR and pick a decision with a real trade-off, such as choosing queued integration over a direct database link, or a modular monolith over microservices, where you personally owned the explanation.
Show the translation: replace component names with what the stakeholder cares about (cost, schedule, risk, compliance, what users will notice), and use one simple diagram rather than the full architecture.
Show that you presented options, not just a conclusion: two or three alternatives with their costs and risks, your recommendation, and what the stakeholder would be giving up under each.
Describe how you checked understanding rather than assumed agreement, for example by having the stakeholder restate the risk they were accepting, and how the decision was recorded.
End with a measurable result and a lesson. The mistake that sinks this answer is a jargon-heavy explanation, or a story in which the stakeholder was simply won over and no trade-off was ever acknowledged.

Follow-up

What did the stakeholder push back on, and did it change your recommendation?
How did you confirm they understood the risk instead of just agreeing?
What would you have done if they had chosen the option you recommended against?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan follows the reported loop: stack and resume review first, then architecture, databases, security and integration, resilience, behavioral stories and a final mixed run.

Day 1 — Map the loop and your stack

Write the four reported rounds in order and note the question types each could cover.
List the technologies from the reported requirements (Java, .NET, SQL, Pega, PeopleSoft, AWS or Azure) and mark each as strong, working or weak.
For every project on your resume, write its architectural challenge, the options you weighed and your own contribution.

Deliverable: A one-page loop map, a stack self-rating, and a project sheet with the architectural challenge of each resume project.

Day 2 — Architecture styles and high concurrency

Write a comparison table of monolith and microservices for a large enterprise application: deployment, data ownership, transactions, operations and team structure.
Sketch a high-concurrency design on paper: entry point, stateless services, queue, cache, database and where it saturates first.
Say both answers out loud and note where you reached for jargon without a reason.

Deliverable: The comparison table, one annotated concurrency diagram and a spoken run of each answer.

Day 3 — Database design and SQL tuning

Write a checklist for high availability and data integrity in a schema: constraints, transactions, replication, backups and recovery testing.
Take a slow query on a large table, read its execution plan, add or change an index and record before and after.
Do the keyset paging and live-backfill exercises from the practice library.

Deliverable: A schema integrity checklist, a before-and-after plan note for one query, and two completed SQL exercises.

Day 4 — Security and legacy integration

Write a security checklist for sensitive data: classification, encryption in transit and at rest, authentication, least privilege and audit logging.
Sketch an adapter between a legacy system such as PeopleSoft and a web application, including timeouts, retries and data mapping.
Design a secure channel between two microservices using mTLS with certificates from an internal CA (or a service mesh such as Istio or Linkerd), short-lived signed service tokens (OAuth2 client credentials or JWT) for authorisation, certificate rotation, and FIPS-validated cipher suites where a contract requires them. List what each costs in latency, then decide where you would accept that cost.

Deliverable: A security checklist, a legacy integration diagram with failure paths, and a one-paragraph performance-versus-security argument naming the building blocks you chose.

Day 5 — Resilience and technology choice

Outline a disaster recovery and failover plan for a distributed system: what is replicated, how failover is triggered, and how you test it.
Write how you would ship a major update with zero downtime, for example parallel environments or expand-then-contract schema changes.
Build a decision matrix for choosing a technology stack for a new project and fill it in for a case from your own experience.
Work through the rolling failure-rate exercise from the practice library.

Deliverable: A recovery plan, a zero-downtime release outline, a filled decision matrix and one finished practice exercise.

Day 6 — Behavioral stories

Write STAR outlines for the performance optimisation, technical disagreement, conflicting deadlines and code-quality prompts, each with a measurable result.
Prepare a client-friendly explanation of one architectural decision, ending with the trade-off the client accepted.
Say each story aloud and cut anything that does not show your own action.

Deliverable: Four STAR outlines, one non-technical decision explanation and recordings or notes from spoken run-throughs.

Day 7 — Mixed rehearsal

Run a mixed session, answered aloud without notes: the monolith versus microservices question, the database high availability and integrity question, the sensitive-data security question and the technical disagreement story.
Answer the Java dependency-management scenario: a BOM or dependencyManagement block to pin versions, resolving transitive conflicts (mvn dependency:tree, enforcer dependencyConvergence), lockfiles, an internal artifact repository for air-gapped or cleared environments, and OWASP Dependency-Check or a similar scanner in CI.
If you are on the Pega track, review case types and stages, data pages and REST or SOAP connectors, rule resolution and class hierarchy, guardrail scores, and the CSA and CSSA certification levels. For .NET or PeopleSoft, prepare a short integration-level statement of your exposure.
Write your questions for the team about its technical challenges and how it balances innovation with security, and confirm clearance and on-site details if they apply.

Deliverable: A recorded mixed session with a list of weak spots to fix, a one-page dependency-management answer, and your final questions for the interviewers.

Stories for a client-facing engineering loop

Reports describe the Deeper-Dive and Collaborative Evaluation stages as covering problem-solving, cultural alignment and input from several team members, and the leadership prompts reach into mentoring and talking to non-technical stakeholders. Candidates are advised to use the STAR method and to keep the focus on their own contribution. Prepare one story per prompt, each with a decision you made, the evidence you used and a result you can state.

Describe a situation where you had to explain a complex architectural decision to a client or stakeholder.

Describe a time you had to optimize a piece of code that was causing significant performance bottlenecks.

Medium · Technical and Domain Expertise

Approach

Open with the symptom as a number you measured: a latency percentile, a batch run time, a query's CPU or row count. A story with no baseline is weak; choose a different one.
Show how you found the cause before changing anything: a profiler or thread dump for Java or .NET code, an execution plan for SQL, timing logs around an integration call. Say what the evidence ruled out as well as what it pointed to.
Name the mechanism you fixed (an N+1 query replaced by a join, a missing index, repeated object allocation in a hot loop, a synchronous call turned into a batch or a cache) and the cost you accepted, such as memory, staleness or readability.
Protect correctness: say how you showed the faster version returned identical results, and how you rolled it out so you could back it out.
Finish with the re-measured result in the same unit as the baseline and what you added so a regression gets caught next time, such as a benchmark, an alert or a plan check in review.

Follow-up

How did you know that code path, and not something else, was the bottleneck?
What did the optimisation cost in readability or maintainability, and was it worth it?
How would you have caught it earlier, or kept it from shipping at all?

Tell me about a time you had to manage a technical disagreement within your team.

Medium · Behavioral and Leadership

Approach

Choose a disagreement about a real technical decision, such as a pattern, a schema shape, build versus integrate, or how to handle a failure case, not a personality clash. State both positions fairly, including the strongest point on the other side.
Explain how you moved from opinion to evidence: a small spike, a benchmark, a written comparison against agreed requirements, or a security or compliance constraint that settled it. Say which criteria the group agreed on before judging the options.
Be clear about who made the final call and how (you, a lead, or an agreed team rule), and what happened to the option not chosen, for example a recorded decision with reasons and a date to revisit.
Give the outcome and the working relationship afterwards. If the other view won, say what you did to make it succeed; a story in which you were simply right teaches the listener little.
The mistake that sinks this answer is casting the colleague as stubborn or uninformed, or resolving it by escalating before any attempt to settle it on evidence.

Follow-up

What would you have done if the other person's approach had turned out to be right?
What if there was no way to test the two options before deciding?
How did your working relationship with that person change afterwards?

How do you prioritize tasks when faced with conflicting project deadlines?

Medium · Behavioral and Leadership

Approach

Use one concrete occasion where two or more deadlines collided: name each deliverable and who was waiting on it. A generic answer such as making a list shows no judgement.
State the ordering rule you applied: the consequence of missing each date, dependencies that block other people, remaining effort, and whether anything was fixed by a contract date, a release freeze or a compliance requirement.
Show the conversation: you told the project manager or stakeholders what would slip, offered options (cut scope, move a date, add help) and let the owner of the priority choose, with the decision in writing.
Say how you protected quality under pressure: scope came out before tests did, and deferred items went on a list with owners and dates.
End with what happened to every deadline, including the one that moved, and what you changed afterwards, such as earlier estimates or a regular priorities check with the stakeholders.

Follow-up

Two stakeholders each insist their item is the top priority. What do you do?
How did you tell the person whose deadline slipped, and how did they respond?
How do you choose between a small urgent fix and a larger piece of important work?

What steps do you take to foster a culture of code quality and peer review?

Medium · Behavioral and Leadership

Approach

Answer with practices you have put in place and what changed, not ideals. Lead with one example, such as a pull-request checklist or a rule that splits oversized changes.
Cover automation first: formatters, linters, static analysis, test gates in CI, and dependency and secret scanning. That leaves human reviewers free to look at design, error handling, security and naming instead of style.
Describe the review habits: small changes, a written list of what a reviewer checks, comments that give the reason and an alternative, an agreed response time so reviews do not stall, and your own code going through the same process.
Show mentoring: pairing a junior developer on a first change, explaining review comments, rotating reviewers. For a lead or architect role, add how you made a standard stick without blocking delivery.
Say how you knew it worked, for example fewer defects returned from testing, shorter review turnaround or fewer repeated comments, and be honest about what did not take and what you adjusted.

Follow-up

A senior engineer keeps merging without review. What do you do?
Reviews have become the bottleneck. How do you fix that?
What would you deliberately leave out of code review, and why?