The sequence is almost always the same. A 25-minute screening call with a recruiter, mostly about your notice period, your salary expectation and whether you need sponsorship. Two days later an email arrives with a link, a deadline and a sentence like "should take about four hours". The link works once. The clock starts when you open it.

If you have never done a technical interview Netherlands employers run, the thing that catches people out is not the difficulty of the problems. It is the format: what counts as finished, what the reviewer is actually looking at, and which parts you are allowed to ask about before the timer begins. A Dutch-based candidate asks their recruiter a quick question on WhatsApp and gets an answer in ten minutes. If you are applying from Lagos, Bangalore or São Paulo, that same question can cost you a working day of your deadline.

What follows is the practical version: the formats in use, how long each one really takes, where international candidates lose attempts for reasons that have nothing to do with code, and what to send back.

Dutch tech employers use three assessment types, sometimes two of them in sequence. Before you write a line of code, identify which one is in your inbox, because the preparation for each is different.

The asynchronous take-home. You get a repository, a brief, a dataset or a Figma file, plus a window (commonly 48 to 72 hours of calendar time with a suggested effort of a few hours). Nobody watches you. The artefact is judged.

The timed platform test. A link to an assessment tool with algorithmic or language-specific questions, a hard timer, and often a webcam or tab-focus requirement. Scored automatically, sometimes with a human looking at the top-scoring submissions only.

The live session. A video call of 45 to 90 minutes where you write code, debug something, or extend an existing codebase while two engineers watch and occasionally interrupt. In the Netherlands this is frequently framed as "pair programming" rather than "coding interview", and that framing is a genuine signal about what is being scored.

The email usually tells you which one you have if you read it as a document rather than a notification. Look for the words "at your own pace" (take-home), "you will have 60 minutes from the moment you start" (platform test), or a calendar invite with two names on it (live session). An email with both a link and an invite means a take-home that will be discussed in a follow-up call, which changes how you should write it.

A typical Tuesday: screening call, then a 48-hour link in your inbox

The most common failure on a take home assignment Netherlands jobs send out is not a bug. It is scope. The brief says "build a small service that exposes two endpoints and stores the results", and the candidate delivers authentication, Docker Compose, a CI pipeline, a React front end and 40 tests, three days late. The reviewer, who has 25 minutes blocked for this, opens the repository and cannot find the two endpoints.

Dutch engineering teams tend to read a take-home as evidence of how you work, not how much you can produce. A few things reviewers at sponsoring companies consistently look for:

- A README that is written for them, not for you. How to run it, what you chose to leave out and why, what you would do next with another day. The "what I left out" section does more for you than an extra feature.

- Commits that tell a story. One commit called "solution" is a missed opportunity. Six commits that show you building the core first and refactoring after read as professional.

- Tests on the parts that matter. Two meaningful tests on the business logic beat 30 generated tests on getters.

- Respect for the stated time. If the brief says three hours and you spent twelve, say so honestly in the README. Reviewers notice the mismatch anyway, and the ones who notice silently are the ones who mark you down.

If the brief and the time estimate conflict, build the smallest version that works end to end, then document the gap. Partial and coherent beats complete and unreadable.

The second trap is the deadline type. "48 hours" sometimes means 48 hours from receipt and sometimes means "send it back before Thursday's panel". These are very different if you have a day job in a different time zone. Settle which it is in your first reply, not on hour 40.

A coding test Dutch tech companies run live is usually not a test of whether you remember the standard library. The two engineers on the call are watching how you behave when you do not immediately know the answer.

Concretely, what gets written in the feedback form after a pairing session comes down to five things: whether you asked clarifying questions before starting or simply assumed, whether you said what you were about to do before doing it, whether you engaged with the interviewer's alternative approach or defended your own, whether you caught your own mistake before being told, and whether you could explain a trade-off in plain language.

Dutch workplace culture is direct and flat in a way that genuinely shows up here. An interviewer who says "I don't think that will work" is not being hostile and is not testing your composure. They are doing what they would do with a colleague on a Tuesday afternoon. The expected response is to discuss it, not to apologise or to immediately abandon your approach. Candidates from more hierarchical working cultures often read that interruption as failure and go quiet, which is the actual scoring event. The same dynamic shows up across the hiring process, and it is one of the skills that get internationals hired in Dutch tech more reliably than another framework on the CV.

Practical preparation that works: use your own editor if allowed, ask for the problem statement in writing at the start, narrate in short sentences, and say "I don't know, here is how I'd find out" when that is the true answer. Nobody loses a Dutch live round for not knowing something. People lose it for pretending.

Take-home assignments: scope, time limit, and what "done" really means

For medior and senior roles you will usually get a design conversation, either as its own 60-minute round or as the second half of a longer loop. The prompt is deliberately underspecified: design a service that ingests payment events, design the booking flow, design how we would store and query these documents.

A system design interview Netherlands employers run tends to be scaled to the company, not to a FAANG template. A 60-person scale-up in Eindhoven is not interested in whether you can shard across three regions. They want to know whether you ask about volume before choosing a database, whether you can say out loud which failure modes you are accepting, and whether you would be a safe person to hand a production incident to.

