The developer who became available on the first day still asks what "released order" means in your operation. It's the third time someone from the team has explained it to him. The task assigned to him weeks ago is still in the same column on the board, and two of your best engineers spend part of their day translating the business.
His resume said the right things: the stack, years of experience, certifications. The technical interview went well. A person's fit within a team lives elsewhere, and that place can be observed before signing.
Where does the cost arise?
The cost of a profile that doesn't fit comes as senior hours dedicated to explaining, as code reviews that repeat the same comments, and as a timeline that moves silently. The team absorbs it without naming it, which is why it's important to detect it from the selection.
Four observable signals anticipate that fit. Each one brings a test that you can apply in an interview or in the first week of work.
1. How code written by someone else is interpreted.
Almost all the work of a developer within an existing team consists of modifying someone else's code, with conventions, debt, and prior decisions that no one documented. Reading someone else's code is the task that best predicts team performance.
The test: deliver a real, anonymized module of 200 to 300 lines with some inherited peculiarity, and ask them to explain what it does and where they would start changing it. Observe if they follow the flow of the data, if they identify side effects, if they ask about existing tests, and if they respect the conventions of the module before proposing to rewrite it.
2. How an incomplete requirement is handled.
Every requirement comes with gaps. Some developers fill them with silent assumptions, and rework appears weeks later when someone discovers that the implemented rule differs from what the business expected.
The test: present a requirement with two deliberate gaps. For example, "calculate the commission per sale" without defining what happens with returns or with sales on the last day of the month. Observe if they list their assumptions, if they order the questions by impact, if they propose a default value to move forward, and if they document the decision.
3. How a delay is communicated.
An estimate is a hypothesis, and every project adjusts it. The timing and content of the notice reveal the professional.
The test: ask them to recount a delivery that became complicated. Listen to when they notified, what information they provided (cause, new estimate, options), and what they adjusted afterward. In the first week of work, observe how they report their first blockage. An early notice, with options on the table, allows the team to decide in time.
4. How much of the business do you make your own?
Understanding the client's operation is a technical competency. The data model, validations, and edge cases arise from business knowledge: an accounting close that occurs on the 25th, a seasonal peak, a rounding rule that accounting requires. Each of those particularities ends up becoming a technical decision with business consequences.
The test: spend 30 minutes explaining a real process from your operation and ask them to recount it in their own words and point out where a system that automates it could fail. Observe if they use business vocabulary accurately and if they connect each technical decision with its effect on the operation, for example, why a process must be able to execute twice without generating a duplicate invoice.
How to use the signals.
Signals 1 and 2 are observed in the interview. Signals 3 and 4 are confirmed in the first week of work. Rate each one on three levels (absent, present with support, present independently) and invite a senior engineer from the team to the test, because the one who will work with the candidate perceives details that another interviewer overlooks.
How do we approach it?
At EmasT, the selection starts from a specific technical criterion for each team and continues with active support during integration. Behind each person, there is technical backing from the rest of the team. With AI supporting execution, the specialist directs development and validates each delivery, and for that, they need to know the business thoroughly.
The best indicator of alignment is often a silence: the question the developer no longer needs to ask because the operation has started speaking their language.
If you are adding talent to your team today, we would be happy to compare criteria.