TL;DR
- Start SAP ABAP answers by identifying the system release, language version and business operation you are implementing.
- Choose an internal table from its access pattern and uniqueness requirements; a hashed table is not a universal performance upgrade.
- Test empty inputs, duplicate business keys and partial failures before discussing the happy path of a data-processing job.
- Separate classic ABAP techniques from ABAP Cloud's released-API model, and explain how you would verify the exact environment.
Prepare around a business problem, not a list of definitions
A useful SAP ABAP interview answer connects language features to business data. Knowing the words “standard,” “sorted” and “hashed” is a starting point. Explaining how the choice changes duplicate handling in a supplier lookup is much more revealing.
The eight questions below use an original purchase-order reconciliation scenario. A report receives a set of supplier IDs, reads relevant purchase orders, calculates exceptions and prepares follow-up work. The examples are design exercises checked against SAP documentation. They have not been executed in an SAP system and do not claim to reproduce an employer's interview questions.
First ask whether the role concerns classic on-premise development, an S/4HANA environment, ABAP Cloud or a mixture. The permissible interfaces and language features matter, especially when an existing implementation relies on older enhancement or database-access patterns.
1. How do you choose an internal table category?
Suppose the reconciliation report needs to find a supplier by its ID hundreds of times. Ask whether there should be exactly one row per supplier and whether the job also needs ordered range processing.
SAP's table-key documentation distinguishes the three primary categories. A standard table has a non-unique primary key; a sorted table maintains sorted key order and can use a unique or non-unique primary key; a hashed table has a unique hash key.
| Requirement in the example | Candidate choice | Question to settle |
|---|---|---|
| Preserve an imported sequence for later processing | Standard table | Which explicit key or index will later reads use? |
| Process orders grouped by supplier in key order | Sorted table | Must repeated supplier IDs be allowed? |
| Find one supplier record by a unique full key | Hashed table | What happens if source data contains duplicates? |
| Preserve one main structure but add another access path | Consider a secondary key | Is the read benefit worth maintaining the extra key? |
A secondary key does not improve every statement automatically. Name the key in the operation that needs it and account for memory and update costs. Performance claims should reflect a measured workload, including table construction and mutation, rather than a single lookup isolated from the rest of the job.
2. Can you sort a hashed table?
This question exposes a common overgeneralization. SAP documents that explicit SORT can be applied to standard and hashed tables, while sorted tables already maintain their defined order. A hashed table still has no primary table index; sorting affects sequential processing such as a loop. See the current sorting reference.
For the reconciliation report, state the business order explicitly. “Sort by supplier, then requested delivery date” is clearer than relying on an implicit default key. If equal sort values must preserve their earlier relative order, discuss STABLE; that behavior is not the default.
Do not confuse sorting presentation order with changing uniqueness. A sorted view of duplicate supplier records does not resolve whether duplicates are valid. Likewise, sorting a hashed table does not turn it into a structure supporting ordinary primary-index reads.
The practical answer is about the next operation: keyed access, ordered iteration or output formatting. Choose the representation that supports that operation without hiding a data-quality decision.
3. What could go wrong with an empty FOR ALL ENTRIES input?
In a classic ABAP implementation, a developer might select purchase orders using an internal table of supplier IDs. Before discussing speed, examine what happens when that driver table is empty.
SAP's FOR ALL ENTRIES guidance calls out a critical behavior: an empty internal table causes the entire WHERE condition to be ignored. A job intended to process a small supplier set can therefore retrieve all rows.
For this exercise, define empty input as “nothing to reconcile.” Check that condition before the query and return an empty result with an explicit completion reason. If the business instead intends a full run, make that a separate, visible mode with appropriate controls.
Then compare supported alternatives such as a join or another set-oriented query in the actual language version. Explain selected columns, filtering, source uniqueness and expected result grain. Do not claim that one older idiom is always faster, or assume it is available in every ABAP Cloud context.
An interview test case should assert both the result and whether the expensive database operation was called when the input was empty.
4. How would you prevent duplicate rows from changing a total?
Imagine supplier A has two purchase orders and three contact records. Joining orders directly to contacts can repeat each order three times. A total that looks plausible may therefore be wrong even though the query runs successfully. This row multiplication is the same fan-out problem that SQL interview questions on joins test in data and backend rounds.
State the intended result grain: one row per purchase order, one per supplier, or one per supplier-contact pair. If the output is supplier-level spend, aggregate orders at the appropriate key before attaching independent one-to-many data, or choose a specific contact according to a business rule.
Build a tiny example by hand. Two orders worth 100 and 150 should contribute 250, not 750 merely because the supplier has three contacts. Adding DISTINCT to a final amount is not a principled repair: two legitimate orders may have equal values.
A useful test adds a second order with the same amount, an order with no contact record and a repeated import event. Each exposes a different assumption. This is a business-data question that table syntax alone cannot answer.
5. What happens when only part of a business operation succeeds?
Suppose a reconciliation job records an exception and then requests a follow-up action from another system. The local database commit and the remote request do not automatically become one indivisible operation.
Ask who owns the SAP logical unit of work, which business API is supported and where commit or rollback belongs. Avoid scattering commits inside helper routines when the caller is responsible for coordinating the larger operation. The exact transaction behavior must be verified for the selected APIs and release.
For a remote failure, define a recoverable state rather than silently marking the operation complete. Store a durable business identifier, make repeat processing distinguish a retry from a new request, and decide how to reconcile an uncertain response. “Retry three times” does not answer whether the first request already succeeded. The same concern is behind the idempotency keys covered in distributed systems interview questions about safe retries.
In a real interview, connect this to a change you actually handled. Describe the business invariant, how you observed an incomplete operation and how you made recovery understandable to support staff.
6. How would you test this code with ABAP Unit?
Keep the decision logic separate from dependencies where practical. A function deciding whether an order is late should not need a live supplier system just to test a date boundary.
SAP describes dependency isolation and test doubles in its ABAP Unit development guidance, including support for testing code that uses SQL dependencies. The available framework and restrictions should be checked against the development environment.
For the reconciliation scenario, propose five specific tests: empty supplier input, repeated supplier IDs, a delivery date exactly on the boundary, two legitimate equal-value orders and a dependency failure after partial work. Use a controllable date source so the test does not change outcome next month.
A unit test can prove a business rule under controlled inputs. It does not prove that production authorizations, database plans or external connectivity are correct. Add targeted integration tests for those boundaries and explain which environment they require.
7. How does ABAP Cloud change your implementation choices?
Do not describe ABAP Cloud as simply running any existing ABAP code somewhere else. SAP's overview of key ABAP Cloud concepts explains the importance of released APIs and extension contracts.
If the existing report uses an internal object that is not released for the relevant use, first identify a supported interface or extension point. Then examine whether the business behavior can be preserved through that interface. Copying a classic technique without checking the release contract can create a maintenance problem even when the code appears familiar.
A credible migration answer inventories dependencies, separates business rules from access code and validates one representative operation before proposing a large rewrite. It also distinguishes a documented capability from an assumption about a particular customer's edition or installed release.
8. A report became slow after a data increase. What would you inspect?
Start with the measured symptom: total runtime, database time, row counts, time spent transforming data and whether the slowdown affects every input. Compare the same workload before and after the change if that evidence exists. Production debugging rounds in backend engineer interviews ask for the same habit: symptoms and a hypothesis before a fix.
Inspect repeated database access inside loops, unexpectedly broad selections, row multiplication and internal-table access patterns. A missing key may matter, but so may loading ten times more data than the user requested. Use the diagnostic tools available in the actual SAP environment and retain the representative input conditions.
After a change, compare correctness as well as runtime. An optimization that drops duplicate business records may run faster by doing the wrong work. Include the equal-value-order and empty-input cases from this guide in the regression check.
Turn the questions into a rehearsal
Draw the supplier-to-order-to-contact relationships. Explain one query, one internal-table choice and one failure-recovery sequence without referring to notes. Then ask someone to change a requirement: duplicate suppliers become valid, input is empty, or the remote service returns an uncertain response.
Use PhantomCodeAI for permitted practice if it helps you speak through the tradeoffs. The strongest preparation is an explanation you can defend with the business rule, the actual SAP environment and a specific test.