SAP ABAP developer interview questions

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · certification facts checked against SAP Learning, October 2026

SAP ABAP developer interview questions test whether you can build, change and diagnose code inside an SAP system without harming it: the language and data dictionary, database-minded performance, the current programming model and its clean-core rules, transports and debugging, and usually a live problem. Each part below carries its questions and what separates a rehearsed answer from a lived one.

As of October 2026, the model interviewers ask about is ABAP Cloud — the RESTful Application Programming Model, released APIs and the ABAP for Cloud Development language version — which is the only ABAP allowed in SAP S/4HANA Cloud Public Edition and in the BTP ABAP environment, while classic ABAP stays available on premise and in private cloud. SAP's certification for it is now titled SAP Certified - Backend Developer - ABAP Cloud and listed as a beta version of the practical exam: a three-hour system-based assessment, taken in your own Eclipse with ABAP Development Tools, that also tests working with Joule for developers. The model is documented on the Help Portal.

What does an ABAP interview cover?

The blocks below appear in most interviews, whether the seat is at an integrator, a product company or an in-house team. The weights differ by project: a conversion programme leans on custom-code remediation and performance; a cloud-first build leans on the current programming model; a support seat leans on debugging.

• Core language and data dictionary. Internal tables and their kinds, field symbols and references, object orientation, the dictionary objects — domains, data elements, tables, views, search helps — and how Core Data Services views changed what "a view" means.
• Performance thinking. Why a select inside a loop is the classic mistake, when a sorted or hashed table matters, what table buffering does, and why the current platform wants logic pushed down to the database rather than fetched up into ABAP.
• The current programming model and clean core. The ABAP RESTful Application Programming Model (RAP), ABAP Cloud and its released-API rule, the difference between key-user and developer extensibility, and when an extension belongs beside the system on what SAP BTP is and what runs on it rather than inside it.
• Debugging and transport discipline. The debugger, the runtime analysis tools, the static checks, how a transport request is assembled and sequenced, and what you do when one arrives in production out of order.
• A live problem. A piece of code to read and critique, a symptom to diagnose aloud, or a small design to sketch — where everything above is watched at once.

Which topics does an ABAP interviewer test, and how?

Each topic has a recognisable question type, and the job title on the posting — programmer, developer, technical consultant — barely changes it. The table pairs each topic with the example question a panel tends to open on.

How would you answer those opening questions?

Briefly, and with the mechanism. The short versions:

• The repeated read by key. A hashed table when the full unique key is always known, because the lookup time does not grow with the table; a sorted table when you also read by the leading part of the key or need the rows in order.
• FOR ALL ENTRIES with an empty driver table. The whole WHERE condition is ignored, so the statement reads every row of the database table. Check for an empty driver table first, and remember that duplicate result rows are removed.
• Row-level authorisation on a CDS view. In a CDS access control: a role written in the data control language that ties the view to an authorisation object and is applied whenever ABAP SQL reads the view.
• Unmanaged persistence in RAP. When the save logic already exists in a BAPI, a function module or an update task and has to remain the one way the data is written.
• The background-only failure. Read the job log and the dump first. Then select the job in SM37 and enter JDBG in the command field to run it in the debugger, or attach to the running work process from SM50.

Which questions should you expect?

Representative phrasings, grouped by what they probe. Learning answers by rote defeats the purpose; learning to recognise the type does not.

• Language and dictionary. "When would you choose a hashed table over a sorted one, and what does that choice cost you?" "What is the difference between a domain and a data element, and why does the dictionary separate them?" "Explain what a CDS view with associations gives you that a classic database view does not."
• Performance. "Here is a report that takes minutes. Without running it, where would you look first?" "What does code pushdown mean, and where does it stop being a good idea?" "How do you decide whether a table should be buffered?"
• Modern model and clean core. "A client wants a custom field and a validation on a standard business object. Walk me through key-user extension, developer extension and a side-by-side app, and pick one." "What does 'released API' mean in ABAP Cloud, and what do you do when the one you need is not released?" "Describe a RAP business object you built: the behaviour definition, the implementation, the service exposure."
• Discipline. "A transport failed in the quality system with a missing dependency. What happened, and how do you prevent it?" "What do the static checks flag in a conversion, and which findings did you fix versus justify?" "How do you debug a background job you cannot reproduce in the foreground?"
• Fiori and integration edges. "How does a Fiori elements app get its user interface from annotations, and where do those annotations live?" "An OData service returns the wrong data for one user only. What are the usual suspects?" The front-end roles themselves are in SAP Fiori developer and UX careers.

What does a good answer show?

The interviewer is rarely checking whether you know a keyword. What separates the answers that get offers:

• Mechanism over memory. "A hashed table gives constant lookup on the full key and nothing else" beats a recited definition, because it shows you can decide the next case unaided.
• Cost awareness. Every design has a price — a side-by-side app has its own runtime, monitoring and release cycle; a modification has an upgrade bill. Naming the price, unprompted, is what architects are made of.
• Scars. The out-of-sequence transport you cleaned up, the performance fix that broke a downstream report, the released-API gap you worked around. Real stories carry detail that courses do not, which is why experience is read that way.

For the live problem specifically: narrate. Say what you are looking at, what you suspect and what you would check next. A silent candidate who reaches the right answer scores lower than a talkative one who gets most of the way: a fix nobody could follow is a fix a reviewer sends back, and thinking aloud is the audition for that review.

How should you prepare?

• Bring your own code to mind. Pick a handful of objects you built and be ready to explain their design, what you would change now, and how they were tested and transported. The walkthrough of your own work is most of the interview.
• Build something in the current model. A small RAP service with a Fiori elements front end, in a trial or sandbox system, gives you concrete answers to the modern-model questions and is showable before a first project.
• Re-read the performance basics with the database in mind: table types, buffering, pushdown, the difference between a long-running select and a long-running loop.
• Know the functional side of your last project. Developers who can explain the business process their code serves are the ones functional colleagues ask for by name; the functional interview guide shows what that side sounds like.
• Have your facts consistent across your CV and your public profile — areas, roles, start year. The developer career guide explains what the market expects a developer profile to say.

Which answers are red flags?

• Modification first. Changing standard code when an extension point or released API exists says you have not worked under clean-core rules.
• Performance by superstition. Rules without their mechanism collapse on the follow-up.
• No transport story. A developer whose transports never went wrong has not shipped much.
• Contempt for the functional side. The functional and technical divide is real; treating it as a hierarchy reads badly.