ACSE Solutions Software Engineer Interview Guide

The 60-second brief

Reports of the ACSE Solutions Software Engineer role centre on Oracle: Oracle Cloud environments, custom interfaces that move data between internal systems and external partners, API integrations and reporting, all delivered for clients. The role is described as sitting between functional consultants who define business needs and the technical build that implements them, covering inbound and outbound interfaces, Oracle Cloud configuration and items such as Key Flexfields and invoice creation. Candidate reports do not describe ACSE's own product lines or team structure, so this guide sticks to the work the role is said to involve.

This guide is for Software Engineer candidates whose background is Oracle development and integration: interfaces, reports, forms, flexfields, conversions and API work.

Candidates report two rounds spread over roughly 2 to 4 weeks: a Technical Assessment of domain knowledge, then a Leadership Discussion. This is what candidates describe, not a published process.

Focus areas

• OIC (Oracle Integration Cloud)
• Oracle Cloud
• Oracle Reports / Reporting

Overview

Reports describe the work as designing, maintaining and tuning enterprise systems on Oracle Cloud. Day to day that means building and supporting inbound interfaces (data arriving from another system) and outbound interfaces (data leaving Oracle for a partner), integrating through APIs, producing reports, and configuring cloud modules. Candidates report Oracle Integration Cloud (OIC), Oracle Cloud, Oracle Reports and inbound and outbound interfaces as the areas tested.

The reported questions are almost all explain-your-own-work questions: your process for building Oracle reports and the tools you use, how you handle inbound and outbound interfaces, how you set up Key and Descriptive Flexfields, the technical steps of invoice creation, your experience with Oracle Forms and the compile process, and how you would design an API integration to scale. Two more are behavioral (a significant technical challenge and troubleshooting a complex conversion error), and the example scenarios add a mid-project requirement change and a slow report or query. None of the reported questions is an algorithm puzzle, so preparation means rehearsing precise walkthroughs of work you have actually done.

Candidates report two themes in the advice they pass on. First, describe your own contribution to each interface or report with "I", not what the team delivered. Second, explain why you chose an implementation, not only how the tool works. Both mean you should arrive with a written inventory of your projects, an ordered debugging routine for a failing interface, and a reconciliation routine for conversions.

The Leadership Discussion is described as less technical but not optional: candidates are told it covers teamwork and handling professional challenges. The listed soft skills include explaining complex technical concepts to non-technical stakeholders, so prepare at least one story where you translated a technical constraint for a functional consultant or business user.

The ACSE Solutions interview process

Candidates describe two stages, a Technical Assessment and a Leadership Discussion, over roughly 2 to 4 weeks. Reports do not tie individual questions to a particular round, so rehearse both question sets.

Technical Assessment

Candidates describe the Technical Assessment as the first look at your domain knowledge. The technical areas they list are Oracle development and integration (interfaces, reporting tools, Key and Descriptive Flexfields) and technical problem solving (API design, Oracle Forms and compilation, and less commonly performance tuning for high-volume data and custom module integration). Reported example scenarios include debugging an interface that fails to push data to its destination, keeping data consistent through a conversion, and speeding up a slow report or query. The reports do not say whether the stage is spoken, written or hands-on, so prepare step-by-step spoken walkthroughs that you could also sketch on a page: input, logic, output, error handling and why you chose that route.

What to demonstrate

• Hands-on knowledge of Oracle reports, inbound and outbound interfaces, flexfields, invoice creation and Oracle Forms
• Whether you can explain why you chose an implementation path, not only how the tool works
• Troubleshooting method for failing interfaces, conversion errors and slow reports or queries
• API integration design with reliability and scalability in mind

How to prepare

• Write an inventory of every interface, report, form and conversion you have built, with direction (inbound or outbound), tool, data volume and your own part
• Rehearse an ordered debugging routine for an interface that is not delivering data: was it triggered, what was extracted, what the transformation did, what the target rejected, and how you confirmed the fix
• Prepare the invoice creation walkthrough in the module you know best, naming each step and the business reason for it
• Prepare a scalability answer for a new API integration covering pagination, retries with backoff, idempotency, rate limits, queuing and monitoring

Leadership Discussion

