Defense Finance and Accounting Service Software Engineer Interview Guide

The 60-second brief

DFAS is described by candidates as the part of the U.S. Department of Defense that runs financial management for military personnel and their families: keeping financial records accurate, paying people on time and meeting federal regulation. Software engineers there are described as building and maintaining the systems behind that work. Candidate descriptions name COBOL applications, modernization of older systems and the integration of newer technology with them, and list SQL and database management as useful extras.

This guide is for software engineers preparing for the DFAS Software Engineer loop. It covers the four stages candidates report, every question they report (COBOL and debugging, legacy optimization, data integrity, financial system design, case scenarios, coding and behavioral prompts), and a plan that turns them into practice sessions.

Candidates report four stages over roughly three to five weeks: Initial Screening, Technical Assessments, Behavioral Interviews and Final Evaluations. Reports do not say which questions belong to which stage.

Focus areas

• COBOL
• COBOL Language Fundamentals
• Mainframe Development

Overview

Candidate descriptions of this role centre on COBOL. They list COBOL development, debugging and optimization as must-haves, the software development lifecycle as a requirement, and SQL, Agile practice, Java or C# and cloud exposure as extras. The topics candidates associate with the loop are COBOL, COBOL language fundamentals, mainframe development, legacy systems modernization and structured programming concepts. Prepare to explain the language itself, not only to say you have used it.

The reported questions fall into five groups. Technical and domain questions cover COBOL experience, debugging a COBOL program, optimizing legacy code, procedural versus object-oriented COBOL and data integrity. Design questions cover a financial transaction processing system, high availability and fault tolerance, database design and integrating new technology with legacy systems. Case questions cover a payroll failure, a new regulation hitting existing software, a production bug near a deadline and a disagreement with a product owner. Coding questions include a COBOL summary-report program, an algorithm in COBOL, data structures for financial work and the complexity of a sorting algorithm. Behavioral prompts round it out.

Almost every question touches the same worry: money must come out right and old code must stay safe to change. Build your answers around exact decimal arithmetic, reconciliation and control totals, idempotent processing, audit trails and small reversible changes, and keep those themes ready for the design, debugging and behavioral stages alike.

If your COBOL exposure is thin, say so honestly and close the gap with practice: write a small batch program that reads a transaction file and prints totals, and learn to read someone else's code. A true account of what you have done plus visible effort to learn is easier to defend than a long list of keywords.

The Defense Finance and Accounting Service interview process

Candidates describe four stages in this order. The reports give only a name and a one-line purpose for each, so the preparation below is built from the question types each stage names.

Initial Screening

Candidates describe the Initial Screening as the first check of qualifications and fit for the role. Nothing more specific is reported about its format. Treat it as the point where you show that your background matches the requirements candidates list: COBOL, the software development lifecycle, debugging and optimization, plus SQL and database work.

What to demonstrate

• How your background lines up with the requirements candidates list for the role
• Whether you can describe your COBOL and legacy-system experience concretely and honestly
• Basic fit for the Software Engineer position

How to prepare

• Write a short account of your COBOL or legacy experience: what the program did, its inputs and outputs, and your part in it. This is also the material for the COBOL experience question.
• List your years and domains against the stated requirements, and mark gaps such as no mainframe time, no SQL or no Agile work, with one sentence on how you are closing each.
• Ask what the later stages involve so you can adjust the rest of the week.

Technical Assessments

Candidates say the Technical Assessments evaluate programming skills and domain knowledge. The technical question types reported for this loop are COBOL and debugging, legacy optimization, data integrity, design of a financial transaction system, high availability, database design, legacy integration and coding (a COBOL summary-report program, an algorithm in COBOL, data structures, sorting complexity). Be ready to write COBOL by hand and to talk through design trade-offs.

What to demonstrate

• Working programming skill, including code you can write and explain
• Domain knowledge in COBOL, legacy systems and financial data handling
• Reasoning about design choices such as consistency, failure handling and integration

How to prepare

• Write the transaction summary program in COBOL without looking anything up: sequential read, a control break, totals in packed or display decimal fields and a report line layout.
• Rehearse the debugging walk-through for a failing COBOL batch job: read the abend or status code, reproduce with a small input, bisect by paragraph with DISPLAY output or a debugger, then fix and re-test against known totals.
• Prepare a two-minute design outline for the transaction processing system and the high-availability question: idempotent posting, an immutable ledger, reconciliation, replicas and recovery.
• Be able to state the complexity and stability of merge sort, quicksort and insertion sort, and to say which suits a file of transactions.

Behavioral Interviews

