SAP ABAP Interview Questions for Developers and Consultants

Hiring manager: “Custom report used to finish in two minutes. Now it’s twenty. Where do you start?”

You’ve fixed slow ALV reports. Naming the first three checks out loud is what they score. Selection. Nested SELECT loops. Whether the work belongs in the database. Not whether you remember every transaction code.

SAP ABAP interview questions for developers and consultants usually mix language basics, internal tables and Open SQL, ABAP on HANA and CDS, enhancement options (BAdIs especially), and a stakeholder scene where “just modify the standard” is the wrong first move. Sample answers below are illustrative. System IDs, tickets, runtimes: fictional. Steal the shape.

Behavioral shape: STAR method guide. Adjacent OO vocabulary sometimes shows up too: Java interview questions for experienced developers.

What the interview feels like

Definitions. A small design (“how would you select and process…”). HANA-aware SQL or CDS. An enhancement choice. One story about go-live or an angry business user. Pure coding screens still happen. Consultant-leaning roles push requirements, transports, and talking to non-ABAP people without a jargon flood.

Interview prep for ABAP work. Not a license to change productive systems without change control.

Basics, internal tables, Open SQL

1. Standard, sorted, hashed. How do you choose?

Standard for append-heavy work when keyed reads aren’t the point. Sorted when you read by key a lot and want binary search. Hashed when unique-key reads dominate. Measure the access pattern. Defaulting everything to standard and shrugging at a slow loop is a weak answer.

2. Open SQL. What do you watch?

ABAP-layer SQL the kernel maps to the DB. Smells: SELECT in a loop, missing WHERE, SELECT *, stuffing huge sets into memory, joining when a buffered read or CDS view would do. Prefer the fields you need. Say when aggregation belongs in the database instead of an ABAP loop.

3. Work area vs header line.

Explicit work areas (or field-symbols / inline declarations). Header lines hide body vs header and make reviews painful. New code: skip header lines.

4. Dump you only see in prod.

Read the short dump. Exception, stack, variables. Reproduce the variant in QA if you can. Check recent transports, data volume, auth. Guard the path. Don’t “fix” by editing prod.

5. Forms, function modules, methods.

New work in classes and methods. Function modules still wrap RFC and classic APIs. Forms are legacy. Wrap old includes gradually. Big-bang rewrites mid-project are how releases slip.

ABAP on HANA and CDS

6. What actually changes on HANA?

Push filters, aggregations, and set work into the database. CDS views (and table functions when needed) become the reuse contract. Code-to-data. You still write ABAP for orchestration, UI, process logic.

7. CDS basics they expect.

DDL views on the ABAP stack. Annotations where the UI or analytics stack needs them. Associations. Cleaner shops layer interface vs consumption views. Auth annotations matter. Sketch a thin interface view and a consumption view on top. One mega-view is a smell.

8. When CDS is the wrong tool.

Heavy procedural logic. Stateful processing. One-off admin scripts. Or a team with no transport/test lifecycle for CDS. Narrow Open SQL in a method can still be right.

9. AMDP, one breath.

ABAP-visible methods implemented as DB procedures (often SQLScript on HANA). Use when set-based logic truly belongs in the DB and CDS isn’t enough. Don’t use AMDP to look modern.

Say where the work runs: ABAP loop or database. That sentence alone cleans up a lot of fuzzy answers.

Upgrade-safe extension beats a clever modification you’ll own forever.

Enhancements and BAdIs

10. Modification vs enhancement.

Modification changes SAP standard. You own the upgrade fight. Enhancements (BAdIs, points/sections, explicit spots) hook in at defined places. Prefer enhancement. Modification only with eyes open and an exit plan on paper.

11. What is a BAdI?

OO add-in: defining interface, implementing classes. Find it from the call in standard code, docs, or your landscape’s search tools. Single-use vs multiple-use changes how many active implementations you get.

12. User exit vs BAdI.

Classic exits still exist. BAdIs are the modern OO route. Many landscapes have both. Implement what’s in front of you. Test in isolation.

13. Transport mistakes you avoid.

Partial transports that leave a class without its interface. Hardcoded system IDs. Mixing config and workbench with no release plan. Package checks. Smoke test in QA with the business variant that failed last time.

Stakeholder scenarios

14. Finance wants a field on a standard screen by Friday. “Just modify it.”

Restate the need: which process, which users, display vs edit, audit. Offer: existing field, custom field with enhancement, or BAdI/screen exit if one exists. Flag upgrade risk if they insist on a modification. Give a real estimate. “No” with no option sounds rigid. “Yes” with no risk sounds naive.

15. Custom interface posts duplicates after a network blip.

Idempotency key or document check before post. Correlation IDs in the log. Safe replay. For the stakeholder: “we’ll block duplicates and show which ones already posted.” Not a dump of RFC traces. Fix code and monitoring. Short write-up for night shift.

Fictional STAR for the behavioral follow-up. Shape only.

A plant report for open production orders slowed from minutes to half an hour after a go-live wave. Business blamed “HANA.” I traced nested SELECTs inside a loop over orders, replaced the inner reads with one joined selection (later a CDS view for reuse), and cut the same variant to under three minutes. Habit that stuck: performance stories start with the access plan, not a bigger app server.

More on shaping stories: STAR method interview questions and examples.

Stakeholder answers need a risk, an option, and a time box. Jargon alone doesn’t calm anyone.

Mistakes that sink it

SELECT-in-a-loop with a shrug. “I’d modify standard” as plan A. CDS buzzwords with no layering or auth. Debugging by changing prod. Behavioral answers that never say what you did.

Slow report on the table? Narrate: variant, row counts, SQL-trace mindset, redesign. Empty boxes on paper are fine.

Practicing with OfferBull

Help Portal pages help. Saying the slow-report opener while someone asks “what if it’s already on HANA?” helps more.

OfferBull is an AI mock interview app for iOS and Android. An interviewer voice asks questions out loud and you answer by speaking. Paste an SAP ABAP or consultant job description, or upload your resume, and the questions follow that role. It asks follow-ups based on what you said and what’s on your resume. During practice it can show answer suggestions and STAR structures when a story starts wandering. English and Chinese.

Prep tool. Not something you use in the real interview.

Start an AI mock interview

FAQ

Need S/4HANA project experience? Helps. Clear Open SQL, internal tables, and an honest HANA/CDS answer still carry a lot of mid-level rounds.

Consultant vs pure developer? More stakeholder and process for consultant tracks. Deeper code and performance for developer tracks. Plenty of roles blend both.

Classical reports and ALV? Often yes in maintenance-heavy shops. Selection screens, ALV basics, why heavy logic shouldn’t live in the UI layer.

Scenario length? Ninety seconds to two minutes first pass. Risk, option, next check. Stop.

---

Practice This Out Loud

Tonight: the twenty-minute report opener in under two minutes. First checks, what you’d move to the database, how you’d prove it in QA. Then the “modify standard by Friday” pushback once. Steady? Try a voice mock that asks follow-ups. → Practice Now