Candidates describe the Leadership Discussion as the closing conversation, covering leadership qualities and cultural alignment with the team. Some call it the management round and warn that it only looks less technical: the reports say it is where working within a team and handling professional challenges come up. Reports do not say which questions belong to this stage, but behavioral prompts such as a significant technical challenge, troubleshooting a complex conversion error or a requirement that changed mid-project can be told as leadership material through your own decisions. Candidates are also advised to be ready to discuss every technology on their resume, so keep your technical detail ready here too.

What to demonstrate

• Leadership qualities and fit with the team, as candidates describe the stage
• Ability to work within a team and handle professional challenges
• Ability to explain complex technical concepts to non-technical stakeholders, one of the listed soft skills
• Accountability for your own code and configuration, including what went wrong

How to prepare

• Write three STAR stories: a significant technical challenge, a complex conversion error, and a requirement that changed mid-project
• Add one story where you explained a technical constraint to a functional consultant or business user, and what they decided as a result
• Use "I" for every action in each story, and prepare one admission of a mistake and the process change that followed
• Be ready to defend every technology on your resume with at least three concrete facts about how you used it

Where candidates lose points

Answering the Oracle reports question with a list of tools and no process

For each report you built, state the requirement, data source and query, parameters, layout, scheduling and delivery, testing, and why you picked that tool. Practise it on one real report until the reason for each choice comes out unprompted.

Saying "we" about interface and report work so your own contribution is invisible

Write one line per project that starts with "I built", "I changed" or "I diagnosed". Candidates are told the conversation is about your individual part in the interface lifecycle, so keep team results as context only.

Jumping straight to a fix when asked how you debug an interface that is not pushing data

Use a fixed order: confirm the run was triggered, check what was extracted, check the transformation, check connection and authentication to the target, read the target's rejection, fix, then re-run and verify. Say what each step rules out.

Answering the API integration scalability question with "add more capacity" instead of design choices

Name pagination or batching, retry with backoff, idempotency keys so a retry cannot double-apply, rate limits, asynchronous queuing, error handling and monitoring, and security. Tie each to an integration you built or would build.

Treating the Leadership Discussion as a formality and arriving with no stories

Prepare STAR stories for a technical challenge, a conversion error and a mid-project requirement change, plus one example of explaining a technical constraint to a non-technical stakeholder. Rehearse them aloud with "I" statements and one honest mistake.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

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

Approach

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

Follow-up

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

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

Medium · top-k · heavy hitters · streaming

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

Approach

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

Follow-up

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

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

1. 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.
2. 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.
3. 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.
4. 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?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

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

Approach

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

Follow-up

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

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

What is your process for creating Oracle reports, and which tools do you utilize?

Medium · Technical Domain Expertise

Approach

1. Name the toolset for each platform. In E-Business Suite: Reports Builder (.rdf) or BI Publisher (XML Publisher) with a data template or RDF data source plus an RTF layout. In Fusion Cloud: a BI Publisher data model and layout in the /Custom catalog folder, and OTBI subject areas for ad hoc analysis.
2. Walk the build order: get the requirement and a sample output from the functional user, write and tune the SQL with bind parameters (e.g. :P_ORG_ID, date range), build the RTF or Excel layout, then register and deploy it.
3. For EBS BI Publisher, explain the registration chain. You register the concurrent program executable and the program with output format XML. You create the data definition under XML Publisher Administrator with a code that matches the program short name, attach the template, and add the program to the right request group.
4. Cover data security and parameters: set the MOAC or org context so operating-unit-striped views return rows, and convert FND_STANDARD_DATE parameters, which arrive as canonical strings, with fnd_date.canonical_to_date.
5. Close with testing and performance: compare totals against a standard report, run at production volume, check the explain plan, and avoid wrapping indexed columns in functions in the WHERE clause.

Follow-up

• When would you choose OTBI over a BI Publisher report in Fusion?
• How would you burst one report into a separate file or email per supplier or business unit?
• A report that ran in seconds now times out at month end. Where do you look first?

Can you explain how you handle inbound and outbound interfaces in your current projects?

Medium · Technical Domain Expertise

Approach