Candidates describe the Behavioral Interviews as covering interpersonal skills and fit within the organization. The reported prompts include a challenging project, team conflict, mentoring a junior developer, prioritizing across projects, motivation, balancing technical limits against business needs and disagreeing with a product owner. Candidate descriptions also mention explaining technical ideas to non-technical colleagues, integrity and Agile working.

What to demonstrate

• Teamwork, communication and conflict handling as shown in your stories
• Mentoring and support for other developers
• How you describe decisions where technical limits met business needs

How to prepare

• Build a bank of five stories, each with your own decision and a result: a hard project, a conflict, a mentoring case, a prioritization call and a disagreement with a product owner.
• Tag each story with the legacy or financial angle it can carry, such as a data fix, a regulation-driven change or a tight release.
• Say each story aloud in this order: situation in two sentences, your decision, the trade-off, the outcome.
• Prepare one honest, specific answer on why this kind of work motivates you.

Final Evaluations

Candidates describe Final Evaluations as the stage that determines overall suitability for the Software Engineer position. No format or question list is reported for it. Prepare as if both the technical and behavioral material from earlier stages could return, and have a single coherent account of who you are as an engineer.

What to demonstrate

• Overall suitability for the Software Engineer position
• Consistency between what you said in earlier stages and what you say now

How to prepare

• Write a one-page summary of your strongest stories, your COBOL or legacy depth and the topics you are weakest on, and use it to review the night before.
• Repeat the design questions you found hardest, especially high availability and fault tolerance and database design for financial applications.
• Prepare questions of your own about the team's systems and the modernization work candidates mention, so the conversation has substance on both sides.

Where candidates lose points

Listing COBOL keywords without being able to write or trace a program

Write a transaction summary program by hand, with a read loop, a control break and decimal totals. Be ready to explain every division and data item, and say plainly what you have not done.

Treating money as ordinary numbers in design and coding answers

State up front that you use exact decimal types or integer minor units, define rounding, and reconcile totals and record counts. Do the same in the transaction system and database answers.

Answering the payroll failure, production bug and regulation questions with a list of fixes instead of a sequence

Open with scope and impact, find what changed, reproduce with a small input, contain before you cure, verify against known totals, then say how you will prevent a repeat.

Giving the legacy optimization or integration answer as a rewrite pitch

Measure first, change the smallest thing that removes the bottleneck, and wrap or phase the old component. Explain how you prove behavior is unchanged, such as comparing outputs on the same input.

Telling behavioral stories in which the team did everything or the obstacle was never concrete

Prepare five stories with your own decision, the trade-off and a result. Cover conflict, mentoring, prioritizing and a product-owner disagreement, and say what you would change.

Questions & practice

Write a COBOL program that processes a list of transactions and outputs a summary report.

Medium · Coding / Algorithms

Approach

1. Outline the program structure aloud: ENVIRONMENT DIVISION FILE-CONTROL with SELECT ... ASSIGN and FILE STATUS for the input and the report file; DATA DIVISION with an FD for each, a transaction record layout, and WORKING-STORAGE accumulators such as PIC S9(13)V99 COMP-3 for amounts.
2. Use the standard read loop: OPEN, a priming READ with AT END setting an end-of-file flag, PERFORM a processing paragraph UNTIL the flag is set (that paragraph reads the next record at its end), then write grand totals and CLOSE.
3. For per-account or per-type subtotals, use control-break logic, which needs input sorted on the break key. If it is not sorted, sort it first with the SORT verb (USING/GIVING, or an INPUT PROCEDURE to filter). The pass is O(n) after an O(n log n) sort.
4. Validate each record: IF amount IS NUMERIC before arithmetic, ON SIZE ERROR on ADD, a count of rejected records written to an exceptions section, and correct handling of an empty file (a report with zero totals, not an abend).
5. Format the report with edited pictures (for example PIC Z,ZZZ,ZZ9.99- for a signed amount), header and page-break lines, and finish with control totals: records read = records processed + records rejected.

Follow-up

• The input is not sorted and is too large to hold in a table. How do you produce per-account totals?
• How would you make the report reconcile with the source system's totals?
• What changes if a transaction can be a reversal with a negative amount?

Given a specific algorithmic problem, how would you implement it in COBOL?

Medium · Coding / Algorithms

Approach

