SAP Interview Questions (2026): Most Asked, With Answers

Most technical loops run three to five stages: a recruiter screen focused on background and location/visa logistics, a technical phone or video screen with a live coding or ABAP exercise, one or two panel rounds covering deeper technical depth plus a system design or architecture discussion, and a hiring manager or culture conversation near the end. For consulting and functional roles the technical screen is replaced with a case-style walkthrough of a business process, like how you'd configure a procurement or order-to-cash flow.

Candidates who've been through both large-vendor and startup loops describe SAP's process as closer to a traditional enterprise timeline than a fast-moving product company's, sometimes several weeks between stages, which is worth planning around if you're juggling competing offers.

S/4HANA is SAP's current-generation ERP suite, built to run natively on the HANA in-memory database rather than on a traditional row-store database that ECC (ERP Central Component) was designed for. The practical differences show up in the data model: many aggregate and index tables that ECC maintained separately, like the classic tables that stored summarized stock or accounting totals, were simplified or eliminated because HANA can calculate those aggregates on the fly from the underlying line items instead of storing precomputed copies.

S/4HANA also replaced most of the older SAP GUI transaction screens with Fiori-based web apps as the default user experience, though the underlying ABAP transactions still exist for compatibility.

SuccessFactors handles human capital management, recruiting, performance, and payroll workflows. Ariba runs procurement and supplier network transactions between buyers and sellers. Concur manages travel and expense reporting. SAP Business Technology Platform (BTP) is the cloud layer for building extensions, integrations, and analytics on top of the core suite. Each of these has its own product roadmap and, often, its own hiring pipeline separate from core S/4HANA.

SELECT SINGLE requires the WHERE clause to uniquely identify a row using the table's key fields and returns exactly that one row, or no row at all if nothing matches. SELECT... UP TO 1 ROWS doesn't require a unique key match, it runs the full query as written and simply stops after fetching the first row the database happens to return, which means the result can be non-deterministic if the WHERE clause doesn't already guarantee uniqueness and there's no ORDER BY.

" Deterministic: MATNR is the key field for MARA
SELECT SINGLE * FROM mara WHERE matnr = @lv_matnr INTO @DATA(ls_mara).

" Not necessarily deterministic without ORDER BY
SELECT * FROM mara UP TO 1 ROWS INTO @ls_mara WHERE werks = @lv_werks.
ENDSELECT.

An internal table is ABAP's in-memory, dynamic array structure, the workhorse for holding and processing sets of records inside a program. A standard table keeps rows in insertion order and requires a linear scan for most lookups. A sorted table maintains a defined key order automatically and supports binary search for reads. A hashed table uses a hash algorithm on a unique key and gives near-constant-time lookups, but only supports access by that key, no index-based access at all.

DATA: lt_standard TYPE STANDARD TABLE OF mara,
   lt_sorted  TYPE SORTED TABLE OF mara WITH UNIQUE KEY matnr,
   lt_hashed  TYPE HASHED TABLE OF mara WITH UNIQUE KEY matnr.

Row-store keeps all columns of a single record physically together on disk or in memory, which is efficient when a query needs most or all fields of a small number of rows, a classic OLTP pattern like fetching one customer's full record. Column-store keeps each column's values contiguous across all rows, which is far more efficient for aggregating or filtering across millions of rows on just a few columns, the classic OLAP pattern. HANA defaults most tables to column-store because it's built to serve both transactional and analytical queries against the same tables, and the analytical pattern is common enough across S/4HANA's own workload to justify it as the default.

SAPUI5 is the JavaScript UI framework itself, controls, data binding, MVC structure, comparable in role to a framework like Angular. Fiori is SAP's design language and set of UX guidelines built on top of SAPUI5, defining how a list report or an object page should look and behave consistently across apps. Fiori Elements goes a step further and generates a full working app, list page, object page, from an annotated OData metadata document with minimal hand-written UI code at all, trading some flexibility for a large reduction in boilerplate.