1. Split the answer by direction and platform. Inbound EBS: load the file into a custom staging table (SQL*Loader or an external table), validate in PL/SQL, insert into the open interface table (GL_INTERFACE, AP_INVOICES_INTERFACE, RA_INTERFACE_LINES_ALL), then run the standard import program or call a public API.
2. Inbound Fusion: build the FBDI CSVs from the Excel template, zip them, and upload through the ERP Integration service (importBulkData), usually orchestrated in OIC. It runs Load Interface File for Import and then the module's import job, with a callback or getESSJobStatus to track completion.
3. Outbound: extract with a BI Publisher report, an HCM Extract or a PL/SQL extract with UTL_FILE, and deliver over SFTP or REST. Track a last-run timestamp watermark so each run sends only new or changed records and a rerun does not double-send.
4. Error handling decides the design. Write validation failures back to the staging rows with a status and message, read the module's rejection tables (e.g. AP_INTERFACE_REJECTIONS), and reconcile record counts and amounts between source, interface and base tables.
5. State your own part in a real interface: the volume, the schedule, a failure you hit, and how reprocessing works without manual cleanup.

Follow-up

• How do you make an inbound load safe to rerun after it failed halfway?
• When would you call a public API row by row instead of using the open interface plus import program?
• How do you notify the source team about rejected records?

How do you configure and manage Key Flexfields and Descriptive Flexfields?

Medium · Technical Domain Expertise

Approach

1. Start with the difference. A Key Flexfield builds an identifier from segments stored in SEGMENT1..n of a combinations table, such as the Accounting Flexfield in GL_CODE_COMBINATIONS keyed by CODE_COMBINATION_ID. A Descriptive Flexfield adds extra fields to an existing table through ATTRIBUTE1..n columns, with ATTRIBUTE_CATEGORY as the context.
2. KFF setup: define the structure and segments, attach value sets (independent, dependent, table-validated), assign flexfield qualifiers such as balancing segment, cost center and natural account, and decide on dynamic inserts. In EBS, freeze and compile the structure.
3. Control rules: cross-validation rules stop invalid segment combinations from being created; security rules restrict which values a given responsibility or role can enter. Name both and say which problem each solves.
4. DFF setup: global data elements versus context-sensitive segments driven by a reference field, mapping each segment to an unused ATTRIBUTE column, and in Fusion running Deploy Flexfield so the change appears in the UI and services.
5. Edge cases: never reuse an ATTRIBUTE column that already holds data, check existing usages before adding a segment, and plan structure changes carefully because combinations already in use cannot simply be redefined.

Follow-up

• How do you find which ATTRIBUTE column holds a given DFF segment so a report can select it?
• A user cannot enter an account combination. How do you tell a cross-validation rule from a security rule?
• What breaks if you change a value set on a segment that already has transaction data?

Walk me through the technical steps involved in the Invoice creation process within Oracle.

Medium · Technical Domain Expertise

Approach

1. Ask which invoice is meant: Payables (supplier invoices) or Receivables (customer invoices). The two answers are different, and offering both shows you know the modules.
2. Payables path: entry through the invoice workbench or the Payables Open Interface (AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then Payables Open Interface Import). The invoice is stored as header, lines and distributions; you match to the PO with 2-way, 3-way (receipt) or 4-way (inspection) matching.
3. Then validation, which places or releases holds (price, quantity, tax), followed by approval workflow, Create Accounting through Subledger Accounting, transfer to GL, and payment through a payment process request.
4. Receivables path: AutoInvoice reads RA_INTERFACE_LINES_ALL (and distributions), applies the transaction source and grouping rules, creates transactions, and writes failures to RA_INTERFACE_ERRORS_ALL. In Fusion, both paths are commonly fed by FBDI or REST.
5. Edge cases: duplicate invoice numbers for the same supplier are rejected, invoices in a foreign currency need exchange rates, tax comes from the tax engine rather than hard-coded lines, and rejected rows must be corrected and resubmitted, not inserted again.

Follow-up

• An imported invoice sits on a quantity hold. How do you trace the cause and release it?
• How would you load several thousand supplier invoices a day from an external system?
• What is the difference between invoice validation and invoice approval?

How do you approach the design of a new API integration to ensure scalability?

Medium · Behavioral and Problem-Solving

Approach

1. Start with the volume and the pattern: real-time single records versus scheduled bulk. For large bulk loads into Oracle Cloud, I use file-based import (FBDI through the ERP Integration service) rather than one REST call per record, and keep REST for low-latency single-record updates.
2. Make every write idempotent: carry a source-system key or idempotency key and enforce uniqueness on the target (a unique source reference or an upsert by external key). A check-then-create on its own can race when retries run concurrently, so a duplicate create should fail safely or be ignored. Only auto-retry operations that are safe to repeat.
3. Handle limits and failures: retry 429 and 5xx with exponential backoff and jitter, cap concurrency to what the target allows, and page through reads (Fusion REST uses limit/offset and returns hasMore) instead of pulling everything in one call.
4. Decouple with asynchronous processing: accept the request, queue it, and return a tracking id. In OIC, that means separating the trigger integration from the processing, so a slow downstream system does not block the caller.
5. Plan the operations side: OAuth 2.0 client credentials instead of stored user passwords, a versioned contract, correlation ids logged end to end (OIC tracking fields), and an error queue with a replay path for failed records.