1. Solve the problem first in plain terms (algorithm and complexity), then translate, saying which COBOL constraints shape the code: tables are fixed-size OCCURS arrays (OCCURS DEPENDING ON for a variable count), subscripts start at 1, and there is no built-in dynamic list or hash map.
2. Choose table access deliberately: an index declared with INDEXED BY plus SET/SEARCH for a linear scan, or SEARCH ALL for binary search when the table is sorted on a declared ASCENDING or DESCENDING KEY.
3. Avoid recursion unless the program is declared RECURSIVE, and write depth-first or divide-and-conquer logic iteratively with an explicit stack held in a table and a top-of-stack counter.
4. Write a hash map, when one is needed, as a table with open addressing: compute the slot with FUNCTION MOD of a numeric key and probe linearly on collisions, sizing the table above the expected count to keep probes short.
5. State the edge cases out loud: table overflow (check the count against the OCCURS limit before inserting), empty input, and numeric field sizes that could overflow on accumulation.

Follow-up

• How would you find duplicate account numbers in a file too large for a working-storage table?
• Why does SEARCH ALL return wrong results if the table is not actually sorted?
• How would you implement a queue in a fixed-size COBOL table?

What data structures do you find most useful in financial applications, and why?

Medium · Coding / Algorithms

Approach

1. Tie each structure to an access pattern: fixed-length records and arrays (COBOL tables) for sequential batch processing, which is O(n) and cache- and I/O-friendly.
2. Sorted tables with binary search (SEARCH ALL, O(log n)) for read-mostly reference data such as rate, code or pay-grade lookups, and hash maps (O(1) average) keyed by account or transaction ID for aggregation and duplicate detection.
3. Keyed indexes, such as a B-tree database index or a VSAM key-sequenced data set, for files and tables that need both direct lookup by key and ordered range scans, such as all transactions for an account in a date range.
4. FIFO queues for transaction intake so postings are processed in arrival order, a priority queue (binary heap, O(log n) insert and remove) for scheduling payments by due date, and an append-only log for the ledger so history is never overwritten.
5. Name the value type as well: amounts held as fixed-point decimal (packed decimal or BigDecimal), because the choice of numeric representation matters as much as the container.

Follow-up

• Why would you choose a sorted table over a hash map for rate lookups?
• How would you detect duplicate transactions across a day's files with limited memory?
• What structure would you use to compute a running balance per account over time?

Can you explain the complexity of a sorting algorithm you have implemented?

Medium · Coding / Algorithms

Approach

1. Pick one sort you have actually implemented and state its complexity precisely. Merge sort: O(n log n) in every case, stable, O(n) extra memory. Quicksort: O(n log n) on average, O(n^2) worst case (for example a naive first-element pivot on already sorted input), in place with O(log n) average stack, not stable.
2. Contrast the alternatives by their deciding properties: heapsort is O(n log n) worst case and in place but not stable; insertion sort is O(n^2) but O(n) on nearly sorted input and stable, which is why hybrid sorts use it for small runs.
3. Explain why stability matters in financial data: sorting by account after sorting by date keeps each account's transactions in date order only if the second sort is stable.
4. Mention the limits: comparison sorts cannot beat Omega(n log n) in the worst case, while counting or radix sort reach O(n + k) on bounded integer keys.
5. For data larger than memory, describe external merge sort (sort runs that fit in memory, then k-way merge them), which is how mainframe sort utilities and the COBOL SORT verb handle large files.

Follow-up

• How would you make quicksort's worst case unlikely on real data?
• How would you sort a file larger than available memory, and what dominates its cost?
• Which sort would you pick for a table that is already almost in order, and why?

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

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

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

How do you approach optimizing legacy code for better performance?

Medium · Technical / Domain Questions

Approach

1. Measure before touching code: find where the CPU and elapsed time go (job accounting data, a profiler such as Strobe or Application Performance Analyzer, or SQL EXPLAIN output) and pick the top hotspot, not the ugliest paragraph.
2. Name the usual COBOL wins and why they work: arithmetic on COMP-3 or binary fields instead of DISPLAY numerics (no conversion on each operation), binary subscripts or indexes for table access, SEARCH ALL (binary search, O(log n), needs a table sorted on its ASCENDING/DESCENDING KEY) instead of a sequential SEARCH (O(n)).
3. Look at I/O before CPU: larger block sizes, opening a file once instead of per record, and replacing row-at-a-time SQL cursor fetches or repeated singleton SELECTs inside a loop with set-based SQL or multi-row fetch.
4. Protect behaviour: freeze a baseline input set, capture the current output, and require byte-identical output and matching control totals after each change, so a speedup never changes a payment amount.
5. Change one thing at a time and record before-and-after numbers, so each gain is attributable and any regression can be rolled back alone.

Follow-up

• The program is fast in test but slow in production. What would you compare between the two runs?
• When would you leave slow legacy code alone rather than optimise it?
• How do you prove a refactored program gives the same results on edge cases such as negative amounts and rounding?