Two-way binding keeps a UI control and a model property automatically synchronized in both directions: changing the model updates whatever's bound to it in the view, and a user editing an input field pushes that new value back into the model without manual event-handler wiring on every keystroke.

// View (XML)
// <Input value="{/customerName}" />

// Controller
var oModel = new sap.ui.model.json.JSONModel({ customerName: "Acme Corp" });
this.getView().setModel(oModel);
// typing in the Input control updates oModel's customerName automatically

Released APIs, whether OData services or the newer API Business Hub-catalogued interfaces, come with a compatibility guarantee that direct table access never had. SAP can and does restructure underlying database tables between releases, sometimes significantly, as it did moving from ECC to S/4HANA's simplified data model. Code written against a released API keeps working across that kind of change because the API contract stays stable even when the tables underneath it don't. Direct table reads skip that layer of protection entirely and break silently on upgrade.

Track values you've already seen in a set, and only keep an element the first time it's encountered.

function dedupe(arr) {
 const seen = new Set();
 const result = [];
 for (const item of arr) {
  if (!seen.has(item)) {
   seen.add(item);
   result.push(item);
  }
 }
 return result;
}

Walk both arrays with a pointer each, always taking the smaller of the two current elements, then append whatever's left over once one array runs out.

function mergeSorted(a, b) {
 const result = [];
 let i = 0, j = 0;
 while (i < a.length && j < b.length) {
  result.push(a[i] <= b[j] ? a[i++] : b[j++]);
 }
 return result.concat(a.slice(i)).concat(b.slice(j));
}

This one is looking for whether you can disagree constructively without either caving immediately or becoming difficult to work with. A strong answer names the specific concern clearly, shows you brought data or a concrete alternative rather than just an objection, and describes the actual outcome honestly, including if the stakeholder's original call turned out to be right after all. Interviewers notice when a candidate only tells stories where they were vindicated.

A weak answer is generic, "I like enterprise software" works anywhere. A strong answer connects something specific, a product area, a customer segment, the clean-core extensibility direction, to the candidate's actual background and where they want to grow next, and it's honest about the tradeoff of joining a large, established company over a smaller one, more structure and process, in exchange for scale, established customer relationships, and the kind of deep domain problems that only show up once software runs a company's actual finance or supply chain operations at real volume.

Product engineering loops at SAP look much closer to a general software company: data structures and algorithms, a system design round scaled to the specific product area (HANA, BTP, SuccessFactors, Ariba), and a code review or pairing exercise. Consulting loops, whether SAP-employed or through an implementation partner, weight business-process knowledge much more heavily, how would you handle a client that wants a customization SAP recommends against, how do you scope a module rollout, and often include a scenario-based case study instead of a whiteboard problem.

The one thing both tracks share is a heavier-than-average emphasis on communicating with non-technical stakeholders, since almost every SAP role eventually touches a customer's business process directly or indirectly.

Get hands-on with the SAP Business Technology Platform trial account and the free tier of the SAP Community, both of which let you spin up an ABAP environment or a HANA instance without a customer license. Build one small thing end to end, a CDS view exposed as an OData service consumed by a Fiori app, rather than reading documentation passively. Interviewers can tell within a few minutes whether a candidate has actually typed ABAP or only read about it.

Less than most candidates assume for pure engineering roles inside a product team, more than most candidates assume for anything touching an implementation or customer success function. SAP's product organization hires plenty of engineers from outside the SAP ecosystem specifically because fresh perspective on developer experience and cloud-native architecture is in short supply internally. Customer-facing roles lean the other way, since ramp-up time on an unfamiliar module can cost a project real weeks.

An in-memory database keeps the primary copy of data in RAM rather than reading it from disk on every query, and HANA specifically combines that with column-store storage, which keeps each column's values contiguous so aggregations across millions of rows can scan just the columns a query actually needs instead of full rows. The combination is what let SAP collapse operational reporting and analytical reporting into the same system, instead of running a separate data warehouse fed by nightly batch jobs the way ECC-era architectures typically did.