Follow-up

• The source system sends ten times the volume during month-end close. What changes in your design?
• How do you stop a timeout followed by a retry from creating a record twice?
• How would you version the integration when the source adds required fields?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.

Approach

1. Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
2. Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
3. Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
4. Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.

Follow-up

• The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
• How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?

Suggested practice checklist

The seven days start from your own project inventory, move through the reported technical topics (interfaces and OIC, reports, flexfields and invoices, Forms and conversions), then turn them into STAR stories and a full run-through.

Day 1 — Inventory your own Oracle work

• List every interface, report, form, conversion and integration on your resume with system, direction (inbound or outbound), tool, data volume and your own part in it
• Mark the three you can defend in the most depth and the one you know least; plan to cover the weak one on later days
• Write the two or three facts you would give about every technology listed on your resume

Deliverable: A one-page inventory table of your projects with your contribution and your strongest three marked

Day 2 — Interfaces, OIC and API integration design

• Write the lifecycle of one inbound and one outbound interface you built: trigger, extract, transform, load or deliver, error handling, reprocessing and monitoring
• Outline one OIC integration: scheduled versus app-driven orchestration, adapters and connections (ERP Cloud, FTP, REST), lookups, scope fault handlers, and tracking fields plus instance monitoring so failed instances can be resubmitted
• Write your ordered debugging routine for an interface that fails to push data, and a scalability outline for a new API integration (pagination, backoff, idempotency, rate limits, queuing, monitoring)

Deliverable: Two interface lifecycle write-ups, one OIC outline, one debugging routine and one API design outline, plus a worked solution to the redelivered-batch practice question

Day 3 — Oracle reports and slow queries

• Write your report-building process end to end for one real report: requirement, data source, query, parameters, layout, scheduling, delivery and testing, with the reason for each tool choice
• Prepare a before-and-after story for a slow report or query, using only numbers you measured

Deliverable: One report-process write-up, one before-and-after tuning story, and worked answers to the two practice questions

Day 4 — Flexfields and the invoice creation process

• Write how a Key Flexfield is structured (segments, value sets, how combinations are validated) versus a Descriptive Flexfield (context and global segments, attribute columns), and the deployment step after a change
• Choose the module you know best and walk through invoice creation step by step, saying what each step does for the business
• Note where flexfield values appear in the invoice flow and what breaks if they are configured wrongly

Deliverable: A flexfield comparison sheet and a step-by-step invoice creation walkthrough with the business reason for each step

Day 5 — Oracle Forms compile process and conversions

• Write the compile order for forms, menus and libraries, the runtime file each produces, and the compile errors you have fixed with their causes
• Write your conversion reconciliation routine: counts in, loaded and rejected, control totals, sample checks and a safe rerun of failures
• Choose one real conversion error and outline the diagnosis from reject message to root cause to prevention

Deliverable: A compile-process sheet, a reconciliation checklist and one conversion-error diagnosis outline

Day 6 — Behavioral stories for the Leadership Discussion

• Write three STAR stories: a significant technical challenge, a complex conversion error and a requirement that changed mid-project
• Write a fourth story about explaining a technical constraint to a functional consultant or business user
• Rehearse all four aloud, checking that every action is stated with "I" and that each has one admitted mistake and what you changed afterwards

Deliverable: Four STAR stories on one page each, rehearsed aloud once

Day 7 — Full run-through

• Answer all eight reported questions aloud in one sitting, technical ones first and behavioral ones second, and record yourself
• Replay the recording and mark every "we", every tool named without a reason, and every claim you could not back up with a project
• Write two questions to ask about how interface work and support are split on the team

Deliverable: A recorded run-through, a marked-up list of fixes and two questions to ask

Behavioral stories for the Leadership Discussion

The Leadership Discussion is described as the stage for leadership qualities, working within a team and handling professional challenges. For this role that means stories drawn from interface, report and conversion work in which you made the decisions, explained them to non-technical people and owned the outcome.