Describe the differences between procedural and object-oriented programming in COBOL.

Medium · Technical / Domain Questions

Approach

1. Define procedural COBOL: a program is divisions, sections and paragraphs, control flow is PERFORM and CALL, data lives in WORKING-STORAGE visible to the whole program, and shared layouts come from COPY members passed through the LINKAGE SECTION.
2. Define OO COBOL, added in the COBOL 2002 standard: CLASS-ID with FACTORY and OBJECT paragraphs, METHOD-ID for methods, INHERITS for inheritance, object references declared with USAGE OBJECT REFERENCE, and calls made with INVOKE.
3. Contrast the practical differences: OO bundles data with the methods that use it (each object instance has its own data) and supports inheritance and polymorphism, while procedural code shares state across paragraphs, which is simpler to trace but easier to corrupt from distant code.
4. Be accurate about practice: most production COBOL is procedural, and IBM Enterprise COBOL's OO support is used mainly for interoperating with Java, so modularity in legacy systems usually comes from called subprograms and copybooks.
5. Close with when each fits: procedural for batch record processing, OO or a called-module design when a component needs a clear interface to newer code.

Follow-up

• How would you get some of OO's encapsulation benefits in a purely procedural COBOL program?
• What does INVOKE do that CALL does not?
• How would a COBOL program call into Java, or be called from it?

What strategies do you use to ensure data integrity in financial applications?

Medium · Technical / Domain Questions

Approach

1. Represent money exactly: fixed-point decimal (COMP-3 packed decimal in COBOL, DECIMAL/NUMERIC in SQL, BigDecimal in Java), never binary floating point, with the ROUNDED clause and ON SIZE ERROR so an overflow is caught instead of silently truncated.
2. Use database guarantees: wrap a debit and its matching credit in one ACID transaction, and add NOT NULL, CHECK, foreign key and unique constraints so invalid states cannot be written even by a buggy program.
3. In batch flows, carry control totals (record count, total amount, a hash total of a key field) from each step to the next and fail the step if they do not match; add checkpoint/restart so a rerun neither skips nor duplicates records.
4. Make writes idempotent with a unique transaction identifier so a retry cannot post twice, and keep an append-only audit trail where corrections are reversing entries, not updates in place.
5. Reconcile independently: a scheduled job compares ledger balances with the source system and the disbursement file and reports every break.

Follow-up

• A rerun after a failure posted some transactions twice. How would you find them and prevent it next time?
• Why is binary floating point unsafe for currency? Give a concrete example.
• Where would you validate input: at the edge, in the program, in the database, or all three?

How would you design a financial transaction processing system?

Medium · System Design / Architecture

Approach

1. Pin the requirements first: online versus batch, volume and peak (payday or month end), the latency target, the consistency requirement (no lost or duplicated money), and the audit and retention rules.
2. Outline the components: an intake API or file intake that validates and assigns an idempotency key, a transaction state machine (received, validated, posted, settled, reversed), a double-entry ledger where every posting's debits equal its credits, and a settlement/export step that produces payment files.
3. Concurrency on balances: update an account inside a transaction with a row lock or an optimistic version column, so two concurrent debits cannot both read the same balance; never keep the authoritative balance in a cache.
4. For events downstream, use a transactional outbox (write the event row in the same transaction as the ledger entry, then publish) so the ledger and the events cannot disagree.
5. Cover failure and audit: retries are safe because of the idempotency key, errors are reversed with compensating entries, and a daily reconciliation compares ledger totals with bank or treasury files.

Follow-up

• The service crashes after debiting one account but before crediting the other. What state is the system in?
• How would you partition the ledger if one table could no longer keep up?
• How would you add batch payroll runs to a design built for online transactions?

What considerations are important when designing systems with high availability and fault tolerance?

Medium · System Design / Architecture

Approach

1. Turn availability into targets: the uptime goal (99.9% allows about 8.76 hours of downtime a year), RTO (how quickly service comes back) and RPO (how much data loss is tolerable), because these decide everything else.
2. Remove single points of failure: redundant instances behind a load balancer with health checks, database replication with automated failover, and a second site when one site is a risk. Note that synchronous replication gives an RPO of zero at the cost of write latency, while asynchronous replication is faster but can lose recent writes.
3. Contain failures: timeouts on every remote call, retries with exponential backoff and jitter only for idempotent operations, circuit breakers, and bulkheads so one slow dependency cannot use up every thread.
4. Do the series and parallel arithmetic: components in series multiply their availabilities (two at 99.9% give about 99.8%), while two independent redundant copies give 1 - (1 - a)^2.
5. Prove it works: monitor and alert on user-facing symptoms, rehearse failover and restore from backup regularly, and plan graceful degradation (for example accept and queue payments when the downstream system is down).

