API Integration Developer Skills Test: What Employers Should Assess
An effective API integration developer skills test should ask a candidate to build and explain a small, production-style integration. The assessment should reveal whether they can clarify requirements, authenticate securely, validate and transform data, prevent duplicate processing, recover from failures and leave maintainable documentation. Use a sandbox CRM or mock service with fictional data, then introduce a failure such as throttling, a delayed response or a changed schema. The candidate's diagnosis and trade-offs are often more revealing than whether the initial request succeeds.
What the assessment needs to measure
Judge the complete operating path: receiving a request, checking its authenticity, mapping data, updating the destination and recovering when something fails. Adapt the language and platform to your stack, but retain the failure-handling and explanation requirements. For UK and European employers, also assess how the developer communicates an incident during your business hours and handles access to personal data.
How Borderless Recruit helps
Borderless Recruit is a recruitment and staffing agency specialising in Philippine AI and automation talent. Its dedicated specialists work only for you during your UK or European business hours. It handles sourcing, vetting, local employment contracts, payroll and HR for a flat monthly fee. The Integrations Developer (APIs) tier starts from £1,140 / €1,320 per month ($1,500). Vetting includes a live English interview, a personality/reliability assessment and a hands-on multi-step workflow build with error handling.
Copy-ready API integration test blueprint
Assessment stages and the evidence each should produce
| Stage | Candidate task | Evidence to assess |
|---|---|---|
| Requirements review | Read an incomplete brief and submit clarifying questions before coding. | Recognition of missing ownership, data, security, retry and acceptance requirements. |
| Practical build | Receive a sandbox CRM webhook, validate it and synchronise selected fields to a destination REST service. | Correct API use, clean mapping, secure configuration and automated tests. |
| Failure simulation | Respond to duplicate events, throttling, malformed data and timeouts. | Durable duplicate protection, bounded retries and useful diagnostics. |
| Review and handover | Demonstrate the solution, make a requested change and explain deployment and recovery. | Engineering judgement, communication and maintainability. |
Practical exercise: CRM lead synchronisation
Use this fictional exercise: a CRM sends lead-created and lead-updated events to a marketing platform. Supply mock endpoints, a webhook signing specification, example payloads and a destination API contract. Include an event identifier, lead identifier, source version, email address and marketing-consent field. The destination should support a stable external identifier for matching records. Provide documented authentication and throttling behaviour so candidates can work from a clear technical contract.
Leave selected business rules open for clarification: which system owns each field, whether an email change identifies a new person, and what withdrawing consent should do. Keep an assessor answer sheet and give equivalent answers to comparable candidates. Explain that identifying ambiguity is part of the exercise; undisclosed rules should not become hidden reasons to fail someone.
- Verify the webhook signature against the original request body before trusting or transforming its contents; apply replay checks supported by the supplied signing scheme.
- Validate required fields and normalise the payload without exposing secrets or personal information in logs.
- Keep credentials outside source code and test fixtures. Demonstrate refresh or rotation behaviour where the supplied authentication scheme requires it.
- Prevent repeated delivery from creating duplicate records, including after processing restarts.
- Handle throttling, temporary failures and timeouts without retrying permanently invalid requests indefinitely.
- Submit automated tests, a sample configuration without secrets, a field-mapping document and concise run and recovery instructions.
Make acceptance observable: delivering the same event repeatedly must not create additional destination records; an older source version must not overwrite a newer accepted update; and invalid input must leave the destination unchanged. Include a destination write that succeeds but whose response is lost. Ask the candidate to demonstrate how a retry avoids duplicating that write. Recording an event as processed after success alone does not resolve this uncertainty.
Variants for automation and enterprise platforms
For n8n, Make, Zapier or Power Automate candidates, permit a platform-native implementation but still require explicit error paths, replay protection, credential handling and exportable documentation. The n8n developer assessment provides a tool-specific companion. For enterprise integration platforms, supply an incomplete synchronisation flow and ask the candidate to diagnose a changed payload format, isolate failed records and explain monitoring and rollback. Require only features available in the test environment.
A transparent scoring rubric by seniority
Score observed evidence rather than polish. Use the ratings demonstrated independently, demonstrated with prompting, and not demonstrated for each assessment area: requirements, correctness, resilience, security, testing, maintainability and communication. Record the behaviour or test result behind each rating. Mark anything outside the agreed exercise as not assessed.
Seniority expectations for this assessment
| Level | Expected evidence | Appropriate scope |
|---|---|---|
| Junior | Builds the happy path with guidance, validates inputs, protects credentials and writes useful tests. Identifies where support is needed. | Bounded integrations with established patterns, review and close supervision. |
| Mid-level | Clarifies ambiguity, implements durable duplicate protection and classified retries, tests failure paths and produces usable documentation. | Owns routine third-party integrations and their maintenance. |
| Senior | Anticipates partial failures and concurrency, weighs architectural alternatives, and designs monitoring and recovery around business risk. | Owns integration architecture, critical workflows and incident decisions. |
Define the required independence before interviewing. For an ownership role, unresolved credential exposure, silent data loss or duplicate writes should block a pass even if the presentation is strong. If a candidate corrects a problem after prompting, record both the original failure and their reasoning. Do not convert a simple average into a seniority decision or infer capability in an area the exercise did not test.
Test production resilience, not just successful requests
Failure drills and answer guidance
| Injected condition | A strong response includes | Weak response |
|---|---|---|
| Duplicate event or concurrent delivery | A stable event key, durable state and atomic coordination or destination-side idempotency. | A memory-only flag or a check followed by an unprotected write. |
| Out-of-order update | A source version or agreed ordering rule that prevents stale data overwriting newer state. | Assuming deduplication also guarantees event order. |
| Throttled dependency | Respect for provider retry guidance, capped retries, varied retry delays and queued work where appropriate. | Immediate, unlimited retries. |
| Permanent validation error | A safely isolated record, an actionable diagnostic and a controlled correction or replay path. | Dropping the record silently or retrying forever. |
| Destination commits but response is lost | Destination idempotency or reconciliation using a stable identifier before replay. | Blindly repeating a potentially successful write. |
| Extended outage | Timeouts, controlled concurrency, alerts and recovery from durably stored work. | Blocking indefinitely or acknowledging receipt before durable acceptance. |
Ask candidates to explain their mechanisms in plain English. Idempotency means repeating an operation has the same intended effect as performing it initially; it does not automatically solve ordering or every partial failure. A dead-letter queue isolates work that cannot be processed automatically. Neither earns credit merely by appearing in an architecture diagram: ask the candidate to show the relevant failure and recovery behaviour.
Security and data-protection questions
Ask where secrets reside, who can rotate them, which data appears in logs and how access is restricted. Require a demonstration using fictional records. A useful handover identifies the service accounts, permissions, log retention settings and steps for revoking access when someone leaves.
If a Philippine specialist can access UK personal data, assess whether the arrangement is a restricted transfer and which safeguards are required under the ICO guidance on international transfers. EU employers should assess transfers under the European Commission's guidance on transfers outside the EU. A coding test can expose unsafe engineering assumptions; it cannot establish legal compliance.
Assess AI integration skills only when the role needs them
A developer connecting language models or agents needs the same integration fundamentals plus model-specific controls. Extend the exercise with a mock model response or tool call and assess validation, permissions and fallback behaviour. Keep this optional for a conventional API role. For deeper orchestration and retrieval work, use the AI agent developer skills test.
Optional AI integration extensions
| Extension | What to assess | Strong answer guidance |
|---|---|---|
| Structured model output | Validation and recovery from malformed or inappropriate output. | Treat output as untrusted input; validate both its structure and permitted business values before acting. |
| Retrieval-augmented generation | Document permissions, retrieval relevance and stale content. | Preserve access controls through indexing and retrieval; evaluate retrieval separately from answer generation. |
| Agent tool call | Least privilege, approval boundaries and auditability. | Validate arguments, restrict available actions and require human approval for actions designated as sensitive. |
Set a fair policy for AI coding assistants
Allow or prohibit AI tools explicitly. Where assistants are part of the job, permit approved tools and ask candidates to summarise how they used them and checked the output. Do not demand unrelated private prompt histories. During the live review, request a small behavioural change, introduce a failing test and ask why the proposed fix is safe. This provides evidence of whether the candidate can understand, debug and maintain the submission.
- Provide fictional data and placeholder credentials for use in prompts; keep working credentials out of external tools.
- State whether code generation, search and documentation are permitted.
- Ask candidates to identify generated code they changed or rejected and explain why.
- Judge engineering decisions, tests and explanations rather than typing speed.
Assess collaboration during UK or European business hours
Apply the same practical standard to Philippine and local applicants. Ask the candidate to write an incident update stating what failed, which business process is affected, what is known and what needs a decision. Then ask them to explain a technical trade-off to a non-technical operations lead.
Agree a Philippine shift that overlaps your UK or European business hours. The Philippines does not observe daylight saving, so specify how the shift will adjust when your local clocks change. Clarify escalation ownership and arrangements outside the agreed shift; business-hours overlap should not be interpreted as continuous incident cover.
Candidate-friendly assessment checklist
- Use fictional data, mocks or vendor sandboxes rather than production credentials or a disguised client deliverable.
- Keep the exercise bounded and compensate candidates for substantial practical work. Pilot it internally before setting the time allowance.
- State the stack, permitted tools, expected artefacts and scoring rubric before the assessment.
- Distinguish what must work in the submission from architecture topics reserved for discussion.
- Offer a platform-neutral route when product-specific syntax is not essential, and invite requests for reasonable adjustments.
- Explain who will review submissions, how they will be used and when they will be deleted.
The hiring decision should follow the work the developer will own. A candidate who can make an API call but cannot recover, diagnose or document it has not demonstrated readiness to own a critical integration. Look for evidence that they clarify ambiguity, protect data, test failures and leave a system someone else can operate.
Frequently Asked Questions
What is the difference between API testing and API integration testing?
API testing checks an interface's behaviour, contract, validation and responses. Integration testing checks whether connected systems work together, including authentication, field mapping, state changes, duplicate events, dependency failures and recovery. A hiring exercise should cover both where the role includes ongoing integration ownership.
Can a non-technical hiring manager run this assessment?
You can set the business scenario and assess communication, but involve a technical reviewer to inspect authentication, concurrency, data integrity and recovery. Ask that reviewer to demonstrate the failure tests and explain any unresolved risks in business terms. A successful demonstration alone is insufficient evidence for production ownership.
Sources
- ICO guidance on international transfers — ico.org.uk
- European Commission's guidance on transfers outside the EU — commission.europa.eu