# The selection process for AI roles: from CV to assessment

[Skip to content](#lm-inhoud)Network/[NL](/en/selectieproces-ai-als-een-route)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route&text=The%20selection%20process%20for%20AI%20roles%3A%20from%20CV%20to%20assessment)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route&title=The%20selection%20process%20for%20AI%20roles%3A%20from%20CV%20to%20assessment)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route&text=The%20selection%20process%20for%20AI%20roles%3A%20from%20CV%20to%20assessment)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fselectieproces-ai-als-een-route&title=The%20selection%20process%20for%20AI%20roles%3A%20from%20CV%20to%20assessment)[](#)

 
# The Selection Process for AI Roles as One Continuous Journey

 By Ivo Donker — compiled with AI assistance (Claude & Gemini) · August 18, 2026

 In practice, the hiring of AI Engineers, Machine Learning Specialists, and Data Scientists rarely happens through separate, disconnected steps. Those applying for a technical position in the AI domain quickly discover that sending in a resume, having an exploratory conversation, and doing a live assessment are all part of one overarching chain. Throughout the entire cycle, companies test the same core competencies: problem-solving ability, mastery of data architecture, realism about model limitations, and the skill to justify technical choices. This article focuses primarily on candidates preparing for a selection process for AI positions, but also offers insight for hiring teams looking for consistency in their evaluation criteria.

 
## The anatomy of the hiring chain

 The selection process traditionally consists of four to five successive phases: the initial resume and portfolio screening, the exploratory conversation (often with a recruiter or engineering manager), the in-depth technical interview, the technical assessment, and the final culture and contract phase. When we approach these steps as separate islands, we risk stories not lining up with each other, or claims on the resume not being backed up during the assessment.

 The information put down on paper in phase one serves as direct input for the questions in phase two and the case selection in phase four. If a candidate states on their resume that they're skilled at reducing inference latency, they can count on interviewers probing further during the technical conversation about specific optimization techniques such as quantization, batching, or kernel fusion. Good preparation therefore starts with the very first written statement. For those looking for a structured overview of the initial phase, the guide on [applying for an AI position](https://vacatures.llmnet.nl/en/solliciteren-ai-functie) concrete guidance for successfully getting through the initial screening.

 
 
 
 
 Phase | 
 Employer's goal | 
 Candidate's focus point | 
 Typical failure factor | 
 

 
 
 
 1. Screening & Portfolio | 
 Filtering for measurable impact and relevant tech stack | 
 Concretizing contributions and measurable results | 
 Generic buzzwords without an underlying codebase | 
 

 
 2. Exploratory interview | 
 Testing communication and career motives | 
 Clearly articulating your own technical profile | 
 No clear delineation of your own share in projects | 
 

 
 3. Technical deep-dive interview | 
 Verifying in-depth expertise and conceptual insight | 
 Substantiating architecture and model choices | 
 Getting stuck in theory without operational context | 
 

 
 4. Practical assessment | 
 Observing work approach, code quality, and debugging skills | 
 Clean coding, testing, and handling model noise | 
 Over-engineering or ignoring evaluation metrics | 
 

 
 5. Closing & Match | 
 Examining team fit and expectations | 
 Asking questions about infrastructure, budget, and culture | 
 Passive attitude toward the work environment | 
 

 
 
 

 
## Phase 1: The resume and portfolio as the foundation

 The resume and portfolio form the starting point of the journey. Instead of an exhaustive list of libraries and algorithms, technical evaluators expect evidence of systems that have actually been built and run. Training a model in an isolated Jupyter notebook is now the bare minimum; demonstrating that a pipeline functions stably under fluctuating data input makes the difference.

 During this selection step, a reviewer looks at the complexity of the projects completed. Has thought been given to data ingestion, error handling, rate limits, and evaluation frameworks? Those who show projects in which edge cases have explicitly been accounted for create a reliable impression. To understand how to best shape tangible projects, it's worth reading about [building a strong AI portfolio](https://vacatures.llmnet.nl/en/ai-portfolio-bouwen), where the emphasis is on code quality and traceability over superficial demonstrations.

 
## Phase 2: The exploratory interview and the technical intake

 Once the resume has been selected, a conversation of thirty to forty-five minutes usually follows. Although this conversation often looks informal, the hiring team is testing here whether the candidate is able to explain complex material in an understandable way to stakeholders with different levels of expertise. After all, an AI Engineer has to switch regularly between product managers, data engineers, and management.

 During this conversation, candidates are challenged to break down their previous projects. Why was a specific embedding model chosen? What were the operational costs per thousand calls? Where did the system get stuck as data volume increased? Those who answer these questions with vague catch-all terms quickly lose ground. To gain insight into the questions recruiters and leads regularly use, the overview of [interview questions for AI positions](https://vacatures.llmnet.nl/en/interviewvragen-ai-functies) valuable examples for sharpening your answers.

 
## Phase 3: The technical deep-dive interview

 In the technical deep-dive interview, the emphasis shifts from general experience to fundamental principles and system design. Here it's assessed whether a candidate understands what happens under the hood of modern architectures. Topics discussed include transformer models, attention mechanisms, quantization methods, vector databases, and retrieval strategies.

 A common component is designing an AI system on a digital whiteboard. The assignment might read, for example: "Design a scalable customer service assistant that searches documentation, takes user permissions into account, and delivers a first streaming response within 400 milliseconds."

 During this exercise, it's not just the final diagram that counts, but especially the trade-offs made during the design process:

 
 
- Data input and chunking: How are large documents split up, and how is context preserved around tables and lists?
 
- Retrieval and reranking: Is the choice made for dense vectors, sparse search (such as BM25), or a hybrid combination with a cross-encoder?
 
- Model choice and latency: What balance is struck between a compact local model versus a larger external API?
 
- Monitoring and guardrails: How are hallucinations detected, and how is sensitive data prevented from leaking?
 

 
## Phase 4: The technical assessment and the evaluation culture

 The technical assessment is the true test. Employers typically opt for a take-home assignment or a live pair-programming session of two to three hours. The assignment often simulates a real task within the team, such as building a RAG pipeline, fine-tuning a classification model, or optimizing a data-loading process.

 What many candidates underestimate is that a working solution is only the starting point. Evaluators look critically at how the code is structured, whether unit tests are present, how configurations are managed, and how the system handles unexpected input. Those who want to thoroughly prepare for the typical pitfalls during coding tests can consult the guide on [preparing for a technical assessment](https://vacatures.llmnet.nl/en/technisch-assessment-voorbereiden) for direct insight into what examiners expect.

 An essential element in modern assessments is the evaluation layer. A model that appears to respond well to ten manual prompts is vulnerable in production. Companies test whether candidates can set up automated evaluation metrics to prevent regressions. To see which quantitative methods and benchmarks are common when systematically measuring AI behavior, the reference guide on [how to evaluate an AI agent](https://benchmark.llmnet.nl/en/agent-evaluatie) how task success and intermediate steps are tested in a structured way.

 
## The common thread: consistency from claim to code

 The biggest danger in a selection process is a break in consistency. When a candidate writes in their cover letter that latency optimization is their specialty, then hesitates about caching mechanisms during the deep-dive interview, and delivers a blocking synchronous loop in the assessment, doubt arises among the evaluators. The selection process should therefore be seen as one continuous argument.

 The pseudocode below illustrates what a robust evaluation structure looks like in an assessment. Instead of relying on a single generic model call, this setup explicitly shows how validation, token monitoring, and structured error handling are built in.

import time
from typing import Dict, Any, Optional

class ResilientAIService:
 def __init__(self, client: Any, model_name: str, max_retries: int = 3):
 self.client = client
 self.model_name = model_name
 self.max_retries = max_retries

 def generate_with_fallback(self, prompt: str, schema: Dict[str, Any]) -> Optional[Dict[str, Any]]:
 payload = {
 "model": self.model_name,
 "messages": [{"role": "user", "content": prompt}],
 "response_format": {"type": "json_object"},
 "temperature": 0.1
 }
 
 for attempt in range(1, self.max_retries + 1):
 try:
 start_time = time.perf_counter()
 response = self.client.chat.completions.create(**payload)
 latency = time.perf_counter() - start_time
 
 content = response.choices[0].message.content
 parsed = self._validate_schema(content, schema)
 
 # Log latency en tokenverbruik voor reproduceerbaarheid
 self._record_metrics(latency, response.usage.total_tokens)
 return parsed
 except Exception as err:
 if attempt == self.max_retries:
 raise RuntimeError(f"Faal na {attempt} pogingen: {str(err)}")
 time.sleep(2 ** attempt)
 return None

 def _validate_schema(self, raw_json: str, schema: Dict[str, Any]) -> Dict[str, Any]:
 # Placeholder voor robuuste parsering zoals Pydantic validatie
 import json
 return json.loads(raw_json)

 def _record_metrics(self, latency: float, tokens: int) -> None:
 pass

 
## The candidate's role as a critical evaluator

 An application procedure is not a one-way street. While the company is investigating whether the candidate has the right skills, the candidate should be assessing whether the organization has a mature AI vision. Many companies are still in an exploratory phase in which use cases haven't been clearly defined or where the necessary data infrastructure is lacking.

 During the final rounds of conversation, it's wise to ask targeted questions about day-to-day practice:

 
 
- What percentage of AI prototypes actually make it to the production environment?
 
- How is the separation organized between data engineering, model development, and infrastructure management?
 
- What budget and what freedom is there for running experiments and using API services?
 
- What tooling is used for observability, data lineage, and model registration?
 
 The answers to these questions often reveal whether a team already works in a structured way with continuous integration and evaluation, or whether they're still struggling with uncontrolled notebooks that are manually transferred to servers.

 
## Common mistakes per process step

 In practice, candidates often fall short due to avoidable stumbling blocks that can easily be corrected when you see the whole process:

 
 
### 1. Fixating blindly on model size

 Many applicants try to impress with the heaviest models, while employers are actually looking for cost-efficient and scalable solutions. Those who can demonstrate that a task can be reliably solved with a smaller, quantized model or a well-designed search system show more professional maturity than someone who blindly calls an external top-tier model for every problem.

 
### 2. The absence of error handling

 During live-coding sessions, candidates regularly write 'happy path' code. In the AI domain, however, input is inherently unpredictable: APIs hiccup, embeddings drift, and models can refuse to return structured JSON. Code that accounts for these uncertainties and includes fallbacks scores considerably higher.

 
### 3. Ambiguity about your own role

 When a candidate talks about a previous team project, it must be clear what the individual contribution was. Phrases like "we built a RAG system back then" immediately raise the question with technical interviewers of who designed the architecture and who merely wrote the prompts. Be precise in your explanation: state exactly which modules were developed by whom.

 
## Conclusion and checklist for the complete journey

 Those who approach the selection process as one coherent system considerably increase their chances of a successful outcome. By formulating clear claims from the very first resume contact, explaining them convincingly in conversations, and backing them up with tested code in the assessment, a robust and reliable profile emerges.

 Before you enter the next process, it's useful to run through the checkpoints below:

 
 
- Do all technologies on the resume match projects that can be directly demonstrated in the codebase?
 
- Are the choices for frameworks, evaluation methods, and models backed by measurable arguments around cost, latency, and accuracy?
 
- Is the development environment set up for live pair programming, including linters, test frameworks, and debugging tools?
 
- Are sharp questions ready to critically probe the technical maturity of the hiring team?