Follow-up

• What is split-brain, and how do you prevent two primaries from accepting writes?
• Your nightly batch window overlaps with an online system's peak. How does that affect your availability design?
• When is active-passive a better choice than active-active?

How do you approach integrating new technologies with existing legacy systems?

Medium · System Design / Architecture

Approach

1. Start with an inventory: which programs, files, copybooks and tables the new capability touches, which interfaces exist today (batch files, database tables, transaction screens), and who consumes each output.
2. Choose an incremental pattern rather than a big-bang rewrite: the strangler fig approach (route one function at a time to the new component behind a stable interface) plus an anti-corruption layer that translates between the legacy data model and the new one.
3. Handle the data translation explicitly: EBCDIC to ASCII, packed decimal (COMP-3) and zoned fields to decimal types, implied decimal points in PIC clauses, fixed-width records, and date formats. Most integration defects appear here.
4. Keep the systems consistent during the transition with a single system of record per entity, using change data capture or controlled batch extracts to sync the other side, and make interface messages idempotent.
5. De-risk the cutover: run old and new in parallel on the same inputs, compare outputs record by record, and cut over behind a switch that can be flipped back.

Follow-up

• The legacy system only exchanges nightly flat files, but the new service needs near-real-time data. What are your options?
• How would you test the integration when the legacy side has no automated tests?
• Who owns a record while both systems can update it?

Imagine a scenario where a new regulation impacts existing financial software. How would you approach this cha

Medium · Problem-Solving / Case Studies

Imagine a scenario where a new regulation impacts existing financial software. How would you approach this challenge?

Approach

1. Turn the regulation into testable rules: what changes, from which effective date, for which population, and whether it is retroactive. Confirm the reading with the policy or legal owner before coding.
2. Do impact analysis in the code: search copybooks and programs for the affected fields and calculations (cross-reference listings, field usage searches), and list every program, report, interface and stored table that reads or writes them.
3. Implement the change as effective-dated rules rather than hard-coded constants: a rate or rule table keyed by effective date, so transactions are calculated under the rule that was in force on their date and historical recalculations stay correct.
4. Build regression tests from real cases on both sides of the effective date, including boundary dates and retroactive adjustments, and run old and new logic in parallel to explain every difference.
5. Plan the rollout around the compliance date with an audit trail of what changed, who approved it and which records were recalculated.

Follow-up

• The regulation applies retroactively to the start of the fiscal year. How do you recalculate past transactions?
• How do you show an auditor which rule version produced a given payment?
• The compliance date is earlier than a full rewrite allows. What is the minimum safe change?

You have discovered a major bug in production just before a deadline. What steps would you take to resolve it?

Medium · Problem-Solving / Case Studies

Approach

1. Size it first: who is affected, whether data is being corrupted or money mispaid, and whether the damage is growing. That decides whether this is an immediate incident or a fix that can go into the next release.
2. Contain before fixing: roll back the change, disable the feature with a switch, or hold the affected batch output, so the damage stops while the cause is investigated.
3. Lay out options for the deadline owner, each with its risk: a minimal hotfix with focused tests, a workaround plus a full fix later, or moving the deadline. Escalate early rather than presenting a surprise at the last minute.
4. Keep the hotfix narrow: reproduce the bug, add a failing test, change the smallest amount of code, have it reviewed, and run the regression suite that covers that path.
5. Afterwards, repair any bad data with traceable correcting entries, write up the root cause, and add the test or check that would have caught it earlier.

Follow-up

• Rolling back would also remove a fix that another team needs for the same deadline. What now?
• How do you decide that a bug is serious enough to miss the deadline?
• What would you tell a non-technical stakeholder in the first message?

Can you explain the process of debugging a COBOL program?

Medium · Technical / Domain Questions

Approach

1. Start from the symptom type, because COBOL failures fall into a few classes: an abend (on z/OS, S0C7 is a data exception, usually non-numeric data in a packed or zoned field; S0C4 is an addressing error, often a subscript out of range or a bad LINKAGE SECTION parameter), a non-zero FILE STATUS, or a clean run with wrong output.
2. For an abend, map the failing offset from the dump (the Language Environment CEEDUMP) to a statement using a compile listing built with the LIST/OFFSET and MAP options, then inspect the fields on that statement in the dump.
3. Check FILE STATUS after every OPEN, READ and WRITE: 35 means the file was not found at OPEN, 39 an attribute mismatch with the program's FD, 23 a key not found, 22 a duplicate key, 10 end of file. An unchecked status is a common reason a job runs on with bad data.
4. For wrong output, reproduce with a copy of the failing input in a test region, then narrow with targeted DISPLAY statements or an interactive debugger (IBM z/OS Debugger, Xpediter) stepping through the paragraph that produces the bad field.
5. Finish with the fix plus a regression case built from the record that broke it, and compare the rerun's control totals against the expected ones.

