The hire everyone says is “impossible”
A fintech in Warsaw asks for a senior data engineer who also understands payments compliance. Someone who can build transaction pipelines and translate requirements from the risk team into data checks.
The TA lead has a feeling this person barely exists. The CFO has a start date in mind. The hiring manager says “just find them.”
Before committing to the search, bring a first market snapshot to the planning meeting. Show which experience you found, what remains unclear and which responsibilities the existing team could cover.
Talent market mapping can help with that decision. For this exercise, the output is a short, dated record of the profiles you reviewed, the experience they describe and the questions still open. Combined with a check of your internal team’s capacity, it helps you compare ways to cover the work.
The Warsaw company and hiring brief are hypothetical. The profile examples come from an actual Wandify search run on 16 October 2026, shown in the screenshot below.
Step 1. Write the decision, not the search
Put one question at the top of the document:
“Should we hire one person to own both the data pipelines and the compliance logic, or split the two?”
Then write down what evidence would change the answer. For this role, you need to know whether profiles show people doing both kinds of work, and whether your existing team could cover one half. The market cannot answer the second part. Someone has to ask the head of risk.
Keep three routes in view for the whole exercise:
- Route A. One specialist who has done both.
- Route B. A data engineer, supported by your compliance team.
- Route C. A risk analyst who defines and tests the data checks, with an existing data engineer responsible for building and maintaining the pipelines.
These are options to compare, not predictions about which is cheapest or fastest.
Before you open a single profile, agree on what would rule a route out. If nobody in the company can support Route B, it is not a real option, however many engineers you find. More search results will not fix that.
CIPD’s July 2026 piece on workforce intelligence argues for the same habit: test your assumptions against a few plausible scenarios instead of defending the first plan.
Step 2. Run the search and save what you find
In Wandify AI Search, describe the experience in plain language, the way you would explain it to a colleague:
“Data Engineer, Poland, payments or banking pipelines, worked with compliance, AML or fraud teams”
Start with Poland as the location and, for the engineering routes, Data Engineer as the title filter. Wandify’s AI Search guide recommends starting with one or two filters. Record this as an engineering search: it cannot fairly test Route C, which needs a separate search for risk analysts. If the wording itself needs work, turn the job description into a sourcing brief first.
Skim the results and save the relevant profiles to a new folder. Name it so a colleague can find it later: Market map: payments data engineer, Poland, Oct 2026.
Save the source profiles in the folder and link them from your notes so a colleague can check your reasoning.
Wandify helps you discover and organise profiles. Review the full profiles before drawing conclusions about experience; confirm interest, availability and salary expectations in conversation.
Step 3. Make it reproducible
Write down, right at the top of your notes:
- the date you searched
- the tool and the exact query
- the location and any filters
- how you picked which profiles to read (all of them? the top 30?)
A sample taken from ranked results shows what that search surfaced. It does not describe everyone in Poland with this background. Say so in the notes.
Two small rules save arguments later:
- A profile’s location is not willingness to relocate or commute. Keep those in a separate column marked unknown.
- If a profile is too thin to judge, write “insufficient information.” Do not count it as a match, and do not count it as proof that the skill is missing.
Remove duplicates before you report a number. And keep the meeting version anonymous: grouped findings and a few unnamed examples, not a wall of names.
Step 4. Write each finding in three parts
For every pattern you notice, record:
- Observation: what the profile actually says.
- Interpretation: why it might matter for one of your routes.
- Next check: what you would need to confirm before relying on it.
Here is what the search actually returned for the Warsaw brief.
These three records come from the top of a real Wandify search run on 16 October 2026: the query above, filtered to Poland and Data Engineer. The screenshot shows the search results; the records below omit names and employers. The observations refer to the visible cards, with fuller experience left for the next check.
Record A.
Observation: a profile headlined “Data Engineer | PySpark | AWS” shows four years as a big data engineer at a global consulting firm. The card mentions no payments, banking or compliance work.
Interpretation: worth reviewing for the engineering work in Route A or B. The card alone does not establish project depth or domain experience.
Next check: open the full profile and ask whether any client work involved regulated financial data.
Record B.
Observation: a profile headlined “Big Data Expert | Spark & Scala Specialist” shows a senior big data engineer role at a large European bank since March 2022, with Kafka, Scala and Hadoop among the skills. The card says nothing about AML, fraud or compliance teams.
Interpretation: the banking context makes this a useful profile to investigate. Working at a bank does not establish responsibility for payments pipelines or compliance-related data checks.
Next check: what the bank’s data work covered, and whether this person worked with risk or compliance colleagues.
Record C.
Observation: a profile headlined “Data Engineer & Cloud enthusiast” shows a data engineer role at a pharmaceutical company, with Kafka and Scala in the skills list and no further detail.
Interpretation: insufficient information to assess the domain requirement. Experience from earlier roles or projects may be missing from the card.
Next check: review the full work history. If it adds no relevant detail, leave the domain experience unconfirmed.
Read the three together. They show why card-level information can leave a requirement unresolved. They do not establish that the combined role is rare or that Route B is better. Review full profiles, try alternative search wording and investigate the open questions before recommending a route.
In your own map, link each observation to its source and note when you checked it. Record whether the evidence came from a result card, a full profile or a conversation.
Step 5. Don’t mix up different sources
Job adverts show how employers describe related work. Keep them separate from professional profiles. In its UK Textkernel methodology, the ONS explains that an online advert may cover multiple positions or a speculative opportunity. That is a useful caution when reading advert counts, not evidence about demand for this role in Poland.
For the same reason, do not divide profiles by adverts and call the result “candidate availability.” Different sources, different coverage, different update cycles.
If pay could change the decision, get a proper salary check from a source built for that. If relocation matters, ask people. Until then, leave those cells as “unknown.” An honest blank is more useful than a confident number borrowed from a different role.
Step 6. Bring a recommendation with conditions
Summarise the map by route: what the profiles support, what internal help it needs, and what could stop it.
For the Warsaw hire it might read:
“Keep Routes A and B open. We still need to confirm whether the profiles reviewed include both pipeline delivery and compliance-related data work. Route B is viable only if the risk team can define and validate the rules while the engineer owns the pipelines. Next step: the CTO and head of risk agree that split, and TA checks the unresolved experience before recommending a route.”
That is a conditional proposal, not a promise that the role will be easy to fill. If the combined role is non-negotiable, say what extra research you would need first, and set a review date tied to the next business decision. Don’t invent a “right” sample size or a time-to-hire.
Copy this one-page template
| Field | What to write |
| Decision required | What must leadership decide before approving the hire? |
| Work to cover | What must the person own, and what can colleagues support? |
| Research boundary | Tool, date, geography, query, filters, how profiles were picked, duplicates removed |
| Observed patterns | What profiles say, grouped by responsibility and location |
| Hiring routes | A, B, C, or your own |
| Conditions per route | Internal support needed, constraints, evidence still missing |
| Unknowns | Pay, interest, availability, mobility, real technical depth |
| Recommendation | Which route to explore next, and what would change your mind |
| Owner and review date | Who resolves the open question, and before which decision |
Where this leaves you
A useful market snapshot gives the hiring manager something concrete to discuss: which experience you found, what remains unconfirmed and what support each hiring route would require.
Try it on your next hard role. Run the search in Wandify, save the profiles to a folder and fill in the template. The interpretation and the final call stay with your team.