The underlying question is almost always what you do when the requirements are incomplete. So start by making them complete: ask about expected request volume, read-versus-write balance, consistency requirements, who the consumers are, and what the team already runs. Then design for that, and name the thing you are trading away. Saying "I'd accept eventual consistency here because the dashboard is read by humans once a day" is worth more than a diagram with six boxes.

If you are targeting a senior title specifically, the expectations around scope and ownership in Dutch teams are covered in more detail in the medior-to-senior playbook.

None of the following appears in the assessment brief, and all of it costs people attempts.

Time zones compress your window. A 48-hour take-home sent at 17:00 CET on a Friday gives a candidate in Amsterdam two weekend days. It gives a candidate in Manila a window that opens at midnight and includes a working week. You can ask for a shift. Ask in the first reply, give a reason and propose a specific new deadline. Recruiters at sponsoring companies deal with this constantly and most will move it. Nobody can move it on hour 46.

Platform access fails in ways nobody tests for. Some assessment platforms geo-restrict, require a phone verification that rejects certain country codes, or break on connections with high latency. Open the link the moment it arrives, confirm it loads, confirm you can type in the editor, then close it without starting if the tool lets you. If there is no preview mode, say so in your reply and ask for written confirmation that the timer starts on your first action.

Interview loops collide with visa questions. If sponsorship has not been confirmed yet, the technical round is the point where candidates are most tempted to leave the subject alone and hope. That is the wrong instinct, because the whole process can still be voided at the offer stage by a salary that does not meet the IND criterion. Handle it the way the piece on answering the sponsorship question describes, and verify on the IND public register that the employer is actually a recognised sponsor (erkend referent) before you spend a weekend on their take-home.

The video round may be AI-screened first. Several Dutch employers now put an automated interview before the human technical round, which is a separate preparation problem from coding and is covered in the guide to AI job interview questions.

Most Dutch take-homes are legitimate. A minority are not, and the distinction is usually visible in the brief before you start.

Signals that you are being asked to do commercial work:

Signals it is a normal assessment: a synthetic or public dataset, a fictional domain, a stated time box of a few hours, and a brief that says explicitly that you keep your code.

If the task is large and genuinely useful to them, asking about payment is reasonable, and some Dutch companies do pay for longer assignments. Phrase it neutrally: say that this looks like a day of work rather than the three hours mentioned, then ask whether it is a paid assignment or whether a reduced scope would be acceptable. The answer tells you a lot about the company either way. A refusal plus insistence on the full scope is a legitimate reason to withdraw. Companies that treat unpaid pre-hire labour as normal usually have other patterns worth knowing about, and the ones to watch for appear in the guide to spotting real versus fake sponsorship ads.

Before you open the link, send one short email with up to four questions. Four is the realistic ceiling before you look high-maintenance. Ask whether the deadline runs from receipt or from a fixed calendar date. Ask whether the suggested effort is a target or a limit. Ask who reviews it and whether there will be a follow-up discussion about the code. Ask whether there is a stack constraint or whether any reasonable choice is acceptable.

When you submit, keep the delivery boring and complete: a repository link or zip that actually opens, run instructions that work on a clean machine, and a README with your assumptions, your omissions and roughly how long you spent. If a follow-up call is scheduled, reread your own code the morning of the call. Being unable to explain a decision you made 72 hours ago reads worse than the decision itself.

Rejections at this stage are frequently about calibration rather than ability: the team had a specific stack in mind, the reviewer wanted more depth on testing, someone else solved the same problem more cleanly. Ask for the feedback in one line, accept whatever you get, and do not relitigate the grading.

Retrying the same company is usually worth it after six to twelve months, and much more worth it if you can point to something that changed. A better use of the next two weeks is almost always applying the preparation you just did somewhere else. If you built a working service in a specific stack for one sponsoring employer, there are likely several other recognised sponsors with open roles in the same stack, including ones posted months ago that no longer surface in a date-sorted search. Timelines across the whole process, including how long the assessment stage typically adds, are set out in the Netherlands job search timeline.

Most briefs state three to six hours of effort inside a 48 to 72 hour window. If the stated effort and the actual scope are clearly mismatched, build the core, document the rest and say what you cut. Spending 15 hours on a four-hour brief does not read as commitment.

Ask, and assume the answer appears in the brief. A growing number of Dutch teams explicitly allow it and then ask you to explain every line in a follow-up call, which is a harder test than writing it yourself. Using it where it was prohibited, particularly on a monitored platform, is one of the few genuinely unrecoverable mistakes at this stage.

Almost never. Engineering interviews at sponsoring companies run in English as a matter of course. Dutch becomes relevant later, for internal communication and for roles that touch Dutch customers or public-sector clients, as covered in the case for learning Dutch for your career here.

No. Assessment stages are run by the engineering team. Sponsorship is a separate decision involving HR, the IND salary criterion and the company's recognised sponsor status. Confirm the sponsorship path before the final round, not after the offer.

Yes, once, with a specific alternative proposed and as early as possible. Time zone and connectivity reasons are accepted without friction. Rescheduling twice, or cancelling within a few hours of the slot, is read as unreliability.

The work you did for one assessment travels further than one application. If you want every currently open sponsored role that matches your profile rather than only the ones posted this week, ArrowLancer's Match Sweep runs a full sweep across all active jobs for a €14.99 one-off: get matched automatically, or browse visa-sponsored jobs yourself first and see which stacks keep repeating.