Follow-up

• The job ended with S0C7 on a record that looks numeric in the file viewer. What would you check next?
• How would you debug a subscript that goes out of range only on month-end volumes?
• How would you guard the program so one bad input record cannot stop the whole batch run?

How would you troubleshoot a critical system failure affecting payroll processing?

Medium · Problem-Solving / Case Studies

Approach

1. Assess impact and contain it first: which pay cycle, how many records, and whether wrong amounts could reach a disbursement file. Hold or stop the downstream transmission before diagnosing, because a wrong payment that goes out is much harder to recover.
2. Read the evidence: job logs and return codes, the abend code and failing step, FILE STATUS or SQLCODE values, and the last checkpoint reached, to separate a crash from a run that finished with bad results.
3. Establish what changed since the last good run: code or compiler changes, the input file (record count, layout, unexpected values), reference tables such as tax or deduction rates, and date logic (year end, leap year, a new pay period).
4. Reproduce with a copy of the failing input in a non-production region, fix, then restart from the last valid checkpoint or rerun the cycle. Confirm the result with control totals and a sample of individual pay records before releasing the hold.
5. Communicate status and expected time to the affected stakeholders throughout, and afterwards write the root cause plus the check that would have caught it earlier (input validation, a control-total mismatch alarm).

Follow-up

• Half of the records were processed before the abend. How do you restart without paying anyone twice?
• The job finished with return code 0 but totals are off by a small amount. Where would you look?
• What monitoring would catch this failure before payday instead of after it?

Suggested practice checklist

The plan follows the reported loop: COBOL fundamentals first, then debugging and legacy optimization, financial design, coding and complexity, behavioral stories, and a full mock pass. Each day names the reported questions it practises.

Day 1 — Map the loop and audit your COBOL

• Write the four reported stages, Initial Screening, Technical Assessments, Behavioral Interviews and Final Evaluations, and beside each the question types from this guide you would expect to practise for it.
• Score yourself 1 to 5 on COBOL data definition, file handling, paragraph structure, debugging, SQL and database design, and sorting complexity.
• Write your two-minute account of your COBOL or legacy experience.

Deliverable: A one-page loop map, a scored skills audit with the three weakest areas marked, and a written two-minute experience account.

Day 2 — COBOL fundamentals and the summary-report program

• Review the four divisions, PIC clauses, packed and display numerics, copybooks, PERFORM and the structured-programming rules of sequence, selection and iteration.
• Write a program that reads a transaction file, accumulates totals by account with a control break, and prints a summary report with a grand total.
• Write the answer on how procedural and object-oriented styles differ in COBOL, including what the standard's object features add and why structured paragraphs remain common.

Deliverable: A working summary-report program with test input and expected output, plus a half-page note on procedural versus object-oriented COBOL.

Day 3 — Debugging and legacy performance

• Write a step-by-step debugging routine for a COBOL batch failure: read the abend or file status code, reproduce with a small input, bisect by paragraph, check data definitions and fix.
• Choose a slow legacy job and write an optimization plan: measure first, find the hot loop or file access pattern, change one thing, compare output and timing.
• Outline a response to the payroll processing failure and the production bug before a deadline: scope, containment, cause, fix, verification.

Deliverable: A debugging checklist, a measured-optimization plan for one example job and two spoken-aloud incident outlines.

Day 4 — Financial data integrity and system design

• Outline the financial transaction processing system: idempotent posting, an append-only ledger, reconciliation jobs, audit trail and failure handling.
• Add high-availability design: redundancy, failover, recovery of in-flight work and the consistency you keep.
• Write the plan for a new regulation that changes existing software: find affected rules and data, make a minimal change behind a switch, test against old and new cases, and roll out.
• Do the practice question on detecting a concurrent edit in an update path to rehearse optimistic checks.

Deliverable: Two design outlines (transaction system with availability, regulation change), a data-integrity checklist and the completed concurrent-edit practice answer.

Day 5 — Legacy integration, data structures and complexity

