# Evaluating AI candidates without AI knowledge: a checklist [Skip to content](#lm-inhoud)Network/[NL](/en/ai-kandidaten-beoordelen-zonder-ai-kennis)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%2Fai-kandidaten-beoordelen-zonder-ai-kennis&text=Evaluating%20AI%20candidates%20without%20AI%20knowledge%3A%20a%20checklist)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fai-kandidaten-beoordelen-zonder-ai-kennis)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fai-kandidaten-beoordelen-zonder-ai-kennis&title=Evaluating%20AI%20candidates%20without%20AI%20knowledge%3A%20a%20checklist)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fai-kandidaten-beoordelen-zonder-ai-kennis&text=Evaluating%20AI%20candidates%20without%20AI%20knowledge%3A%20a%20checklist)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fai-kandidaten-beoordelen-zonder-ai-kennis)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fai-kandidaten-beoordelen-zonder-ai-kennis&title=Evaluating%20AI%20candidates%20without%20AI%20knowledge%3A%20a%20checklist)[](#) # Evaluating AI candidates without AI knowledge of your own: a checklist By Ivo Donker — compiled with AI assistance (Claude & Gemini) Selecting and hiring AI specialists presents HR professionals, recruiters, and non-technical managers with one of the toughest hiring challenges around today. The field is developing at breakneck speed, the jargon changes monthly, and the spectrum of applicants varies widely. On one end are experienced software engineers who understand machine learning down to its core; on the other, enthusiastic hobbyists show up who have mainly copied ready-made API calls and standard scripts from tutorials. Anyone without a mathematical background or programming experience quickly risks relying on false certainties: bombastic terms on a resume, a long list of model names, or a collection of online certificates. Still, deep technical expertise is not an absolute requirement for separating the wheat from the chaff. Effective screening by non-technical evaluators isn't about checking mathematical proofs or parsing Python scripts. It's about testing procedural discipline, understanding architectural trade-offs, examining robustness, and checking verifiable evidence. This article offers a complete reference framework and a practical checklist that lets non-technical interviewers reliably assess a candidate's true level. ## The intake and role definition: know exactly what the organization is looking for Before the first resume even hits the table, the organization needs to have clearly defined which problem the new hire is supposed to solve. A common pitfall for non-technical hiring managers is putting together an unrealistic wish list: a specialist who independently trains neural networks, rolls out scalable cloud infrastructure, ensures legal compliance, and delivers smooth web interfaces all at once. In practice, this all-rounder rarely exists, and anyone looking for one mostly attracts candidates who have only a superficial grasp of every topic. It's essential to distinguish between the different profiles within the AI landscape. A Data Scientist focuses primarily on statistical analysis, pattern recognition, and data exploration. A Machine Learning Engineer works on model training, parameter optimization, and mathematical pipelines. An AI Engineer, by contrast, integrates existing foundation models and LLM APIs into working software and business processes. To get a sense of how these different disciplines fit together within an organization, the overview of a [building an effective AI team](https://vacatures.llmnet.nl/en/ai-team-samenstellen) helps define roles, responsibilities, and growth stages cleanly. By making an explicit choice for one of these profiles beforehand, you prevent candidates from applying based on the wrong expectations. A candidate who specializes in data modeling gets frustrated when day-to-day work consists of writing API integrations, while a pure software developer gets stuck on statistical validation. Clarity during the intake prevents friction during the rest of the selection process. ## Resume screening: separating the wheat from the chaff When reviewing a resume, many non-technical recruiters are impressed by a long list of frameworks and model libraries, such as PyTorch, LangChain, LlamaIndex, Transformers, Ollama, and Vector Databases. Naming twenty such terms often means, in practice, little more than that the candidate has skimmed the documentation or watched a YouTube tutorial. Real expertise shows up in context, constraints, and concrete outcomes. So look specifically at how projects and work experience are described. Does the candidate only mention vague claims like "built an LLM solution for customer service," or do they cite measurable parameters like "reduced document processing turnaround time by 40% and brought the error margin in structured data extraction down to below 2%"? To understand how professionals themselves analyze job postings and filter out jargon, it's illuminating to see how candidates [read AI job postings critically](https://vacatures.llmnet.nl/en/ai-vacatureteksten-lezen) to distinguish vague buzzwords from real requirements. Selection indicator | Warning sign (Superficial) | Positive sign (Craftsmanship) | Experience description | List of 25 tools and libraries without explanation | Detailed explanation of 2 or 3 delivered systems with context | Results orientation | "Successfully introduced new AI technology" | "Reduced API costs per document by 65% through caching and targeted prompts" | Certification | A series of short multiple-choice certificates from online platforms | Public code repositories, documented hobby projects, or technical articles | Self-reflection | Presenting projects as if everything worked flawlessly right away | Honest description of bottlenecks, edge cases, and iterations made | ## Assessing portfolios and projects without reading code yourself A candidate who points to their own GitHub account or publicly accessible demo projects provides valuable evidence. Even if you don't know a single programming language, you can determine the quality and maturity of such a repository surprisingly accurately based on structure and documentation. Open the project's main page and inspect the README.mdfile. A serious developer provides a crystal-clear introduction that answers the following questions: what specific problem does this project solve, what assumptions were made about the input data, how do you install and run the software locally, and what dependencies are required? When a repository consists of nothing more than an unorganized collection of loose Python files (such as script_v2_final.py) with no explanation whatsoever, that points to a lack of professional working standards. Also pay attention to the date and frequency of the changes (the commit history). Were all the files uploaded in one single bulk upload? That could indicate a project copied from elsewhere. If, on the other hand, there's a series of sequential steps with clear explanations for each change (for example, "added error handling for missing JSON fields" or "extended evaluation script with new test cases"), that shows an iterative and deliberate work process. ## Targeted interview questions and answer patterns During the personal interview, you can ask targeted process questions where you're not paying attention to mathematical details, but to the logic and robustness of the reasoning. Good AI engineers excel at managing the uncertainties and imperfections of models. ### 1. How do you measure whether an AI solution functions reliably? Weak candidates rely on so-called eyeball evaluation: they manually enter a handful of questions, see that the answer looks reasonable, and conclude that the system is ready for production. Experienced specialists are horrified by this approach. They explain how they put together a representative test dataset (evaluation corpus) and which objective metrics they use to check whether changes to prompts or models don't cause regressions. To understand how systematic evaluation methods work, the reference framework for a [framework for evaluating an LLM yourself](https://benchmark.llmnet.nl/en/zelf-evalueren-raamwerk) offers concrete methods for making quality and determinism measurable. ### 2. What happens if the model hallucinates or generates corrupted output? When a candidate answers that hallucinations are solved by "politely asking the model in the prompt to tell the truth," that lacks technical realism. A seasoned engineer discusses hard programmatic controls: validating structured JSON output against a strict schema, fallback mechanisms to traditional search algorithms, and guardrails that check whether claims can be directly traced back to the supplied source documents. ### 3. What trade-offs do you make between model size, latency, and operational costs? Blindly choosing the largest and most expensive commercial language model rarely reflects good technical leadership. Ask the candidate why they didn't opt for a more compact model or caching in a specific project. A strong candidate can precisely work out how token limits, user interface response times, and operational hosting costs relate to each other. ## Recognizing tutorial candidates and hype surfers The huge accessibility of generative AI has led to an influx of applicants who copy online tutorials word for word and present them as their own work. These are so-called tutorial candidates. They can put on an impressive demonstration as long as everything stays within the prescribed path, but go silent the moment the context changes. You often recognize tutorial projects by typical standard use cases: a chat feature over an uploaded PDF using the default library settings of a popular framework. As soon as you dig deeper into what happens with concurrent use by a hundred users, how documents with complex tables are parsed, or how privacy-sensitive data is handled, these candidates have no answer. A second category is the hype surfers: professionals who know in theory exactly which models and research papers came out yesterday, but who have little affinity for solid software engineering. They'd rather talk about hypothetical possibilities than automated testing, monitoring, deployment pipelines, and error handling. In a business setting, however, solid software architecture accounts for about 80% of what determines the success of an AI implementation. ## The technical assessment: structure and independent evaluation Once a candidate has successfully made it through the first interview rounds, a technical trial assignment is essential. Because as a non-technical evaluator you can't audit the code yourself for security risks and efficiency, a standardized setup is necessary. An effective assessment consists of a realistic take-home assignment of no more than 3 to 4 hours, focused on a recognizable business problem. For example, ask the candidate to build an API integration that categorizes and validates incoming unstructured customer messages. To get a good sense of the requirements and dynamics around such tests, see the guide to [preparing for the technical assessment](https://vacatures.llmnet.nl/en/technisch-assessment-voorbereiden) within the selection process for AI and software roles. Then have the submitted work reviewed by an external senior specialist or a trusted freelance software architect. Give this reviewer a fixed evaluation matrix with concrete scoring criteria: Assessment pillar | What the external reviewer looks for | Weight | Error handling & Robustness | How does the code respond to missing fields, network errors, and API rate limits? | Heavy | Test coverage | Are there automated tests in place that demonstrate the logic works correctly? | Heavy | Documentation & Setup | Is the project immediately reproducible via a clear guide and a container or environment file? | Medium | Cost & Speed Awareness | Are prompts and calls built efficiently without unnecessary data waste? | Medium | ## The practical assessment checklist The checklist below bundles all evaluation steps into a clear overview that can serve as a guide throughout the entire hiring process: Phase | Checkpoint | Sufficient | Point of Attention | 1. Resume & Profile | Projects show concrete, measurable context and business results achieved. | [ ] | Just a list of trendy model names and tools. | 2. Portfolio | Repositories contain clear documentation, installation steps, and a clear commit history. | [ ] | A few loose scripts with no explanation or one-off bulk uploads. | 3. Communication | Candidate explains complex design choices clearly and without excessive jargon. | [ ] | Retreats into abstract terms when asked simple questions about the business logic. | 4. Evaluation method | Candidate uses systematic test sets and metrics to safeguard performance. | [ ] | Assesses quality solely based on a few manual spot checks. | 5. Error management | Structural measures are in place against hallucinations, data leaks, and high API costs. | [ ] | Blindly trusts the default output of external models. | 6. Assessment | The delivered code is modular, documented, tested, and checked via a fixed matrix. | [ ] | Unclear scripts with no error handling or test scenarios. | ## Working with subject-matter experts and wrapping up Selecting AI talent without deep technical expertise of your own mainly requires procedural precision and a healthy dose of critical distance. By shifting the focus from impressive buzzwords to systematic evaluation methods, error handling, and documentation standards, non-technical interviewers can determine with great precision whether a candidate will genuinely add value to the organization. When you combine this structured questioning with an independent external review of the code assessment, you get a robust and reliable selection process. This is how you confidently build a capable, future-proof team that translates AI technology into measurable organizational success.