Getting Ready for an Oracle EBS R12 Interview
I spent about eight years working on Oracle E-Business Suite implementations, mostly R12 upgrades and customizations. When I started hiring people for my team, I noticed most candidates had read a bunch of generic interview prep material but couldn't actually walk through a real scenario. That gap is what this is about.The landscape has shifted since R12.0 hit the market back in 2006. R12.1.1 added some critical patches that changed how we think about concurrent managers and workflow. R12.1.3 introduced the newer HRMS features that most interviewers now ask about. And if you're sitting in front of someone asking about R12.2.x or 12.2.8, that's a completely different conversation around Online Patching and ADOP. I'll cover the core R12 territory first. "Walk me through the concurrent request lifecycle." This seems straightforward until you realize most people describe the ideal path and freeze when you mention what happens if the listener crashes mid-request. A strong answer mentions the conflict domain, the fact that there are separate managers for different queues, and that you can check fnd_concurrent_requests and fnd_concurrent_processes to see where things are actually sitting. I once had a candidate who confidently described the lifecycle, then when I asked about a stuck request that wouldn't cancel even after killing the process, they drew a blank. The answer involves checking the state column, making sure it's not 'Hold' or 'Resuming', and sometimes you need to touch the database directly with a status update to fnd_concurrent_requests to unstick it. "Explain the difference between a value set and a cross-implementation value set." The basic answer is that a value set defines valid entries for a field, and a cross-implementation one allows multiple applications to share the same definition. But the nuance is in dependent value sets and how they interact with flexfields. I've seen production issues where a dependent value set wasn't updating correctly after a patch because the translation table was pointing to the wrong segment. The workaround is to verify fnd_flex_value_sets and fnd_flex_values along with the segment table alignment.
"How do you debug a profile option that isn't taking effect?" Most people say "check the site, responsibility, application, and user levels." That's correct but incomplete. The actual debugging path involves checking v_profile_option_values in sequence, and more importantly, understanding that some profiles are application-specific and won't show up at the site level. I ran into a case once where a profile was set correctly at the user level but still wasn't working because the application developer hadn't registered it as a user-modifiable option in fnd_profile_options. The fix was to check the user_enable_flag column.
Technical Depth: What Separates Juniors from Seniors
Oracle Apps R12 has enough moving parts that interviewers can go pretty deep. Here's where most candidates start struggling. Flexfield customization: This is the bread and butter of R12 work. Descriptive flexfields (DFF) and key flexfields (KFF) have different implementation paths. DFF uses fnd_desc_flex_fields and fnd_desc_flex_fields_usages. KFF uses fnd_id_flex_structures. The trick is that security is controlled through fnd_id_flexs and the segment combination rules are in fnd_flex_value_sets. I remember one project where a KFF segment wasn't showing up in a custom form because the structure assignment was only at the organization level, not at the transaction type level. The resolution required updating fnd_id_flex_structures with the correct context value. Concurrent program parameters: Most people understand how to define a parameter, but few know about the special handling of LOV parameters and how they interact with value sets. There's a known issue in R12.1.0 where a parameter with a large LOV could cause the concurrent manager to run out of memory during compilation. The workaround is to break the LOV into smaller value set fragments and use the cache flag appropriately. I've found that checking fnd_concurrent_programs and fnd_concurrent_programs_tl gives you the full parameter definition along with the event handler registration.
Get the Full Details
Workflow and OEAM: Oracle Workflow is its own beast. The interviewers love to ask about workflow items, processes, and activities. The key tables are wf_items, wf_processes, and wf_activities. But the advanced part is understanding how workflow engines interact with the concurrent manager and how to debug a stuck workflow using wf_blocking_entities. I encountered a case where a workflow item was stuck in 'Error' state because the notification mailer wasn't configured correctly. The fix involved checking the wf_notifications table and verifying the assigned_user against fnd_user.
Pitfalls That Trip Up Even Experienced People
There are several areas where intuition fails and people make mistakes, even those who've been working with R12 for years. Multithreaded Concurrent Manager (MTCM): Introduced in R12.1.1, MTCM changed how we think about concurrent processing. Most interview guides mention it briefly, but very few people understand the actual behavior under load. The issue is that MTCM uses worker processes rather than threads, and the configuration in adcm_control determines how many workers to spawn. I've seen production problems where MTCM was misconfigured, causing concurrent requests to queue unnecessarily. The troubleshooting path involves checking fnd_concurrent_worker_requests and the actual worker state. Online Patching (R12.2.x): If you're interviewing for an R12.2 role, Online Patching is the elephant in the room. ADOP (AutoPatch online patching) has its own lifecycle: prepare, apply, finalize, abort. Most people memorize the steps but don't understand what happens to the database during each phase. I've seen interviewers push hard on what occurs to ad_patch_drivers and ad_bugs during a failed patch cycle. The honest answer is that ADOP creates a new patch filesystem and uses edition-based redefinition, but if you've never actually run adop phase=apply on a large instance, you might not know about the cutover delay issues that can occur with certain tables.
Customization vs. Standard: This is the philosophical question that reveals whether someone actually understands the product. The standard advice is "never customize what you can configure." But the reality is more nuanced. There are cases where a customization using PL/SQL packages in the AR, AP, or GL modules is actually cleaner than fighting with OAF pages. I personally encountered a situation where the standard R12.1.3 HRMS fast formula couldn't handle a client-specific calculation, and a custom PL/SQL function in the fnd_function table was the only practical solution. The trade-off is upgrade pain versus development time.
What I'd Actually Ask in an Interview
If I were conducting an Apps R12 technical interview, I'd skip the rote questions and focus on scenarios that reveal how someone thinks. Here's a realistic problem I posed to a candidate last year: A client reported that a specific concurrent program runs successfully in the test environment but hangs in production. The program is a custom PL/SQL package that calls three standard R12 APIs. The candidate immediately asked about the environment differences, which is the right instinct. Then we walked through checking fnd_concurrent_requests for the session_id, verifying the database link connectivity, and examining the awr report for lock waits. The root cause turned out to be a missing index on a custom table that happened to be small enough in test to not matter. This type of question reveals more about a candidate's debugging approach than any definition-based question ever could. I also like to ask about the migration path from R11.5.10.2 to R12. Most people recite the upgrade steps from the metalink note. What I'm actually looking for is whether they mention the database version requirements (10.2.0.4 minimum for R12, 11.2 for R12.1.1), the mandatory pre-upgrade checks in fnd_install, and the fact that some customizations break during the upgrade because of tablespace changes. I learned this the hard way on a migration where a custom form referencing fnd_flex_value_sets directly broke after the upgrade because the table was partitioned differently.
Resources Beyond the Generic Prep Lists
The internet is full of Apps R12 interview questions lists, most of which are recycled from forums with little accuracy. Here's what I actually recommend. Oracle's official documentation at docs.oracle.com is starting point, but the real knowledge lives in the MOS notes. Note 1320898.1 covers R12.1.3 known issues. Note 454997.1 explains the concurrent manager architecture in depth. For customization patterns, the Oracle E-Business Suite Developer's Guide (the one that actually came with the forms builder) is still relevant even though it's old. I also suggest setting up a local R12.1.3 instance using the VM images Oracle used to distribute. Nothing beats hands-on experience with fnd_concurrent_requests, adcm_control, and the actual forms builder. I've found that candidates who've actually created a custom concurrent program in a sandbox environment can discuss the nuances much more naturally than those who've only read about it.
The bottom line is that Apps R12 interview questions have evolved. The product has too many layers for surface-level answers to work anymore. Whether you're the interviewer or the interviewee, the conversations that matter are the ones that dig into how the system actually behaves under real conditions.