A client is a self-contained business unit within a single SAP system installation, with its own master data, transactional data, and customizing settings, identified by a three-digit client number. Multiple clients can share the same application server and database instance while staying logically isolated from each other, which is how a single SAP landscape often supports a development client, a quality assurance client, and a production client without three separate installations.

Customizing means adjusting settings through SAP's supported configuration tables and transactions (SPRO and its underlying IMG structure), staying entirely within what SAP ships and supports. A modification means changing SAP's actual standard code or standard objects directly, which SAP does not guarantee will survive an upgrade or a support pack. Teams avoid modifications because every one becomes technical debt that has to be manually reapplied or reconciled during every future upgrade, sometimes years later, by someone who wasn't on the original project.

Public cloud S/4HANA is multi-tenant, which means SAP controls the underlying system and only exposes extensibility through released APIs and the in-app and side-by-side extensibility frameworks on BTP, no direct database or ABAP-core access at all. Private cloud and on-premise editions give a customer their own dedicated system, which still permits classic ABAP development inside the customer namespace, though SAP increasingly steers even those customers toward clean-core practices to keep future upgrades manageable.

Core Data Services views let you define joins, calculations, and associations once in the database layer, in a way HANA can push down and optimize as a single execution plan, instead of pulling raw table rows into ABAP internal tables and joining them in application-layer loops. A CDS view is also reusable across multiple consumers, an OData service, a report, another CDS view, whereas application-layer join logic tends to get copy-pasted between programs and drift out of sync over time.

define view Z_C_SalesOrderItem as select from vbap
 association [1..1] to vbak as _Header on _Header.vbeln = vbap.vbeln
{
 key vbap.vbeln,
 key vbap.posnr,
 vbap.matnr,
 vbap.netwr,
 _Header.kunnr,
 _Header
}