• Outline an integration of a newer service with a legacy system: adapter or wrapper, a stable interface, retries without duplicates and a phased cutover.
• List the data structures for financial work (hash maps for lookups by account, sorted arrays or trees for ranges, queues for pending work) and the access pattern behind each.
• Write the complexity, stability and memory profile of insertion sort, merge sort and quicksort, and say which suits a file of transactions already in nearly sorted order.
• Prepare the database design and optimization story.

Deliverable: An integration outline, a data-structure table keyed by access pattern, a sorting comparison sheet and a written database story.

Day 6 — Behavioral story bank

• Write stories for the challenging project, the conflict, the mentoring case and the prioritization question, each with situation, decision, trade-off and result.
• Write the technical-limit versus business-requirement story and the product-owner disagreement story, including what you conceded.
• Write your motivation answer with one example, then record all answers aloud and cut anything vague.

Deliverable: Six story outlines and one motivation answer, each with a stated decision and result, recorded aloud once.

Day 7 — Full mock loop and weak-spot repair

• Run a mock in loop order: a short background pitch, a COBOL coding exercise written by hand, a debugging scenario, a design question and three behavioral prompts.
• Review where you stalled and rewrite those answers.
• Prepare questions for the team about their systems and modernization work, and your one-page summary for the final stage.

Deliverable: A scored mock with a list of fixes, rewritten weak answers and a one-page final-stage summary.

Behavioral stories for a legacy financial systems role

Candidates describe the behavioral interviews as covering interpersonal skills and fit. For this role the reported prompts are about mentoring, conflict, prioritization, disagreement with a product owner and decisions where technical limits met business needs. Each story should show your own decision, the trade-off and a result, ideally in legacy or financial settings.

What is your experience with COBOL and how have you applied it in projects?

Medium · Technical / Domain Questions

Approach

1. Pick one or two real projects and describe the program's job before your own: batch or online, what it read, what it wrote, how much data, and the part you owned (a report program, a file-matching job, a copybook change, a defect fix).
2. Prove fluency with specifics instead of keywords: PIC clauses for money fields, packed-decimal storage, copybooks shared across programs, paragraph structure with PERFORM, file status checks and how you tested a change (known input, before-and-after output comparison).
3. Tie it to financial correctness: how you handled rounding, signs and overflow, and which record counts or control totals you reconciled after a run.
4. If your COBOL time is short or none, say so in the first sentence, offer the nearest equivalent (batch processing or legacy maintenance in another language) and name something concrete you did to learn, such as writing a program in GnuCOBOL. Claiming mainframe experience you cannot defend sinks the answer.

Follow-up

• What was the hardest defect you fixed in that code, and how did you find it?
• How did you test a change when there was no automated test suite?
• What would you modernize first in that system, and why not rewrite it all?

Describe your experience with database design and optimization for financial applications.

Medium · System Design / Architecture

Approach

1. Open with the system and the shape of its data: the main tables (accounts, transactions, balances), rough row counts, the read-to-write mix and your role. Keep this to a few sentences.
2. Describe design decisions you can defend: exact numeric types for money (DECIMAL or integer minor units, never floating point), primary and foreign keys, check constraints, append-only ledger rows with reversing entries instead of in-place edits, and a unique key that makes retries safe.
3. Present optimization as measurement. Name the slow query, how you read its execution plan, the change (a composite index matching the filter and sort order, a rewritten join, batching, archiving old rows) and the before-and-after numbers from your own work.
4. Name the trade-off you accepted, such as write cost of an extra index, or a stored running total that needs reconciliation against the ledger, and how you protected correctness (isolation level, locking, or an optimistic version column).

Follow-up

• How would you stop two concurrent updates from corrupting a balance?
• How did you confirm the new index did not slow the write path?
• What do you do with a query that is fast on test data but slow at production volume?

Discuss a time when you had to balance technical limitations with business requirements in a software design.

Medium · System Design / Architecture

Approach

1. Choose a case where the limit was real: a legacy platform, a fixed file layout, a batch window, a regulation or a schema you could not change. A story where you were only short on time is weaker.
2. State the business requirement in the business's terms and the technical limit in specifics, for example the field width, the run window or the interface that could not change.
3. Walk through the options you weighed, such as phasing the work, adding an adapter around the old component, accepting batch latency, or adding a reconciliation step, with the cost of each, and say which you chose and why.
4. Explain how you put the trade-off to non-engineers, what the business gave up, and how the result held up afterwards. Avoid stories that end in heroics or blame the business.

Follow-up

• What did the business lose by the option you chose?
• Would you make the same call today, and what has changed since?
• How did you record the decision so the next team understood it?

