Interview guides · AHU Technology

AHU Technology Software Engineer Interview Guide

AHU Technology Software Engineer interview guide: reported rounds, Oracle Cloud ERP and Order to Cash questions, cloud design prompts and a 7-day plan.

The 60-second brief

Candidates describe AHU Technology as a firm whose Software Engineer work sits in two areas: Oracle Cloud ERP and cloud applications. Reported projects include improving Order to Cash processes and building cloud-native solutions for government and enterprise clients. The engineer in this role is described as owning a cloud application from requirements gathering through architectural design, coding and deployment, working alongside Business Analysts and Project Managers. Day to day, candidates describe production troubleshooting, tuning existing code, keeping system documentation current and shipping releases with cross-functional teams. For preparation, that means you need to talk about a business process end to end (how an order becomes cash) as comfortably as you talk about code.

This guide is for engineers preparing for the AHU Technology Software Engineer loop. The requirements candidates describe list Oracle Cloud ERP experience (Order to Cash modules in particular), software development in Java, Python or a similar language, and cloud infrastructure experience, with Agile/Scrum, government-sector work and Oracle or cloud certifications as extras, and a range of roughly 3 to 7 years of experience. The guide covers the three reported rounds and the fifteen reported questions, which fall into domain expertise, system design and architecture, and behavioral and leadership groups.

Candidates report three rounds over about 3-5 weeks: a Technical Screening that checks the basics of the role's technical areas, Deep-Dive Sessions covering system design, hands-on problem solving and behavioral alignment, and a Final Assessment. For government-contract roles, candidates mention that extra vetting such as security or background checks can add time.

Focus areas

Oracle Cloud ERP
Order-to-Cash (O2C)
Cloud Architecture

Overview

The work candidates describe is enterprise application delivery: an ERP-centred business process (Order to Cash), custom cloud applications around it, and the integration between the two. The evaluation topics candidates report match that picture: data flow mapping between modules and external systems, when to configure the ERP and when to build custom code, security compliance in ERP systems, and disaster recovery planning. Preparation should therefore start from a process diagram, not from a list of algorithms.

The reported questions fall into three groups. The domain group asks about data integrity in an Order to Cash cycle, integrating custom applications with Oracle Cloud ERP, trade-offs of a government-contracted cloud environment, debugging a performance bottleneck in a distributed architecture, and the role of middleware in your latest cloud project. The design group covers a high-availability system for a large enterprise client, choosing one cloud service over another, balancing security with stakeholder access, refactoring a legacy system into a cloud framework, and recovery planning. The behavioral group covers explaining a technical issue to a non-technical client, conflicting priorities on long contracts, pivoting after a requirements change, cross-functional collaboration and mentoring. Many of these are phrased as 'your experience' or 'a time you', so they need real projects behind them.

Candidates report that coding is assessed but that system design and solving business problems in an enterprise setting get the main emphasis. Keep your Java or Python sharp enough to write and explain code, but spend most of your time on three things: a clear Order to Cash walk-through with the integrity controls at each handoff, two or three design templates you can adapt (high availability, disaster recovery, secure access), and a set of project stories in which you made the decisions. Reported advice also says your resume should name the specific Oracle modules you have worked with, so check that every module listed is one you can discuss in depth.

The AHU Technology interview process

Candidates report three rounds across roughly 3-5 weeks, and the detail available for each stage is brief. The preparation below is organised by round; candidates report what a stage covers only for the Deep-Dive Sessions, so the advice for the other two stages is general preparation.

Technical Screening

Candidates describe the Technical Screening as the opening check on basic knowledge across the role's technical areas. No format details are reported, so prepare across the stack the listed requirements name: Oracle Cloud ERP with its Order to Cash modules, software development in a language such as Java or Python, and cloud infrastructure. Because candidates report that specific Oracle modules on the resume are a primary filter, be ready to explain any module you list as if you were describing a project.

What to demonstrate

Grounding in the basics of the role's technical areas
No further criteria are reported for this stage; the role's listed requirements (Oracle Cloud ERP, software development, cloud infrastructure) show which areas count as relevant

How to prepare

