ERPClimb logoERPClimb

SAP Architect Debugging Interview Questions

Interviewers use debugging to test depth rather than coverage: the follow-up question is almost always "why does the system behave that way?", and that is where prepared answers usually run out.

Master ABAP debugging with breakpoints, watchpoints, update debugging, background jobs, RFC/OData debugging, ST22 dump analysis and production-safe root cause analysis.

This page carries 13 reviewed SAP Architect debugging interview questions, each with a complete written answer and no sign-in required. The set breaks down into 2 foundational, 9 mid-level and 2 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

If you can handle every question here without hesitating, debugging is unlikely to be what costs you an SAP Architect interview — and the same reasoning pattern transfers to the neighbouring topics linked at the bottom of this page.

13 Debugging questions with answers

easyDebugging

1. A field is being overwritten mysteriously. What is a watchpoint and how would you use it here?

A watchpoint pauses execution when a variable or field-symbol changes value (optionally with a condition). In the debugger, create a watchpoint on the specific structure component; run to next occurrence and inspect the call stack to identify the write. Combine with the changes tab to see the before/after value. Prefer watchpoints over stepping through hundreds of lines.
mediumDebugging

2. A field on a screen is being cleared unexpectedly. How do you find the code that clears it?

In the new debugger set a watchpoint on the field / variable. Recreate the scenario; the debugger halts on write. If it is a dictionary field on a structure, set the watchpoint on the specific component. For UI-only issues use PBO/PAI module breakpoints. If it is inside a framework call, enable system debugging and layer-aware stepping; screen exits and enhancements can also touch the field – check SE81 / SE18 for active implementations.
mediumDebugging

3. A READ TABLE does not return data even though you expect a record. What would you check in debugger?

I would check the internal table content, the key fields used in READ TABLE, whether the values have leading zeros or formatting differences, whether the table is sorted if BINARY SEARCH is used and sy-subrc immediately after the READ TABLE.
mediumDebugging

4. A short dump shows MESSAGE_TYPE_X in a UPDATE task function module. Walk me through the investigation.

A type-X message rolls back the LUW and always dumps. In ST22 open the runtime info: the include, source line, and the actual message id/number. Reproduce by re-running the calling report in the debugger, set a breakpoint at the CALL FUNCTION ... IN UPDATE TASK, then use update debugging (/h + settings) to step into the update work process. Fix the root data issue that triggered the MESSAGE X; never mask a type-X with a type-E.
mediumDebugging

5. How do you debug a background job that only fails in production and cannot be reproduced in DEV/QA?

Use SM37 for the job log, ST22 for short dumps around the failure time, SLG1 for application logs the program may have written, and STAD for the ABAP runtime. If a specific user is affected, use SM50 breakpoint on user and reproduce carefully in a controlled window, or add temporary custom logging behind a switch (SFW5 / feature flag) and re-run. Never leave breakpoints active in prod.
mediumDebugging

6. A background job fails intermittently with a short dump. How do you debug it?

Check ST22 for the dump: exception, source line, call stack, variable values, user, and timestamp. If reproducible, run in dialog with the same variant. If not, set a checkpoint group (SAAB) or a soft breakpoint tied to a user or a condition; enable background debugging via JDBG on the job in SM37 with debug parameters, or use system debugging. Add defensive logging in application log (SLG1) around the failing area for future incidents.
hardDebugging

7. What is your approach to production debugging?

I first collect exact input, user, transaction, timestamp and error details. I check logs, ST22, SM37, SLG1, IDoc status or output history before debugger. If debugging production is approved, I use focused breakpoints and avoid changing variable values or business data. I document findings and reproduce/fix in non-production where possible.
mediumDebugging

8. Your breakpoint is not stopping in a function module called IN UPDATE TASK. What is the reason?

The function module runs in update task during COMMIT WORK, not in the normal dialog flow. A normal breakpoint may not stop there unless update debugging is enabled before the update task is triggered.
mediumDebugging

9. You suspect an authorization issue is silently blocking data in a report. How do you confirm it in the debugger?

Turn on the authorization trace (SU53 for the last failure of the current user, ST01 or STAUTHTRACE for a live trace across users). In the debugger, set a breakpoint on AUTHORITY-CHECK or watchpoints on sy-subrc after specific auth calls to see which object fails and with what values. Then compare with the assigned profiles in SUIM. Fix by adjusting the role, never by removing the check.
easyDebugging

10. What is the difference between a session breakpoint and an external breakpoint?

A session breakpoint stops execution only in the current SAP GUI session. An external breakpoint is user-specific and can stop code triggered externally, such as RFC, OData, web applications or another session for the same user.
mediumDebugging

11. The report is slow only for one user. What runtime traces would you use and in what order?

Start with STAD (or ST12) filtered by user and time window to see wall-clock breakdown between ABAP, DB, and RFC. If DB dominates, follow up with ST05 SQL trace of a reproducer run; if ABAP dominates, use SAT (runtime analysis) to find the hot method. Compare with a run for another user of the same data set to isolate role- or variant-specific behaviour.
mediumDebugging

12. A report works in foreground but fails in background. How would you debug it?

I would check SM37 job log, spool, variant and background user first. Then I would compare foreground input with job variant. If needed, I would use JDBG to debug the background job. I would also check whether the program uses frontend-dependent logic like GUI_UPLOAD.
hardDebugging

13. A production LUW committed partial data — how do you investigate and recover?

Reconstruct the LUW: check SM13 for failed updates, SLG1 for application logs, change documents (CDHDR/CDPOS) for what did land, and STAD for the exact sequence. A partial commit usually indicates a missing COMMIT WORK / ROLLBACK boundary, a COMMIT inside a subroutine, or an unhandled exception between related updates. Recovery is data-driven: build a compensating change doc or use standard reversal transactions; never patch tables directly in prod.

Related lesson

Debugging Internal Tables and Field Symbols

Related topics

Cross-Module Integration and Non-Functional ArchitectureABAP CoreOData GatewayCDS ViewsRAP BasicsInternal TablesS/4HANA Clean CoreOpen SQL

Next practice step

Practice with Interview AITake a mock test