Interview patterns for technical MDG
Four question types, one answer structure (clarify, draw, name, risks, result), worked example answers, and STAR stories built from your real projects.
The four question types
Scenario tests end-to-end system behaviour. Design tests trade-offs. Debug tests methodical investigation. AI tests using new tools without breaking governance. Prepare two answers per type: one from real projects, one from the course. Behavioural questions get STAR stories.
Sort these interview questions by type.
One structure for every technical answer
Same five moves every time. It keeps you calm, shows seniority and gives natural points for follow-ups. On video, draw boxes on paper and hold it up.
Put the five moves of a technical answer in order.
- 1Clarify: ask about landscape, entity and volumes
- 2Risks: what could go wrong and how you'd check
- 3Name: CR type, BAdI, DRF model, transactions
- 4Result: close with an outcome or metric
- 5Draw: sketch the flow as boxes and arrows
Worked example: scenario
'A supplier CR was approved but never reached ECC.' Clarify: hub, IDoc, one CR? Then walk the path: is the CR finally activated? Did DRF select it (DRFLOG)? Replicate manually (DRFOUT), follow the IDoc (WE02), read SLG1. Risks: DRF filter, missing key or value mapping, manual replication mode; never resend blindly in production. Result: a checklist like this kept your issue rate below 5%.
Worked example: design
'Design supplier onboarding that prevents duplicates.' Clarify volumes, requesters and receivers. Name: a dedicated CR type with rule-based workflow, the MDG duplicate check at create, BRFplus for simple field rules, a BAdI for harder checks, DRF with key and value mapping. Risks: an over-strict check annoys requesters; small suppliers may lack tax numbers. Result: duplicate rate and CR cycle time before and after.
Worked example: debug
'The receiver has duplicate business partners after go-live.' Clarify: created by replication, or migrated? Test hypotheses in order of likelihood, each with evidence. Fix through MDG, never directly in the receiver, or the next replication brings them back. Result: a root-cause note plus prevention (duplicate check at create, or consolidation for the backlog).
" Quick check: tax numbers used by more than one Business Partner
SELECT taxtype, taxnum, COUNT(*) AS bp_count
FROM dfkkbptaxnum
GROUP BY taxtype, taxnum
HAVING COUNT(*) > 1
INTO TABLE @DATA(lt_dupes).
cl_demo_output=>display( lt_dupes ).Run in a sandbox or with read access. It answers hypothesis 1 in seconds.
Worked example: AI
'Where would you use AI in MDG, and where not?' Clarify: SAP's own features or side-by-side services, and data restrictions. Risks: hallucinated reasons, data leaving the landscape, silent prompt changes. Controls: validated structured output, logged model and prompt version, data minimisation, acceptance-rate tracking. Result: point to the capstone.
The interviewer says: 'Design supplier onboarding that prevents duplicates.' How do you open?
STAR stories from your real projects
Situation, Task, Action, Result. About two minutes each, most time on Action, end with a number. Prepare four or five and map each to the questions it answers. Share only industry and scale, not confidential client details.
Remember
- Most technical MDG questions are scenario, design, debug or AI.
- Clarify, draw, name, risks, result: the same five moves every time.
- Prepare five STAR stories from real projects, each ending in a number.