Review the Oracle O2C modules you list (Order Management, Receivables with AutoInvoice, receipts and Lockbox, Cash Management, Credit Management) and the integration tools (FBDI, REST services, Oracle Integration Cloud, BICC and BI Publisher extracts); be able to explain each one you name
Draw the Order to Cash flow from order entry to cash receipt and mark each point where data moves between modules or external systems
In Java or Python, write a small idempotent REST client that posts an order to an ERP-style API with timeouts, retries with backoff and an idempotency key, then parse and validate a CSV for an FBDI-style bulk load
Rehearse a plain-language account of the integration you know best: what moved, in which direction, through what, and how failures were handled

Deep-Dive Sessions

Candidates report that this stage mixes design discussion, practical problem solving and questions about how you work with others. Across the loop as a whole, the evaluation areas candidates describe include cloud-native patterns (microservices, containers, serverless), performance optimization, multi-region deployment and disaster recovery, plus ERP topics such as data flow mapping, customization versus configuration, security compliance and API-led connectivity, so these are sensible material to have ready for the design part.

What to demonstrate

System design reasoning for secure, scalable cloud systems
Hands-on problem solving
Behavioral alignment shown through specific project stories

How to prepare

Build a reusable design outline: requirements, assumptions, data flow, failure modes, recovery targets, security and access, then trade-offs
Write a debugging sequence for a slow distributed request: confirm the symptom, find the slow hop with traces and metrics, isolate, fix, verify
Prepare a high-availability design and a disaster recovery design for the same system, and be able to say what each one costs

Final Assessment

Candidates describe the Final Assessment as the last decision point, where overall suitability and readiness for the job are judged. No format is reported for it. As general preparation, revisit your weakest answers from earlier stages and have examples ready of working with Business Analysts and Project Managers, since the role is described as working closely with both. Candidates also mention that government-contract roles can involve added vetting that slows things down, so gather any paperwork such checks tend to need early.

What to demonstrate

Overall fit for the role
Readiness to take on the role's work

How to prepare

Review your weakest topic from the earlier rounds and rebuild the answer from scratch
Prepare questions for the team about technical debt and upcoming architectural challenges, as candidates are advised to ask
Line up examples of working with Business Analysts and Project Managers, plus stories that show client communication and a changed plan
If the role involves government work, collect the documents a background check typically needs so the timeline does not stall

Where candidates lose points

Listing Order to Cash controls in the abstract without saying where a record can be duplicated, lost or altered

Walk the cycle stage by stage, name the handoff risks (order holds, AutoInvoice rejects, unapplied receipts, Receivables-to-GL differences), and tie each control to one incident you handled. Practise the answer with an idempotency key, a reconciliation query and a reversing correction as concrete examples.

Answering a high-availability or recovery question by naming microservices, multi-region and failover with no requirements behind them

State assumptions first: who uses the system, what downtime and data loss are tolerable, and what the budget allows. Then choose components that meet those targets and say what each one costs and where it can still fail.

Listing Oracle modules on the resume that you cannot describe through one integration end to end

Keep only modules you can discuss in depth. For each, prepare the data flow, the integration mechanism (REST, FBDI, OIC, BICC or BI Publisher), the custom parts and the failure handling, since candidates report that module experience is used for filtering.

Treating the government-contracted environment question as a generic cloud question

Write your own trade-off list in advance, covering compliance and audit evidence against delivery speed, restricted access against convenience, and added verification steps against timeline. Be ready to connect each item to a system you built.

Telling behavioral stories in the plural, with no personal decision and no result

For each of the five reported behavioral prompts, write a story where you made a specific call, say what it cost, and state what happened. Use the same spoken structure for each: brief situation, your action, the result, the lesson.

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?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

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

Approach

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

Follow-up

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

What are the primary trade-offs when designing for a government-contracted cloud environment?

Medium · Technical and Domain Expertise

Approach