A classic report is procedural, one long linear flow with FORM subroutines, global data, and event blocks like AT SELECTION-SCREEN and START-OF-SELECTION dictating execution order. An object-oriented approach wraps the same logic into classes with private state and public methods, which makes the logic unit-testable in isolation (SAP's own ABAP Unit framework expects exactly this shape) and reusable from other programs without copy-pasting a FORM routine.

SAP has been steering developers toward the OO style for years, mostly because a global-data procedural report is close to impossible to unit test without running the whole program end to end.

An exception class (inheriting from CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NO_CHECK depending on how strictly the compiler should enforce handling) lets a method signal a failure by raising a typed object carrying its own message and attributes, caught with TRY/CATCH at whatever level actually knows how to handle it. The older SY-SUBRC pattern requires the caller to remember to check the return code after every single statement, and nothing forces that check to happen, a missed IF sy-subrc <> 0 just silently continues execution with stale or wrong data.

TRY.
  lo_service->get_order( iv_order_id = lv_id ).
 CATCH cx_order_not_found INTO DATA(lx_error).
  MESSAGE lx_error->get_text( ) TYPE 'E'.
ENDTRY.

A BAdI is an SAP-defined extension point in standard code where SAP has explicitly allowed custom logic to plug in through a defined interface, without touching the standard object itself. Because the extension point is officially released, it survives support packs and upgrades the way a direct modification wouldn't. Enhancement points work similarly but are more implicit, inserted at specific lines SAP has marked as safe to extend. Reaching for a BAdI first, and only falling back to a modification when no extension point exists, is close to a universal rule on any well-run SAP project.

A scalar UDF wraps repeated calculation logic behind a named function so it isn't copy-pasted across every query that needs it, and it can encapsulate branching logic a plain expression can't cleanly express.

CREATE FUNCTION calc_discount_price(
 price DECIMAL(15,2), discount_pct DECIMAL(5,2)
) RETURNS final_price DECIMAL(15,2)
LANGUAGE SQLSCRIPT AS
BEGIN
 final_price := price * (1 - discount_pct / 100);
END;

A calculation view is HANA's modeling layer object, built graphically or in SQLScript, that can combine joins, unions, aggregations, and even procedural logic into a single reusable data source, with HANA's optimizer able to push much of that logic down close to the data instead of materializing intermediate results. A plain database view is closer to a stored, named SQL query with no modeling metadata attached, no defined measures or hierarchies the way a calculation view exposes to reporting tools.

A standard GRANT controls whether a user or role can access an object at all, a table, a view, a procedure. An analytic privilege goes a level deeper for calculation views specifically, restricting which rows of data a user can see based on attribute values, a sales rep's role might be granted the view itself but restricted by an analytic privilege to only the rows for their own sales region. That row-level restriction is enforced inside the database layer itself, not bolted on in application code, which matters because it can't be bypassed by a different client tool hitting the same view.

HANA Cloud is SAP-managed and elastic, memory and compute scale up or down on a subscription model without the customer owning physical infrastructure, and SAP handles patching and version upgrades on its own cadence. On-premise HANA gives a customer full control over sizing, patch timing, and backup strategy, but that control comes with the customer's own team owning capacity planning, something SAP historically got heavily involved in through its sizing and TDI (Tailored Datacenter Integration) guidance because undersized HANA hardware is a common cause of production performance incidents.

Fiori Elements covers the common floorplans well, list-detail, worklist, object pages, and is the faster path whenever the app's requirements fit one of those templates without heavy custom interaction. Freestyle SAPUI5 earns its extra development cost when the UI genuinely needs something the templates don't support, a custom visualization, a non-standard multi-step wizard, or heavy client-side logic that doesn't map cleanly onto an annotated OData model. Reaching for freestyle by default, out of familiarity rather than actual requirements, is a common way Fiori projects end up costing more to build and maintain than they needed to.

BTP is SAP's cloud platform for building extensions, integrations, and analytics that live alongside a customer's core S/4HANA system without being embedded directly inside it. It bundles application development services (Cloud Foundry, Kyma for Kubernetes-based workloads), integration tooling (SAP Integration Suite), and analytics (SAP Analytics Cloud) under one commercial and identity umbrella. For a customer trying to stay clean-core, BTP is the answer to "where does our custom logic actually live" once direct core modification is off the table.

Integration Suite is SAP's managed integration platform, prebuilt adapters, mapping tools, and monitoring for connecting SAP systems to each other and to third-party systems, without every team writing and maintaining its own custom middleware. A concrete case: a company running S/4HANA alongside a non-SAP e-commerce platform needs order data flowing both directions reliably, with retry logic and monitoring if a message fails. Building that as a one-off custom interface means someone owns bespoke error handling and alerting forever. Routing it through Integration Suite gets standardized monitoring and retry behavior for free, at the cost of a subscription and a bit of platform-specific learning curve.

An idempotent operation produces the same end state whether it's executed once or retried multiple times after a failure, which matters because most integration middleware guarantees at-least-once delivery, not exactly-once, so retries after a timeout are a normal and expected part of operation, not an edge case. In an SAP landscape specifically, a lot of the target objects, sales orders, material documents, financial postings, have real business consequences if they get created twice by accident, a duplicate goods receipt or a duplicate invoice isn't a cosmetic bug, it's a financial discrepancy someone in accounting has to track down and reverse.

An in-app extension lives inside the S/4HANA system itself, using released extensibility tools like custom fields, custom CDS views, and key user extensibility, and stays in the same technology stack and lifecycle as the core system. A side-by-side extension runs on BTP as a separate application that calls into S/4HANA through APIs rather than living inside it. I'd reach for in-app when the requirement is a small, tightly-coupled adjustment to an existing transaction or field, and side-by-side when the requirement is a genuinely new application, a custom approval workflow with its own UI and its own data model that only needs to read or write a handful of S/4HANA objects.

A user submits the form in the Fiori app running in the browser, which sends an OData request to the gateway layer exposing a RAP-based business object. The gateway routes that request into the ABAP application server, where the behavior implementation runs validation logic, checks authorizations, and executes the create operation against the underlying database tables through Open SQL, with HANA handling the actual storage and any calculation views involved in follow-on checks like credit limit or availability. The response, success or a validation error, travels back up the same path to render in the UI.

Floyd's cycle detection, two pointers moving through the list at different speeds, one step at a time and two steps at a time. If there's a cycle, the faster pointer eventually laps the slower one and they meet at the same node. If there's no cycle, the faster pointer reaches the end first. It runs in O(n) time and O(1) space, which is the whole appeal over a hash-set approach that would also work but costs O(n) extra memory to track visited nodes.

Push every opening bracket onto a stack, and on every closing bracket, check that it matches whatever's on top of the stack. Any mismatch, or anything left on the stack at the end, means it's unbalanced.

function isBalanced(str) {
 const pairs = { ")": "(", "]": "[", "}": "{" };
 const stack = [];
 for (const ch of str) {
  if (ch === "(" || ch === "[" || ch === "{") {
   stack.push(ch);
  } else if (pairs[ch]) {
   if (stack.pop() !== pairs[ch]) return false;
  }
 }
 return stack.length === 0;
}

A naive nested loop comparing every row of one dataset against every row of the other runs in O(n*m) time. If the smaller dataset fits comfortably in memory, building a hash map keyed on the join column from that smaller side, then streaming through the larger dataset doing O(1) lookups against the hash map, brings that down to roughly O(n+m). This is exactly the shape of the tradeoff a database query optimizer is making at the implementation level when it picks a hash join over a nested loop join for a given query plan.

SAP's business runs on long-term customer relationships across implementation partners and enterprise accounts, so this question is really probing whether you can hold a technical position under commercial pressure without becoming inflexible or, in the other direction, just rolling over to keep a client happy. The strongest answers describe the actual tradeoff explicitly, what the customer wanted, what the risk of doing it that way was, and how the eventual decision got made, rather than framing it as a clean technical win.

The follow-up question matters more than the story itself here. Interviewers are listening for a concrete, specific change in how you work afterward, a new habit, a different checkpoint you added, not a vague "I learned to communicate better." A candidate who can name one thing they changed and why it actually helped the next time comes across as someone who reflects on failure rather than just moving past it.

I'd route the sync through an integration layer, whether that's SAP Integration Suite or a general enterprise service bus, publishing customer change events from S/4HANA rather than having the CRM poll or query the ERP directly. That decouples the two systems' release cycles and gives one place to add a new consumer later, a data warehouse, an analytics tool, without touching either system's core code. I'd also design for idempotency from the start, since retries after a transient failure are guaranteed to happen eventually, and a customer record update applied twice shouldn't produce a different result than applying it once.

If nobody on the panel can clearly describe which team you'd actually land on or what that team ships, that's worth a direct follow-up question before you accept an offer. SAP's org structure spans dozens of product lines and a recruiter working a broad requisition sometimes can't answer that with precision, which is fine at the top of the funnel but is a real problem by the final round. Ask directly which cloud product or module the role sits under and what shipped in the last two quarters.

Clean core means keeping the standard S/4HANA system as close to SAP's shipped state as possible and pushing custom logic out to the side, onto SAP BTP, using released, stable extensibility APIs rather than direct modifications or even classic customer-namespace enhancements inside the core system. In practice that means a development team has to build a habit of checking whether a given extension point is officially released and supported before writing to it, and accepting that some things they could do with unrestricted core access simply aren't available the clean-core way, at least not yet.

The payoff SAP is selling is that cloud upgrades, which now happen multiple times a year instead of once every few years, stop being a multi-week regression-testing project for every customer.

RAP layers a behavior definition and behavior implementation on top of an existing CDS entity, giving that entity create, update, delete, and validation logic, not just read access. Before RAP, exposing a custom business object with full CRUD and business logic through OData meant hand-writing a lot of boilerplate service implementation code. RAP standardizes that into a behavior definition file, draft handling for save-as-you-go UIs, and generated OData service bindings, which is a large part of why SAP now points nearly all new Fiori app development toward RAP rather than the older service-implementation frameworks it replaced.

FOR ALL ENTRIES lets you select rows from a database table based on a driver internal table instead of a single WHERE condition, which ABAP translates roughly into a series of OR conditions or an IN clause internally. The classic mistake is not checking that the driver table is non-empty before the SELECT: if the driver internal table has zero rows, FOR ALL ENTRIES silently selects every row in the target table, ignoring the WHERE clause entirely, instead of returning an empty result the way you'd intuitively expect.

IF lt_driver IS NOT INITIAL.
 SELECT * FROM mara
  FOR ALL ENTRIES IN @lt_driver
  WHERE matnr = @lt_driver-matnr
  INTO TABLE @DATA(lt_result).
ENDIF.

Partition pruning means the database engine can skip scanning entire partitions of a table when a query's WHERE clause already excludes them based on the partitioning key, commonly a date range or a company code. For a table partitioned by fiscal year, a query filtered to the current year never touches the partitions holding five-year-old data, which turns what would be a full-table operation into one scoped to a fraction of the physical data. Getting the partitioning key wrong, picking a column that doesn't align with how queries actually filter, means paying the storage and maintenance overhead of partitioning without getting any of the pruning benefit back.

First, whether the query's WHERE clause still aligns with how the table is partitioned or indexed, since a filter pattern that changed slightly (a new date range, a new company code being queried) can silently stop pruning partitions it used to prune cleanly. Second, whether the query plan shows an unexpected full table scan or a join order that changed as the underlying table statistics shifted with volume. Third, whether the report itself is doing row-by-row processing in application code (a loop calling out to the database per record) that used to be fast at low volume and now scales linearly with a much bigger row count. I'd pull the actual execution plan before guessing, since the fix is completely different depending on which of those three it turns out to be.

First, whether the OData service is fetching more columns or rows than the UI actually displays, a common mistake is exposing the full entity instead of a projection scoped to what the list view needs. Second, whether server-side paging is actually configured and being respected, versus the app pulling the entire result set client-side and paginating in the browser. Third, whether the underlying CDS view or database query behind that OData service has the aggregation and filtering pushed down to HANA, or whether it's pulling raw rows up into the application layer and filtering there, which defeats most of the point of running on an in-memory column store in the first place.

I'd break the job into chunks processed in parallel background work processes rather than one long sequential run, using SAP's own parallel processing framework (RFC-based parallel processing or, on newer stacks, background job chaining) so a failure in one chunk doesn't require restarting the whole batch from zero. I'd schedule it entirely inside the maintenance window and add explicit checks that abort the job cleanly if it's still running past a defined cutoff, rather than letting it bleed into business hours and start competing for the same database resources as live transactions. Logging progress per chunk, not just success or failure of the whole job, is what actually lets someone resume from a partial failure instead of rerunning everything.

Stream through the data once, maintaining a hash map of counts, then use a fixed-size min-heap of size three to track the running top three without ever sorting the full count map. Every time a new count exceeds the smallest count in the heap, pop the smallest and push the new one. That keeps memory bounded by the number of distinct items being counted, not the total row count, which is the part that matters most once "large" means tens of millions of rows arriving as a stream rather than a dataset that comfortably fits in memory.

This comes up constantly at SAP because a huge share of the company's actual revenue runs through customers on systems that are, in some cases, decades old, and plenty of internal work involves supporting that installed base rather than greenfield development. A strong answer accepts the constraint honestly instead of arguing the constraint away, and focuses on what incremental improvement is realistically possible within it, hardening a fragile interface, documenting a poorly understood process, rather than treating every legacy touchpoint as a fight to modernize it immediately.