SAP ABAP developer interview questions

An ABAP developer interview tests whether you can build, change and diagnose code inside an SAP system without harming it: the language and its data dictionary, the performance habits a database-centric platform demands, the current programming model and the clean-core rules that come with it, the discipline of transports and debugging, and usually a live problem. This guide walks through each part, the questions it produces, and what a good answer shows.

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 BTP 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 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?"

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, because the job is done in a team and the narration is the skill.

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 as the first tool. Reaching for a change to standard code, when an extension point or a released API exists, tells the interviewer you have not worked under clean-core rules.
• Performance by superstition. Rules repeated without the mechanism behind them fall apart on the follow-up question.
• No transport story. A developer who has never had a transport go wrong has not shipped much.
• Contempt for the functional side. The best developers on any SAP project are the ones the process people trust; the divide is real, but treating it as a hierarchy reads badly.