Name the constraint set first. In the US that usually means FedRAMP authorization at a Low, Moderate or High baseline (controls drawn from NIST SP 800-53), plus any agency-specific or ITAR data rules. Every trade-off follows from which baseline applies.
Region and service trade-off: government regions (AWS GovCloud, Azure Government, Oracle's government cloud) give you residency and screened-personnel guarantees, but they offer fewer services and get new features later. Check that every managed service you plan to use is authorized at the required level before you commit to it.
Security against delivery speed: FIPS 140 validated encryption, continuous monitoring, audit logging and documented change control all add work to each release. Keep changes small and group them into approved change windows, use pre-approved standard changes for routine work, and back it with a pipeline that produces the evidence (scans, approvals, logs) the authorization process accepts. Large batched releases raise change risk and make each review heavier.
Cost against isolation: dedicated tenancy, separate accounts per environment and longer log retention cost more. Say which isolation the contract requires and which you would add by choice.
Edge cases: support staff who must meet citizenship or clearance rules, third-party SaaS that has no authorization, and data that must never leave the boundary, including backups and telemetry.

Follow-up

A library or SaaS tool your team depends on is not authorized at the required level. What do you do?
How would you keep deployments frequent when every change needs documented approval?
Where do logs and backups live so they stay inside the compliance boundary?

How do you approach debugging a performance bottleneck in a distributed cloud architecture?

Medium · Technical and Domain Expertise

Approach

Pin the symptom down before touching anything: which operation, which percentile (p50 against p99 tells different stories), since when, and whether it lines up with a deploy, a traffic change or a batch job.
Follow one slow request end to end with distributed tracing (for example OpenTelemetry spans) and find the span that dominates the critical path. Then check resources with USE (utilization, saturation, errors) and services with RED (rate, errors, duration).
Check the usual distributed culprits: N+1 or chatty synchronous calls, connection-pool or thread-pool exhaustion, lock contention or missing indexes in the database, GC pauses, and retries that multiply load on a dependency that is already slow.
Use the arithmetic. By Little's law, concurrency equals throughput times latency, so a slower dependency fills pools. With fan-out to N backends that are each slow with probability p, the request is slow with probability 1-(1-p)^N, which is why tail latency grows with fan-out.
Change one thing at a time, then verify with the same metric under comparable load. Add an alert or dashboard so the regression is caught next time.

Follow-up

The traces show every service is fast, yet users still see slow pages. Where do you look next?
How do you reproduce a p99 problem that happens only under production load?
How would you stop retries from turning one slow dependency into an outage?

Explain the role of middleware in your most recent cloud implementation project.

Medium · Technical and Domain Expertise

Approach

Set out the topology in one sentence: which systems the middleware connected, for example an order-capture app, the ERP and a billing or payment service, and why point-to-point links were rejected. Among N systems, point-to-point can need up to N(N-1)/2 links, while a hub needs N.
List the jobs it did: protocol and format mediation (REST, SOAP, files), data mapping and validation, routing and orchestration across steps, and central authentication with OAuth tokens or certificates.
Explain the reliability design: queues to absorb spikes and outages, retries with exponential backoff, idempotency keys so a redelivered order is not booked twice, and a dead-letter queue with a reprocessing path.
Separate bulk paths from real-time ones. For Oracle Cloud ERP that can mean REST or SOAP services for single transactions and file-based data import (FBDI) for bulk loads, often orchestrated through Oracle Integration Cloud. Name the path you used and why.
Close with the cost: an extra hop adds latency, another component to run and monitor, and a shared failure point. Say how you monitored it (message lag, error rate, end-to-end correlation ids).

Follow-up

A message failed halfway through a multi-step flow. How did you find it and replay it safely?
When would you skip the middleware and call the ERP API directly?
How did you version a mapping when the source schema changed?

How would you design a high-availability system for a large-scale enterprise client?

Medium · System Design and Architecture

Approach

Start with the target, because it sets the design: 99.9% availability allows about 8.8 hours of downtime a year, 99.99% about 53 minutes. Also ask for RPO and RTO and which user flows must stay up.
Remove single points of failure: stateless app instances in several availability zones behind a load balancer with health checks, plus autoscaling. Keep session state in a replicated store, not on the instances.
Data tier: a primary with a synchronous standby in another zone for automatic failover with no committed-data loss within the region, and asynchronous cross-region replicas or backups for disaster recovery. Name the trade-off: synchronous replication adds write latency.
Do the availability arithmetic. Components in series multiply (two 99.9% dependencies give about 99.8%), while n redundant copies in parallel give 1-(1-a)^n, but only if their failures are independent. Copies that share a zone, a dependency or a deploy fail together, so real availability is lower than the formula suggests. Protect the request path with timeouts, circuit breakers and jittered retries, and degrade gracefully (for example by queueing writes).
Cover change, the most common cause of outages: rolling or blue/green deploys, expand-then-contract schema migrations, feature flags, and alerting on symptoms users see.

Follow-up

A whole region goes down. What still works, and what is the RPO for orders written in the last minute?
How do you run a schema migration on the main table without downtime?
Which dependency would you remove from the critical path first, and why?

What factors influence your decision to choose a specific cloud service over another?

Medium · System Design and Architecture

Approach

Start from the requirement, not the vendor: latency, throughput, consistency, data size, and the compliance or residency rules that rule options out (certifications, region availability).
Compare the operating model: a managed service gives up control and tuning in exchange for less patching and on-call work. Set that against the team's skills and the size of the operations team.
Compare cost shapes, not list prices. Per-request or serverless pricing suits spiky, low-volume load. Provisioned capacity is usually cheaper under steady high use. Include data egress and support tiers.
Check hard limits and semantics that decide the matter. For example, AWS Lambda caps a run at 15 minutes. SQS standard queues are at-least-once with best-effort ordering, while Kafka keeps order per partition and lets consumers replay retained data.
Weigh lock-in honestly: proprietary APIs against open standards (Postgres, containers, OpenTelemetry). Then make a decision you can reverse, with a named exit path.

Follow-up

Give an example where you picked the more expensive service, and say why.
How would you limit lock-in if you had to use a proprietary managed database?
A cheaper option arrives a year later. What would make the migration worth it?

How do you ensure your architecture remains secure while maintaining ease of access for stakeholders?

Medium · System Design and Architecture

Approach

Make identity the main control: single sign-on through the organisation's identity provider (SAML or OIDC), MFA, and role-based access with least privilege. Access then becomes easy because it comes with the job, not through shared accounts.
Apply segregation of duties to the business process. In order-to-cash, for example, the person who creates customers or changes credit limits should not also approve credit memos or apply cash. Review role assignments on a schedule.
Separate system-to-system access from human access: an API gateway with OAuth 2.0 client credentials and scoped tokens, secrets kept in a vault and rotated, databases on private networks with no public endpoint.
Protect and record the data: TLS in transit, encryption at rest with managed keys, masking of sensitive fields in non-production copies, and audit logs of who read or changed what.
Lower friction for stakeholders without widening access: self-service read-only reports or replicas, just-in-time elevation that expires, and a logged break-glass account for emergencies.

Follow-up

A contractor leaves mid-project. How do you make sure every access path is revoked?
A business user asks for direct database access to build reports. What do you offer instead?
How would you find a role that has gathered more privileges than it needs?

Walk us through a time you had to refactor a legacy system into a modern cloud framework.

Medium · System Design and Architecture

Approach

Tell it as a story in the first person (STAR). Give the situation in two sentences: what the legacy system did, why it had to move (cost, scaling limits, unsupported platform), and what could not break during the move.
Describe the migration pattern: a strangler fig, where a facade or proxy routes one capability at a time to the new service while the rest stays on the old system. Name what you moved first and why it was low-risk.
Explain how you protected behaviour: characterization tests that captured the old outputs before any change, then side-by-side comparison of old and new results on real traffic or replayed data.
Cover the data move: a bulk backfill followed by change data capture or dual writes, plus reconciliation counts and checksums before cutover. Shift traffic gradually behind feature flags and keep a rollback path.
Close with measured results (latency, cost, incident rate, release frequency) and one thing you would do differently, such as decommissioning the old path sooner.

Follow-up

The old and new systems disagreed on results during the parallel run. How did you decide which one was right?
How did you handle writes that arrived during the cutover window?
What did you leave on the legacy system, and why?

How do you plan for system recovery and disaster management in a cloud-native environment?

Medium · System Design and Architecture

Approach

Set targets for each system, based on business impact: RPO (how much data loss is tolerable) and RTO (how long recovery may take). A billing ledger and an internal report have different numbers, and the targets decide the cost.
Choose a strategy tier for each target: backup and restore, pilot light, warm standby, or active-active across regions. Each step down in RTO and RPO costs more and adds failover complexity.
Design backups to survive the disaster: point-in-time recovery, copies in another region and account, and immutable or versioned storage. Replication alone also copies corruption and ransomware encryption.
Make recovery repeatable: infrastructure as code to rebuild environments, runbooks with named owners, DNS or traffic-manager failover, and a plan for shared dependencies such as the identity provider, secrets and certificates.
Prove it works: scheduled restore tests and failover game days that measure the RTO and RPO you actually achieve, plus a failback plan so you can return to the primary region cleanly.

Follow-up

A bad deploy corrupted data an hour ago, and replication has already copied it. How do you recover?
How do you justify the cost of a warm standby to a client?
When did you last test a restore, and what did it reveal?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan starts with the Order to Cash flow and the three reported rounds, moves through Oracle modules and integration, then the design and debugging questions, then spends a day on behavioral stories before a full mock run.

Day 1 — Map the loop and the Order to Cash flow

Write the three reported rounds on one page in order, note that topic coverage is reported only for the Deep-Dive Sessions (system design, hands-on problem solving, behavioral alignment), and list what you will prepare for each stage.
Draw the Order to Cash flow from order entry to cash receipt, marking every handoff between modules and external systems.
Compare your resume with the listed requirements (Oracle Cloud ERP, Java or Python, cloud infrastructure, Agile) and mark each claim you could not defend in depth.

Deliverable: A one-page loop map, an annotated Order to Cash diagram, and a list of resume claims to defend or remove.

Day 2 — Oracle modules, data integrity and ERP integration

Review the O2C modules (Order Management, Receivables with AutoInvoice, receipts and Lockbox, Cash Management, Credit Management) and the integration toolset (FBDI, REST services, Oracle Integration Cloud, BICC and BI Publisher); write two sentences on each one you list on your resume.
Write a spoken answer on data integrity in an Order to Cash cycle: order holds, AutoInvoice rejects, unapplied receipts and Receivables-to-GL reconciliation, with the control for each.
Write a spoken answer on integrating a custom application with Oracle Cloud ERP, naming the mechanism (REST or FBDI through the ERP Integration Service), field mapping, error handling and what was configured versus custom.

Deliverable: A module and tool cheat sheet, two recorded answers (integrity, integration), one optimistic-locking update statement, and one idempotent batch-processing solution.

Day 3 — Cloud trade-offs and secure access

Write a trade-off list for a government-contracted cloud environment and attach an example from your own work to each item.
Build a decision table for choosing one cloud service over another: cost, operational load, portability, compliance, team skill.
Outline how you would keep an architecture secure while stakeholders still get easy access, covering roles, single sign-on and audit logging.

Deliverable: A trade-off list, a service decision table, and a one-page secure-access outline.

Day 4 — High availability, recovery and middleware

Design a high-availability system for a large enterprise client on paper, with explicit assumptions about acceptable downtime and data loss.
Extend the same design with a disaster recovery plan: backups, replication, failover steps and how you would test them.
Write a short account of the role middleware played in your latest cloud project: what it routed, transformed, retried and monitored.

Deliverable: One availability design, a matching recovery plan, and a middleware account from a real project.

Day 5 — Debugging and legacy refactoring

Write your debugging sequence for a performance bottleneck in a distributed cloud system: symptom, traces and metrics, slow hop, fix, verification.
Prepare the story of a legacy-to-cloud refactor, covering the incremental migration plan, how you kept the old system running, and what you would do differently.

Deliverable: A written debugging checklist, two solved practice items, and a refactor story with its migration plan.

Day 6 — Behavioral stories

Write one STAR story each for explaining a technical issue to a client, juggling conflicting priorities, and pivoting after a requirement change.
Write one story for cross-functional collaboration and one for mentoring or a process improvement.
Say each story aloud and cut it down until the action and result carry it.

Deliverable: Five tightened STAR stories, each with a named decision and a stated result.

Day 7 — Full mock run

Run a mock of the three reported stages in order: foundational questions, a design plus behavioral session, and a closing fit discussion.
Write the questions you will ask the team about technical debt and upcoming architectural challenges.

Deliverable: One recorded mock run, a solved rolling-failure-rate solution, and a list of questions for the team.

Stories for client-facing engineering work

The behavioral prompts candidates report centre on client-facing and long-engagement work: explaining a technical issue to a non-technical client, managing competing priorities, changing course when requirements move, collaborating across roles and mentoring. Several domain prompts are also phrased as experience stories, so treat them the same way. Prepare each as a real episode with your decision and its result, using the STAR structure candidates are advised to use.

Walk us through a time you had to refactor a legacy system into a modern cloud framework.

How do you handle data integrity challenges within an Order to Cash cycle?

Medium · Technical and Domain Expertise

Approach

Although this is filed with the behavioral prompts, answer it as a technical story. Walk the Oracle O2C cycle in order (Order Management, shipping, AutoInvoice into Receivables, receipts, Cash Management, posting to the General Ledger) and name where it actually breaks: orders stuck on holds, AutoInvoice interface lines rejected for missing customer, item, tax or accounting data, Lockbox receipts left unapplied or applied to the wrong invoice, and Receivables balances that do not tie to GL.
Name preventive controls: a unique source reference on each order so a retried call cannot create a second one, validation of customer, item, price, tax and currency before data reaches the interface tables, statuses that only move forward, and transactions and constraints wherever your own system owns the data.
Name detective controls: reconciliation between stages (ordered versus shipped versus invoiced quantities and amounts), review of AutoInvoice exceptions after each run, unapplied-receipt aging, the Receivables-to-GL reconciliation after Create Accounting, and alerts on mismatches.
Describe correction: fix errors with credit memos, adjustments or receipt reapplication rather than editing history, keep an audit trail of who or what changed a record, and resubmit rejected interface lines or dead-lettered messages only after the cause is fixed.
Anchor it in one real incident: the symptom (for example invoice totals not matching order totals), how you traced the root cause, the control you added, and how you confirmed it worked. A list of controls with no incident is the weak version of this answer.

Follow-up

How do you stop a retried integration call from creating a second order?
A customer was invoiced twice. How do you detect it, correct it and prevent a repeat?
How do you reconcile rounding and currency conversion differences between two systems?

Describe your experience integrating custom applications with Oracle Cloud ERP.

Medium · Technical and Domain Expertise

Approach

Give the landscape first: which custom application, which Oracle Cloud ERP modules, which direction data flowed, and what business process the integration served. Keep it to a few sentences so the rest of the time goes to your decisions.
Name the Oracle mechanism you used and why. Inbound single transactions can go through Fusion REST or SOAP services; bulk inbound data goes through FBDI templates, uploaded and loaded via the ERP Integration Service (the Load Interface File for Import ESS job, then the module's import job), ideally with a callback when the job finishes. Outbound data usually comes from BICC extracts or BI Publisher reports. Say whether Oracle Integration Cloud sat in the middle and what it handled.
Cover the contract: authentication, field mapping and code translation (customer, item and business-unit identifiers rarely match across systems), payload limits, pagination, and how you tracked ESS job status and pulled the import error report for rejected rows.
Cover failure handling and change: idempotent source references, retries with backoff, reconciliation counts, and monitoring. Say what you did with standard configuration and what was custom, and how you regression-tested the custom parts against Oracle's quarterly updates.
If your hands-on Oracle exposure is limited, describe the closest integration you built end to end and say plainly what you did and did not touch. Naming modules without describing one concrete integration is the mistake that sinks this answer.

Follow-up

What happens to your integration when a quarterly update changes a field or an API you depend on?
Why did you choose REST calls over an FBDI bulk load for that flow, or the reverse?
How did you test the integration without touching production data?