The best AI engineer for a team is rarely the one with the longest list of tools. It is the one whose work can be checked: a system that runs, tests that decide what ships, and an honest account of what failed. This guide is the checklist I would use to hire for my own team, written from the other side of the table.
Start from the job, not from the title
Titles vary. The same work is advertised as AI engineer, LLM engineer, generative AI engineer or applied AI engineer, and in Spanish as ingeniero de IA or ingeniero de inteligencia artificial. Write down what the person will be responsible for in six months: which system, on which data, for which users, and who answers when it is wrong. A team that needs a conversational agent in production needs different evidence from a team that needs a model trained.
Ask for evidence that can be checked
A strong candidate can point to at least three of these without preparation:
- A system in production, with the population it serves and the part the candidate built.
- Code that can be read: open-source repositories, or a private project explained file by file.
- An evaluation the candidate designed, with the cases, the judge and the rule that blocks a release.
- Writing or research that shows how the candidate reasons when the answer is not known.
- A failure they can explain: what broke, how they found it and what changed afterwards.
Prefer one claim with a source over ten without. A figure such as "serves hundreds of thousands of users" should come with its scope: registered population, active users and concurrent sessions are three different numbers.
Questions that separate a demo from production
- How do you decide that a change to a prompt or a model is safe to ship?
- What can the agent do, and what stops it from doing more?
- What happens when a tool call fails or a dependency is slow?
- What is recorded about each run, and who can read it?
- What does one conversation cost, and what would double it?
Listen for mechanisms. "We test it" is not an answer. "A set of golden cases runs in the pipeline and a calibrated judge blocks the release below a threshold" is one. The guides on automated LLM evaluation and agent auditability describe what complete answers look like.
What distinguishes an expert in AI agents
An expert in AI agents talks about boundaries before capabilities. They separate what the model proposes from what the system commits. They treat evaluation as a release gate. They can say what their system does not do, and which of their numbers are measured and which are estimates. They have changed their mind in public at least once.
Certifications and years of experience help to read a profile, and they do not replace this. When a search for the best AI engineers in Mexico or in Latin America returns a list of names, apply the same test to each one: what did this person build, and where can I check it?
Practical matters when hiring in Mexico
- Working hours. Central Mexico is on UTC−6 all year, inside the working day of the United States.
- Language. For a role with a team in the United States, hold part of the interview in English, on a technical subject.
- Engagement. Senior engineers work as employees and as contractors. Decide which one the role needs before the first call.
- Seniority. Ask what the candidate owned from start to finish. A senior engineer names decisions; a junior one names tasks.
Signs to slow down
Only demos and no users. No evaluation beyond reading outputs. Every figure is round. Failures are always someone else's. "The model will handle it" as the answer to a question about a boundary.
How I answer these questions
It would be unfair to publish a checklist and not stand in front of it. My answers are public: the CV, the work on Google Cloud, the case study of an evaluation harness with 138 golden cases, the open-source repositories on GitHub and the research. Where a claim has limits, the evidence list below states them.