What Actually Comes Up in SAP CRM Technical Interviews
SAP CRM technical interviews aren't as clean-cut as the standard ABAP questions you find on any preparation site. The people running them usually have dealt with real production messes, and they want to know whether you can navigate them. I've sat on both sides of these interviews over the years, and the pattern is pretty consistent once you stop treating it like a certification exam. The core technical areas that come up repeatedly break down into a few buckets. You need to understand the architecture before you touch any code. SAP CRM runs on the NetWeaver stack, which means the underlying foundations are ABAP-based, but the customer-facing layers pull in a lot of Java and web technologies. Interviewers expect you to know which piece lives where. The Business Partner model is one of those topics that sounds straightforward until you're asked to explain how BP relationships work in a multi-country deployment. I remember a candidate who couldn't articulate the difference between the BP role types and the classification attributes. That's an immediate red flag for anyone who has actually configured BP scenarios in production.
BOL, or Business Object Layer, is another area where most candidates give textbook answers but crumble under follow-up questions. The BOL is the middleware between the database and the UI, and understanding it means knowing how context nodes map to business objects, how persistence works through the BOL proxy layer, and why certain operations fail silently when you don't understand the transaction handling underneath. I once had to debug a situation where a custom Z-extension was writing directly to CRMD_ORDER and bypassing the BOL completely. The data looked correct in the database but never appeared in the UI because the context wasn't refreshed. This happened because the developer didn't understand that the BOL caches data per session and requires explicit reloads after direct writes. WebUI development is where the interview questions get practical. You'll be asked about BSP pages versus WebUI components, when to use each, and how they interact. The counter-intuitive part most people miss is that BSP isn't deprecated in SAP CRM — it's still very much in use, especially for legacy custom developments. The migration path from BSP to WebUI is something you should understand cold, because every company doing an upgrade will face this decision. For WebUI specifically, know the controller hierarchy inside out. View controllers, page controllers, window controllers, component controllers — the difference between them matters when you're asked about event propagation. A common pitfall is confusing the GET_P method with the SET_P method in a value help scenario. They serve different purposes and mixing them up in a live discussion is noticeable.
Gateway and OData services have become a major focus in recent years. You need to understand how the DPC_EXT and MPC_EXT classes work together, how to implement CRUD operations in the service implementation, and what the performance implications are of eager versus lazy loading in entity sets. I've seen interviews where the candidate could write a basic OData service but couldn't explain how to handle batch operations efficiently. In production, batch requests can make or break your UI performance, so this isn't academic. Workflow is another area where theoretical knowledge falls apart under pressure. SAP CRM workflow uses the SWF tools and integrates with the CRMD_WORKITEM table. Understanding when to use workflow versus simple BAdIs versus user exits is important. I worked on a project where we replaced a complex custom workflow with a straightforward BAdI implementation because the workflow was causing lock conflicts during peak sales periods. The interviewer who asked me about that experience later wanted to know exactly how the lock situation manifested and what metrics proved the change was necessary. Integration scenarios come up frequently because SAP CRM rarely sits alone. IDocs, XI/PI middleware, RFC calls, SOAP services — you need to know which integration method fits which scenario. A good rule of thumb that interviews test is whether you understand the difference between synchronous and asynchronous integration patterns and when to choose each one. The mistake most juniors make is recommending RFC for everything because it's simpler to set up, when in reality IDoc-based integration is far more appropriate for high-volume order processing.
Get the Full Details
Customizing versus coding is a topic that separates the developers from the consultants. Interviewers love to ask whether a requirement should be solved through configuration or through ABAP development. The answer is rarely obvious and depends on factors like upgrade safety, performance requirements, and existing standard functionality. I've seen good developers waste days building custom solutions when a standard SAP CRM business function or a simple BAdI implementation would have done the job in an afternoon. Performance tuning questions are almost guaranteed if the interviewer has operational experience. Understanding how to read STAD and SAT traces, how to analyze SQL traces for slow queries, and how to identify N+1 query problems in your BO code is essential. One thing beginners consistently overlook is that the CRM search help infrastructure uses separate indexes, and querying against non-indexed fields in custom search helps can bring down response times from milliseconds to seconds. Security and authorization deserve attention too. SAP CRM has its own authorization objects beyond the standard SU24 framework. Knowing the difference between P_ORG fields in sales documents and the actual authorization checks that run during document display is something people who haven't debugged auth issues in CRM find surprisingly difficult to explain clearly.
Testing approaches are worth mentioning because the interview often shifts to how you validate your work. SAP CRM's testing landscape includes local testing through transaction codes, unit tests with the ABAP Test Framework, and integration tests that span across systems. The practical reality is that most teams skip proper unit testing in CRM projects due to timeline pressure, which is a habit that causes problems during support phases. Interviewers who've managed teams long enough to see those support tickets will appreciate hearing that you acknowledge this gap and have strategies for mitigating it. Upgrade considerations round out the technical discussion. SAP CRM versions have shifted significantly over the years, and movement from 7.0 to 7.01, then to ERP 2007 and beyond, introduced architectural changes that broke existing custom code. Understanding what changed in the WebUI framework between versions and how to approach a code remediation exercise is a senior-level expectation. The specific issue with context node renaming during upgrades is one I've dealt with multiple times — standard code that referenced a context node by hardcoded string would suddenly break after an upgrade when the node name changed in the enhanced component. For anyone preparing, the most effective approach isn't memorizing answers to expected questions. It's working through real scenarios and being able to explain your reasoning out loud. Interviewers can tell when you've rehearsed a script versus when you've actually built and maintained CRM systems. Pick a recent project, walk through the technical decisions you made, and be ready to defend them with specifics about what you tried, what failed, and what you changed.