1. Tell me about a time a requirement changed in the middle of a project and what you changed in your code or configuration.
2. Describe a report or query you made faster, with what it was like before and after.
3. Describe a time you explained a technical limitation to a functional consultant or business user.

What is your experience with Oracle forms and the associated compilation process?

Medium · Technical Domain Expertise

Approach

1. Open with your real scope in one or two sentences: which module types you worked on (forms, menus, PL/SQL libraries), whether you built new forms or maintained and customised existing ones, and what the change did. Then say honestly how much was yours.
2. Explain the compile chain. Form (.fmb), menu (.mmb) and library (.pll) modules compile into runtime files (.fmx, .mmx, .plx). An object library (.olb) is a design-time container for subclassed or copied objects and produces no runtime file. Compile attached libraries first (they must be on the forms search path), then menus, then the form. State whether you used Forms Builder or the command-line compiler (frmcmp) and which parameters you passed.
3. Name the compile failures you have actually fixed: unresolved references to database packages or tables because an object was invalid, missing or not granted, a library that was not attached or not found, and stale runtime files left from an earlier compile. Say how you fixed each, for example recompiling the invalid database package before recompiling the form.
4. Cover deployment and verification: where the compiled .fmx goes, how you moved the change from development to test to production, how you tested the form after compiling, and how you kept the source under version control for rollback. If your forms work was in an Oracle application suite, mention registering the form with the application's form, function and menu setup.
5. If your Forms experience is thin, say so and describe the nearest work you did (PL/SQL packages, reports, customisations) rather than guessing at commands you have never run.

Follow-up

• A form compiles on your workstation but fails or behaves differently on the server. What do you check?
• A change to a shared library breaks several forms. How do you find which forms are affected and how do you release safely?
• How did you move your form change between environments and roll it back if it failed?

Can you describe a significant technical challenge you have faced and how you resolved it?

Medium · Behavioral and Problem-Solving

Approach

1. Choose a challenge from work you owned personally: an interface that dropped records, a report that timed out, an integration that failed under volume, a conversion that did not reconcile. Say in one or two sentences what broke and who was affected, then spend most of your time on your actions.
2. Show the diagnosis as an ordered sequence: the symptom, where you looked first and why (logs, interface error or reject tables, a failing sample record), the hypotheses you ruled out, and how you reproduced the fault on a small dataset before changing anything.
3. State the root cause precisely and the fix you chose, including the alternative you rejected and the reason. Candidates report that interviewers want the reasoning behind the technical choice, so make that reasoning explicit.
4. Describe how you proved the fix and prevented a repeat: re-run results, reconciliation of counts or totals, a validation added upstream, monitoring or alerting, and documentation. Give only numbers you actually measured, such as rows rejected before and after or report run time.
5. Include what you would do differently or what went wrong along the way. Candidates are advised to own failures, and the story that sinks is one where the team did the work and you were present.

Follow-up

• What other approaches did you consider and why did you reject them?
• How did you confirm the fix worked in production and not only in test?
• What would you do differently if the same problem came back tomorrow?

Describe a time you had to troubleshoot a complex conversion error.

Medium · Behavioral and Problem-Solving

Approach

1. Set the scene precisely: the source and target systems, the load method (interface tables, file import, an OIC integration or SQL scripts), the volume, and what the error looked like: rejected records, wrong totals, mismatched codes or values that loaded but were wrong.
2. Walk through the diagnosis. Read the reject or error messages and group them by cause (format or date mismatch, a missing reference such as supplier or account combination, mandatory field empty, duplicates, rounding or currency). Take one failing record and trace it back through each transformation to the source field.
3. Separate data problems from mapping problems and say how you decided. A data defect goes back to the source owner with evidence; a mapping defect you fix in the transformation and re-test on the full set of affected records.
4. Prove the result with reconciliation: counts in, loaded and rejected; control totals such as the sum of invoice amounts; spot checks of sample records agreed with a business owner. Rerun only the failed records and make the rerun safe so nothing loads twice.
5. Close with prevention: validation before the load, cleansing rules, mock conversion cycles before cutover, and a written list of the error types and fixes. Do not tell a story where you waited for someone else to fix the data.

Follow-up

• How did you make the rerun safe so records already loaded were not loaded twice?
• How did you show the business that the converted totals matched the source?
• What validation would you add before the next conversion cycle?