Introduction
After 3 years in ABAP development, you may feel confident writing reports, classes, and BAPIs but interviews still catch you off guard. Recruiters at this level expect you to explain not just what you did, but why you chose a particular ALV type, modularization strategy, enhancement framework, or RFC handling approach. Generic answers that work for freshers will not work
Why This Happens
Most candidates with 3 years of experience fail mid-level ABAP interviews for one reason: they prepare like freshers. They revise syntax, memorize transaction codes, and recite definitions but interviewers at this level are testing decision-making, not recall.
A senior developer asking you about modularization does not want to hear “FORM routines, function modules, and classes.” They want to know: In your last project, when did you choose a function module over a class method, and why? What were the trade-offs? That kind of contextual reasoning is what separates a 3-year developer from a fresher on paper.
Common gaps at this level include:
- Knowing how BAdIs work, but not knowing when to use a classic BAdI versus an enhancement spot versus an implicit enhancement
- Understanding OOP syntax, but not being able to explain real design decisions made using it
- Giving ECC-only answers in S/4HANA-context roles — for example, describing BSEG queries without mentioning ACDOCA
- Discussing ALV without covering event handling, layout variants, or print scenarios
- No awareness of performance impact: missing the difference between SORTED TABLE with binary search versus STANDARD TABLE with linear search in a loop of 100,000 rows
The fix is structured preparation that goes one level deeper than a fresher guide—practical reasoning backed by project context
Step-by-Step Preparation Strategy
1. Categorize your questions by depth, not just topic
At 3 years of experience, you need three layers per topic:
- Definition — what it is
- Decision — when and why you use it over alternatives
- Project example — a real scenario where you applied it
2. Map release-specific behaviour explicitly
For every major topic, know the ECC 6.0 behaviour and the S/4HANA 2022 difference. This demonstrates that you have worked across releases or have actively kept pace with the platform shift. Key areas: data model (BSEG vs ACDOCA), Open SQL syntax (old vs new with inline declarations), ALV (classic FM vs CL_SALV_TABLE), and reporting (ABAP reports vs CDS-based Fiori tiles).
3. Prepare scenario-based reasoning for each answer
Practice answering every question using the structure: concept → decision logic → project scenario. For example, on BAdIs: explain what a BAdI is, explain when you choose it over a user exit, and then describe the specific SAP standard program you enhanced in your project and why a BAdI was the appropriate tool.
4. Cover the topics freshers skip
Performance tuning, enhancement frameworks, OOP design patterns, debugging production issues, and cross-module integration are rarely covered in fresher guides. These are exactly what 3-year interviews focus on.
5. Validate in a sandbox before the interview
Run small test scenarios for every concept you plan to discuss. Interviewers at this level will ask follow-up questions. If you have not run the scenario yourself, the follow-ups will expose you.
Top ABAP Interview Questions for 3 Years of Experience
Q1. What is the difference between an abstract class and an interface in ABAP OOP?
Answer:
An abstract class is a class that cannot be instantiated directly — it provides a partial implementation that subclasses must complete. It can contain both implemented methods (with logic) and abstract methods (declared but not implemented). An interface, by contrast, is a pure contract: it declares method signatures with no implementation at all, and any class that implements it must provide all method bodies.
The key decision point: use an abstract class when you have shared logic that all subclasses should inherit, for example, a common log_message method that every output handler uses, regardless of whether it writes to spool, ALV, or a file. Use an interface when you want to enforce a contract across unrelated classes — for example, if a payment processor, a delivery handler, and a notification service all need to implement execute_process, but they share no common logic.
In S/4HANA, interfaces are heavily used in the RESTful ABAP Programming (RAP) model. Behaviour definitions are essentially interface contracts that handler classes implement. At 3 years of experience, being able to articulate this design distinction clearly signals architectural thinking.
ECC vs S/4HANA: The language constructs are the same in both releases. The difference is usage pattern: S/4HANA development (especially RAP) relies almost entirely on interfaces; ECC projects more commonly use abstract classes for shared utility logic
Q2. Explain inheritance vs composition in ABAP. Which do you prefer and why?
Answer:
The subclass inherits the attributes and methods of the superclass, and this is inheritance. Behavior can be extended or modified by redefinition in the subclass. Composition is a class that contains a reference to a class as an attribute but does not inherit it.
The old rule of software engineering applies: use composition instead of inheritance for the relationship “has-a” instead of “is-a. However, developers new to OOP are prone to using inheritance in ABAP projects excessively. The problem becomes apparent when the inheritance chain lengthens: subclasses are tightly coupled with the internals of the superclass and if the superclass changes, all subclasses are broken in a way that is difficult to predict.
Inheritance example: If you have a class named zcl_report_output, and you need to make a class that also sends an email, then you make zcl_report_output_with_email.
For interviews, state your preference clearly and back it with a reason. Saying “it depends” without elaborating is a weak answer at this level. What Senior SAP Employers Actually Ask.
Q3. What is method redefinition in ABAP, and what are its risks?
Answer:
Method redefinition allows a subclass to provide its own implementation of a method defined in the superclass. The subclass method replaces the superclass behaviour for instances of the subclass type. The REDEFINITION keyword in the subclass definition signals this.
The risks are real and worth mentioning in an interview:
First, if the superclass method has side effects that callers depend on (modifying shared state, writing to a log), a redefined subclass method that omits those side effects silently breaks behavior. This is the Liskov Substitution Principle violation the subclass should be substitutable for the superclass without changing program correctness.
Second, calling super->method_name( ) inside a redefined method is easy to forget. If the superclass method has critical setup logic and the subclass skips it, runtime errors or incorrect data follow.
Third, in large teams, redefined methods are harder to trace during debugging because the runtime dispatches to the subclass implementation, which is not always obvious when reading the calling code.
Best practice: always document why a method is being redefined, and call super-> unless there is a specific reason not to
Q4. What is a factory method pattern, and have you used it in ABAP?
Answer:
The Factory Method pattern is a creational design pattern where object creation is delegated to a dedicated method (or class) rather than handled directly by the caller with CREATE OBJECT or NEW. The caller asks the factory for an instance without knowing or specifying the exact class that will be instantiated.
In ABAP, this pattern is implemented by defining a static method (commonly called get_instance or create) that returns a reference typed to an interface or abstract class. The factory method internally decides which concrete class to instantiate based on parameters.
A typical use case: an output handler factory that receives a medium type (ALV, spool, email) and returns the appropriate handler object. The caller works only against the interface, unaware of whether it is holding an ALV handler or an email handler. Adding a new output medium means adding a new class and updating the factory method — all existing callers remain unchanged.
This pattern appears frequently in S/4HANA RAP handler classes and in SAP’s own framework code (for example, CL_SALV_TABLE=>FACTORY is itself an implementation of this pattern). Recognizing and naming it in an interview signals maturity beyond basic OOP knowledge.
Q5. What is the performance difference between STANDARD TABLE, SORTED TABLE, and HASHED TABLE in ABAP?
Answer:
The choice of internal table type has direct performance implications, especially in programs processing large volumes — which is exactly the scenario a 3-year developer should have encountered.
STANDARD TABLE uses linear search by default — the runtime scans from the first row until it finds a match. For a table with 10,000 rows, a READ TABLE … WITH KEY performs up to 10,000 comparisons. Acceptable for small tables or tables accessed primarily via LOOP AT … WHERE. For binary search to work on a standard table, it must be sorted first, and BINARY SEARCH must be specified explicitly.
SORTED TABLE maintains rows in sorted order by the defined key at all times—inserts are placed in the correct position automatically. READ TABLE … WITH KEY on the primary key uses binary search automatically, giving O(log n) performance. The trade-off is a slightly higher cost on insert/append operations due to sort maintenance.
A HASHED TABLE stores rows using a hash function on the key, giving O(1) direct access — the fastest possible read performance for single-key lookups. The restriction: it can only be accessed by full primary key, not by partial key or with WHERE conditions.
Rule of thumb from practice: use a HASH TABLE when you build a lookup table once and read from it many times in a loop (replacing a SELECT SINGLE inside a loop). Use SORTED TABLE when you need a mix of range-based access and key access. Use the STANDARD TABLE for collections that are appended to and iterated rather than looked up.
ECC vs S/4HANA: The performance rules are the same. However, in S/4HANA, the HANA database is so fast for indexed reads that the choice of internal table type matters most for ABAP-layer processing, not for replacing database calls.
Q6. What is a secondary index in SAP and when would you create one?
Answer:
According to the ABAP Data Dictionary (SE11), a secondary index in SAP is an extra database index on a transparent table that goes beyond the primary key index. It is used by the database engine to expedite queries that sort or filter on non-key fields.
When to make one: when there are many rows in the table, and a SELECT statement with a WHERE clause on non-key fields executes slowly. The typical diagnostic procedure is to run the program with ST05 SQL Trace enabled, find the costly SELECT statement, examine its execution strategy, and verify that a complete table scan is being carried out. Next, see if the WHERE fields are covered by an existing index.
In S/4HANA, many classic performance problems solved by secondary indexes in ECC are instead solved by reading from CDS views that push calculation to HANA’s column-store engine, which handles large analytical queries differently from row-based databases.
Q7. What is the difference between a user exit, a customer exit, a BAdI, and an enhancement spot?
Answer:
This is one of the most important questions for a 3-year developer because the enhancement framework has evolved through multiple generations, and knowing when to use which tool—and why—is a clear differentiator.
User Exit (USEREXIT_*): The oldest enhancement type. SAP provides empty FORM routines inside standard programs, prefixed with USEREXIT_. You add your code to these routines in an include program. Limitations: only one implementation possible per exit, no object-oriented support, upgrade-risky because you modify SAP includes directly. Found mainly in SD and older module programs.
Customer Exit (SMOD/CMOD): A more structured version. SAP defines exit components (function module exits, menu exits, screen exits) in an enhancement (SMOD). You implement them via a Project (CMOD). Still procedural, still one implementation only, but less risky than direct include modification because SAP clearly defines the exit boundaries.
Classic BAdI (SE18/SE19 — pre-EHP): Object-oriented. SAP defines a BAdI interface; you create an implementation class. Multiple implementations can be active simultaneously (filtered by parameters). Upgrade-safe because your code is in a separate class, not in SAP’s code. A significant improvement over customer exits.
New BAdI / Enhancement Spot (SE18 — EHP1 onward): The current standard. Enhancement Spots group multiple BAdIs. New BAdIs support additional filter types, fallback classes, and can be used in S/4HANA cloud. In S/4HANA on-premise, always use Enhancement Spots with New BAdIs unless the SAP standard only offers a classic BAdI.
Implicit Enhancement: A raw code injection point at the beginning or end of any function module, method, or program block. No SAP-defined interface — you inject any code. Highest flexibility, highest risk. Use as a last resort when no explicit BAdI or exit exists.
Q8. What is an implicit enhancement, and what are the risks of using one in production?
Answer:
An implicit enhancement is a code injection point that SAP provides at the start and end of every function module, method, include, and program. Unlike BAdIs or customer exits, there is no SAP-defined interface you can insert any ABAP code directly into the execution flow of a standard program.
To use one: in SE80 or ADT, right-click at the beginning or end of a routine, select “Enhancement Operations → Create Enhancement”; and choose an implicit enhancement point or section.
The risks in production are significant:
No interface contract: Because there is no defined interface, you have direct access to all local variables of the standard routine at that point. This means your enhancement can read or modify internal SAP variables that are undocumented and subject to change in any support package or upgrade. An SP upgrade that renames or repurposes one of those variables silently breaks your enhancement.
No activation check on upgrade: Unlike BAdIs, implicit enhancements are not validated during system upgrades. They stay active and may execute with incorrect context post-upgrade.
Hard to find during troubleshooting: Implicit enhancements at the start of standard routines are invisible to developers reading the standard code. This makes debugging complex scenarios much harder — the enhancement’s effect appears as if the standard code itself behaved differently.
Best practice: use implicit enhancements only when no BAdI or customer exit exists for the required hook point, document them thoroughly, and include the program name, routine, and business reason in the enhancement description.
Q9. What is the difference between a source code plug-in (enhancement section) and a BAdI call? When does SAP prefer each?
Answer:
Both are mechanisms SAP uses to define enhancement options inside standard programs, but they serve different purposes and offer different capabilities.
Enhancement Section (source code plug-in): SAP wraps a block of standard code between ENHANCEMENT-SECTION and END-ENHANCEMENT-SECTION markers. Developers can insert custom code that executes at that point, or can even replace the standard code section using an enhancement implementation. This is powerful — you can entirely replace standard logic — but it is also risky for the same reasons as implicit enhancements: the code context changes with upgrades.
BAdI Call: SAP explicitly calls GET BADI and CALL BADI at defined points in the standard code. The BAdI interface is a published contract — SAP commits to maintaining it across upgrades. Developers implement the interface in a custom class without touching the standard code at all.
SAP prefers BAdIs for new enhancement options in S/4HANA and for any scenario where data needs to pass cleanly between the standard program and the custom implementation. Enhancement sections are used when the requirement is to modify the flow or logic of a standard code block rather than add parallel custom processing.
For a 3-year developer: always prefer BAdIs. Use enhancement sections only when a BAdI does not exist at the required location and the business requirement cannot be met otherwise.
Q10. How does pricing work in SD and where would you implement a custom pricing requirement in ABAP?
Answer:
Pricing in SD is condition-based and controlled by the Pricing Procedure (configured in SPRO). At runtime, the pricing engine reads condition records from condition tables (A-tables like A305, A304) and applies them in sequence to calculate the final price, discounts, taxes, and surcharges on a sales document.
The ABAP entry points for custom pricing requirements:
Condition formula (VOFM): For a requirement formula (controls whether a condition is applied at all) or a calculation formula (modifies how the condition value is calculated), you write a user routine in VOFM (transaction VOFM, Formulas → Pricing). These are FORM routines that the pricing engine calls during condition determination.
User exit for pricing: USEREXIT_PRICING_PREPARE_TKOMP and USEREXIT_PRICING_PREPARE_TKOMK allow you to populate custom fields in the pricing communication structures (TKOMP for item level, TKOMK for header level). These fields can then be used as access fields in condition table keys — enabling custom condition determination based on data not natively available in the standard pricing structures.
BAdI SD_CND_ACCESS: In newer releases and S/4HANA, this BAdI provides a cleaner, object-oriented hook into condition access logic.
In interviews, walk through the architecture: condition table → access sequence → pricing procedure. Showing you understand the full flow — not just the ABAP exit — demonstrates functional depth alongside technical skill.
- t enhancement” without explaining why a BAdI was not sufficient suggests you default to the riskiest option.
Conclusion
Preparing for ABAP interview questions at 3 years of experience requires a fundamentally different approach from fresher preparation. Interviewers at this level are not testing whether you know what a BAdI is they are testing whether you know when to use a BAdI over an enhancement spot, why you would choose one over the other in a given situation, and what the consequences of the wrong choice are in a production upgrade.
Master the OOP design concepts covered in this guide: not just the syntax, but the decision logic behind abstract classes vs interfaces, composition vs inheritance, and early vs late binding. Know your performance toolkit table type selection, FOR ALL ENTRIES pitfalls, parallel cursor technique, and secondary index strategy and connect each one to a real scenario from your project experience.
The developers who stand out in mid-level ABAP interviews are the ones who answer with specificity and reasoning. They say, “I chose a Classic BAdI because the standard program had no Enhancement Spot at that point, but I documented the implicit enhancement I used instead as a migration candidate for the next release.” That level of precision demonstrates project maturity enhancement spot and that is what this guide prepares you to deliver.
Frequently Asked Questions
1. What topics are most commonly tested for 3-year ABAP experience roles?
OOP design decisions (not just syntax), performance optimization (internal table types, FOR ALL ENTRIES pitfalls, secondary indexes), enhancement framework selection (BAdI vs exit hierarchy), ALV event handling, and ECC vs S/4HANA data model differences (especially BSEG vs ACDOCA) are the highest-frequency topics at this level.
2. How do I show 3 years of experience if my project only covered limited ABAP topics?
Focus depth over breadth. For every topic you did work on, prepare a layered answer: what you built, the design decisions you made, the challenges you encountered, and what you would do differently. One well-told project story is worth more than ten vague topic mentions.
3. How important is S/4HANA knowledge for ECC-only project developers?
Increasingly important. Many clients are planning or midway through S/4HANA migrations. Demonstrating awareness of what changes (ACDOCA, CDS views, new ABAP syntax, RAP) signals that you will not become a liability during migration. At a minimum, know the key data model differences and the shift in development tooling from SE80 to ADT.
4. What is the Clean ABAP guideline, and do interviewers test it? Clean ABAP is SAP’s official style guide for modern ABAP development (available on GitHub at github.com/SAP/styleguides). It covers naming conventions, method length, exception handling, OOP patterns, and test coverage. In S/4HANA-focused interviews, expect at least one question about it. Key points to know: methods should do one thing, names should be self-documenting, and no dead code or commented-out code.
5. What is the difference between an ABAP developer and a consultant at 3 years experience—and how does that affect interview preparation?
A developer role interview will focus heavily on technical depth: OOP, performance, enhancement implementation, and debugging. A consultant role interview will weight functional knowledge more heavily: understanding business process flows (order-to-cash, procure-to-pay), knowing which customizing tables drive which behaviour, and being able to discuss both the ABAP implementation and the functional configuration. For hybrid roles, prepare both tracks.
