Use this guide to prepare for Enterprise Platform Consultant interviews, with a focus on jwt, unit testing, oauth. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
JWT
Unit testing
OAuth
Scripting
Platform strategy
CORS
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Mid-level
1. What does verifying a JWT require beyond decoding its payload?
Answer guide
Decoding just base64 reads the payload; anyone can forge those bytes. Verification means checking the signature with a key you trust and an algorithm you have allowed, never one the token itself dictates. Then validate the claims your service depends on: issuer, audience, expiry, not-before and any scope or role you rely on, allowing only a small clock skew. Tokens also need transport over TLS and careful storage. A good habit is to write a negative test with an expired token and one signed by the wrong key.
What this question explores
Whether you know that a JWT is only trustworthy after signature and claim validation, and understand the classic algorithm pitfalls.
Common mistakes
They decode the payload and trust its contents, treating a readable token as a verified one.
They accept whichever algorithm the token header names, including none, instead of enforcing an allow list.
Practise a follow-up
Why is accepting the algorithm from the token header dangerous?
How would you handle revocation for a token that is valid for an hour?
2. What makes a useful unit test for a function with edge cases?
Answer guide
A useful test states a behaviour in terms of input and observable output, not how the code reaches it. For a function with edge cases, cover a normal value, each boundary such as zero, empty or the maximum, and the error path, giving each test a name that describes the case. Replace clocks, files or network calls with controlled fakes so the result is deterministic. Avoid re-implementing the function in the assertion, since a test that repeats the logic will repeat its bug. When a test fails, it should point straight to the broken rule.
What this question explores
Whether you write tests that describe behaviour, cover boundaries and stay deterministic, rather than mirroring the implementation.
Common mistakes
They only test the happy path with one typical value and consider the function covered.
They compute the expected value with the same logic as the code, so the test can never fail meaningfully.
Practise a follow-up
How would you test a function that depends on the current time?
What is the difference between a stub and a mock in a unit test?
3. How does OAuth authorization differ from application authentication?
Answer guide
OAuth answers what an application may do on someone's behalf, using scopes and an access token; it does not by itself say who the user is. Authentication proves identity, and applications typically get that from OpenID Connect layered on OAuth, which adds an ID token. Mixing them up leads to treating any access token as proof of login. The resource server must validate the token's issuer, audience and scope on every call, and the client should pick a flow that fits it, such as authorization code with PKCE for public clients.
What this question explores
Whether you can separate delegated authorisation from identity proof and know how OpenID Connect fills the gap.
Common mistakes
They say OAuth is a login protocol, treating an access token as proof of who the user is.
They validate tokens only at the client and never at the API that serves the resource.
Practise a follow-up
Why is PKCE recommended for mobile and single-page applications?
What does an ID token contain that an access token may not?
4. How would you document and test the execution order of several Business Rules on one table?
Answer guide
I would start with an inventory: for each rule, record the table, when it runs (before, after, async), its order value, condition and what fields or records it writes. Then I would build controlled test records that move through the important state transitions and log which rules fire and in what sequence. Conflicts usually appear when two rules write the same field and the later one silently undoes the earlier. Where possible give each field one owner and merge competing rules. I would keep that map in the team wiki so new changes are reviewed against the real order.
What this question explores
Systematic thinking about automation order and ownership, not guesswork about what fires when.
Common mistakes
Says rules run 'in some order' and relies on trial and error in production.
Does not look for multiple rules, flows or scripts writing the same field.
Practise a follow-up
How would you detect a hidden flow that modifies the same field?
What would you do if two rules must both touch one field?
5. How would you build a roadmap and governance model for Salesforce across several business units?
Answer guide
I would start from business outcomes such as faster sales cycles or better service resolution, and map the requests of each unit to them. A central platform team owns architecture, security, data standards, release process and licensing, while business units contribute product owners and a prioritised backlog. A design authority approves significant changes and reviews technical debt. I would show the roadmap in quarterly increments with benefits, costs and dependencies, and use shared metrics such as adoption and time to deliver. The balance is between central control and unit autonomy, and I keep it healthy by making governance fast and transparent.
What this question explores
Whether you can combine business outcomes, central standards and business unit autonomy into a workable governance structure.
Common mistakes
Creating heavy governance that slows every request.
Letting each unit build independently with no shared standards.
Practise a follow-up
How do you prioritise competing requests from business units?
6. Why does a CORS failure not prove an API is secure?
Answer guide
CORS is enforced by the browser: it decides whether a web page from one origin may read a response from another. A curl script, a server or a malicious mobile app ignores it entirely, so a strict CORS policy protects users from certain cross-site reads but does not protect the API. Real protection is authentication, authorisation per resource, input validation and, for cookie-based sessions, CSRF defences. Also note that a permissive wildcard combined with credentials is not allowed, and an overly loose allow list still leaks data.
What this question explores
Whether you know CORS is a browser-side relaxation of same-origin policy and not an access-control mechanism for the server.
Common mistakes
They believe blocking cross-origin requests in CORS settings stops attackers from calling the API.
They fix a CORS error by allowing every origin, which weakens protection for cookie-based sessions.
Practise a follow-up
How do simple requests differ from preflighted ones in CORS?
Why can a CSRF attack succeed even when CORS blocks reading the response?
7. How would you rate-limit a public API fairly across several servers?
Answer guide
Pick a fair key first, usually the authenticated account combined with the endpoint, and fall back to client address only for anonymous calls, taking care to trust forwarding headers only from your own proxies. Use a token bucket or sliding window whose counters live in shared storage such as a fast key-value store, so that every server sees the same count. Return a clear rejection status with headers or a message telling clients when to retry. Allow modest bursts, and think about what happens if the shared store fails: fail open or closed is a business decision.
What this question explores
Whether you can design distributed rate limiting with a fair key, shared state, sensible client feedback and failure behaviour.
Common mistakes
They keep counters in each server's memory, so the real limit multiplies with the number of instances.
They key only on IP address and trust a forwarding header from anyone, letting clients spoof it.
Practise a follow-up
Would you choose a token bucket or a fixed window, and why?
What should the API do if the shared rate-limit store becomes unavailable?
8. How would you prevent message loss when a RabbitMQ consumer crashes?
Answer guide
Loss happens when the broker thinks a message is done before your work is. Declare the queue durable, publish persistent messages where loss matters, and use manual acknowledgements so the message is confirmed only after the consumer has finished successfully. If the consumer crashes first, the broker redelivers it. Add a bounded retry policy and a dead-letter queue for poison messages. Because redelivery means duplicates, make handlers idempotent, for example by recording processed message ids before applying the side effect.
What this question explores
Whether you understand acknowledgement timing, durability and redelivery, and accept duplicates as the price of not losing messages.
Common mistakes
They use automatic acknowledgement, so a message is discarded the moment it is delivered, even if processing fails.
They add retries without a limit or dead-letter queue, letting one poison message loop forever.
Practise a follow-up
How would you make the consumer idempotent for a payment message?
What does publisher confirm add beyond durable queues and persistent messages?
9. What would an integration test catch that a unit test may miss?
Answer guide
A unit test isolates one piece, so it can pass while the pieces fail together. An integration test crosses a real boundary, such as the application talking to a database or a broker, and exposes problems that fakes hide: wrong column types, serialisation differences, transaction behaviour, missing migrations and mis-set configuration. Use realistic dependencies, often containers, and give each test its own data so runs do not interfere. Keep the number modest, because these tests are slower, and leave fine-grained logic to unit tests.
What this question explores
Whether you understand what each test layer is for and can name the failures that only appear at real boundaries.
Common mistakes
They say integration tests just repeat unit tests, so they see no reason to write them.
They share one database across tests without cleanup, causing order-dependent, flaky results.
Practise a follow-up
How would you keep integration tests fast enough to run on every pull request?
When would you replace a real dependency with a fake in an integration test?
10. How would you test a create-resource API beyond a successful response?
Answer guide
A 201 response is only the start. Test that invalid or missing fields are rejected with a clear error body, that a caller without permission is refused, and that submitting the same request twice behaves as designed, either a duplicate error or an idempotent result. Then read the data back to confirm it was actually stored correctly, and try two simultaneous creates to expose race conditions. Also exercise timeouts and downstream failures. Assertions should target status codes, the error contract and the persisted state, running against a controlled, seeded environment.
What this question explores
Whether you test an API's failure, security and concurrency behaviour as well as the success response.
Common mistakes
They assert only that the status code is success and never confirm the resource was stored correctly.
They skip authorisation and duplicate-submission cases because the front end already prevents them.
Practise a follow-up
How would you test that repeated create requests are idempotent?
What would you put in the error contract so clients can react properly?
11. How do you hand a Figma component design to engineers without losing important behavior?
Answer guide
A static frame shows one moment, so the handoff must also describe how the component behaves. Provide every state (default, hover, focus, disabled, error, loading), the responsive rules, the design tokens for colour, spacing and type, rules for long or empty content, and accessibility notes such as focus order and labels. Name things the same way engineers will in code. Then review the built component next to the design in a shared session, because interactions and edge cases are the parts most likely to be lost between the two.
What this question explores
Whether you hand over behaviour and constraints, not only pictures, and treat design review of the implementation as part of the job.
Common mistakes
They export polished screens only and assume engineers will infer hover, error and loading states.
They skip a review after implementation, so small deviations in spacing and behaviour reach users.
Practise a follow-up
How do design tokens reduce drift between the design file and the code?
What would you do when engineering says a specified interaction is too costly?
12. How would you use Storybook to keep component states reviewable?
Answer guide
Storybook gives each component state a stable address you can open, share and test. Write stories for the states people actually need to review: empty, loading, error, long text, disabled and right-to-left where relevant. Add interaction tests and an accessibility check on the stories that matter, and keep each story beside its component so it is updated in the same pull request. Visual review or snapshot tools can catch unintended changes. Remember that a story shows a component in isolation, so end-to-end tests are still needed for whole journeys.
What this question explores
Whether you use Storybook as a living catalogue of states with checks, and know where it stops being enough.
Common mistakes
They write one default story per component, so error and edge states are never reviewed.
They treat passing stories as proof that whole user flows work in the real application.
Practise a follow-up
How would you add visual regression testing on top of Storybook?
Who should own the stories in a team with shared components?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.