Can you provide an example of a challenging project and how you overcame obstacles?

Medium · Behavioral / Leadership

Approach

1. Name what made the project hard in concrete terms: an unfamiliar legacy system, a fixed deadline, unclear requirements, or a defect you could not reproduce. Avoid vague answers such as a lot of work.
2. Break the obstacles into two or three named ones. For each, say what you did and why you chose that action, instead of listing tasks.
3. Separate your contribution from the team's with first-person decisions, and include one point where your first approach failed and you changed course.
4. Finish with a checkable result (a shipped release, a defect class removed, a run that reconciled) and one thing you would do differently.

Follow-up

• What was the first approach that failed, and how did you notice?
• If scope had to shrink, what would you have cut first?
• Who else was affected, and how did you keep them informed?

How do you handle conflicts within a team setting?

Medium · Behavioral / Leadership

Approach

1. Use a conflict about substance, such as a design choice, review feedback or who owns a defect. A personality clash gives you little to show.
2. Show the sequence: you asked for the other person's reasoning and restated it, found the real constraint behind it, moved the discussion to shared criteria (a benchmark, a small spike, the spec, a defect count) and then decided together or escalated with a clear summary.
3. Say what you conceded. A story where you were right and the other person simply came round is not convincing.
4. End with the outcome for both the work and the working relationship. Do not claim that you avoid conflict.

Follow-up

• What if the other person still disagreed after seeing the data?
• When would you take the disagreement to a manager?
• How did you work with that person afterwards?

Describe a time when you had to mentor a junior developer. What approach did you take?

Medium · Behavioral / Leadership

Approach

1. Name the junior developer's starting point and goal specifically: new to the codebase, first on-call rotation, or learning to read legacy code.
2. Describe your method: pairing on a real task, reading a program together before changing it, starting with small changes and growing scope, and code-review comments that explain the reason instead of only the fix.
3. Include a moment where you held back from fixing the problem yourself, and how you checked their understanding afterwards.
4. Close with evidence of growth, such as a change they shipped alone or a review they later gave. Do not turn the story into a lecture, and do not claim their work as yours.

Follow-up

• What did you do when they repeated the same mistake?
• How did you balance mentoring with your own deliverables?
• How would you teach a developer who has never seen COBOL or a legacy codebase?

How do you prioritize tasks when managing multiple projects?

Medium · Behavioral / Leadership

Approach

1. Show a method applied to a real week: list the work, rank by impact and urgency, note dependencies, and mark dates that are fixed by someone else, such as a release or a regulatory change.
2. Say who you ask when priorities collide. Taking the ranking to the product owner or manager and making the trade-off visible is stronger than silently deciding.
3. Include a time you deferred or declined something, how you told the people affected and what happened.
4. Describe the mechanism that keeps it working: a written list, a regular re-ranking and a simple rule for interruptions. Answers like I work harder or everything is a priority fail.

Follow-up

• A production issue lands in the middle of a sprint. What moves?
• Two stakeholders each say their request comes first. What do you do?
• How do you notice that you have over-committed?

What motivates you to excel in your role as a software engineer?

Medium · Behavioral / Leadership

Approach

1. Give one or two true drivers and back each with something you did: staying to find why a reconciliation was off, or making old code safe to change.
2. Link the driver to the work candidates describe for this role, such as maintaining financial systems, debugging and modernizing legacy code, without claiming facts about the employer you cannot know.
3. Keep it story-sized: one concrete example of the motivation in action is stronger than a list of adjectives.
4. Avoid pay as the main reason, generic love of solving problems with no example, and praise for the mission that you cannot connect to what you would do day to day.

Follow-up

• What would make you lose motivation in a role?
• Tell me about a task you found dull and how you handled it.
• What do you want to learn in your first year in this job?

Describe how you would handle a situation where you disagree with a product owner on a software feature.

Medium · Problem-Solving / Case Studies

Approach

1. Pick a real feature disagreement and state both positions fairly, including the product owner's reasoning, whether that was user need, a regulation or a deadline.
2. Bring evidence instead of opinion: an estimate, a named risk (data integrity, rework, compliance), a prototype or a small test, and an alternative such as a smaller first version.
3. Show the decision path: you made your case clearly once, the product owner kept the priority call, and if you were overruled you committed and added mitigation or monitoring. Escalate only for a compliance or integrity risk.
4. State the outcome and what you learned. Weak versions are I convinced them with no concession, or going around the product owner.

Follow-up

• What if the product owner is wrong on a compliance point?
• If you were overruled and it went badly, what would you say?
• How do you disagree when several stakeholders are in the meeting?