Performance tuning is almost never asked as a definition question. It arrives as a scenario — a report that used to finish in minutes now runs for hours — and the interviewer is measuring whether you measure. Candidates who start listing optimisations before naming a measurement tool are the ones who get filtered out.
This page collects reviewed ABAP performance and Open SQL interview questions with complete written answers. Between them they cover the analysis path (trace before change), the database side (selective WHERE clauses, index usage, aggregate and join behaviour, buffering), the ABAP side (nested loops, sorted and hashed access to internal tables, reads inside loops), and the S/4HANA-era question of what should be pushed down to the database instead of looped in ABAP.
The answers deliberately keep the order that works in a real interview: what you would measure, what the measurement would tell you, what you would change, and how you would prove the change helped. That last step is the one most candidates skip and most interviewers are listening for.
Expect to be asked which tool you would reach for before touching code. SQL trace and runtime analysis are the two answers that carry weight, and being able to say what each one shows you — statements and their cost versus where the time is spent in the program — matters more than naming them.
Most slow SQL in ABAP is a selection that cannot use an index or a read placed inside a loop. Interviewers probe whether you reason about which fields are actually restricted, not whether you can recite 'add an index'.
Standard, sorted and hashed tables, binary search on a sorted table, and the cost of nested loops are near-guaranteed questions at 2–6 years of experience, usually as 'this loop is slow — what would you change?'.
For S/4HANA projects the question becomes where the logic belongs. Aggregation, joins and filtering done by the database instead of by an ABAP loop is the expected direction, along with an honest account of when that is not worth it.
Ordered from foundational to advanced. No sign-in required.
The questions above are tagged by the experience levels they are normally asked at, so the same page works for a first interview and for a lead-developer round.
Reproduce it and measure it. A runtime analysis shows where the program spends its time and an SQL trace shows which statements the database actually executed and how expensive they were. Only after that measurement does it make sense to talk about indexes, buffering or restructuring loops.
Because it turns one database round trip into as many round trips as the loop has rows, and each of them carries fixed overhead regardless of how small the result is. The standard remedies interviewers expect are reading the required set once into an internal table and then working locally, or letting the database do the join and aggregation in a single statement.
By the access pattern. A hashed table is for single-record access by full key and gives constant-time reads. A sorted table is for reads by a leading part of the key, for ranges and for processing in key order. A standard table with a linear search is the option to justify, not the default.
It means letting the database do set-oriented work — filtering, joining, aggregating, calculating — instead of transporting rows into ABAP and looping over them. In practice that shows up as more expressive Open SQL and CDS-based models, and as removing ABAP loops that only exist to add up or filter what the database could have returned already.
By comparing the same measurement before and after on comparable data volumes, and by checking that the result set is unchanged. Interviewers value the second half of that answer: a faster program that returns different data is a defect, not an optimisation.
ERP Climb is an independent educational platform and is not affiliated with SAP SE.
