Hiring a Qlik developer is where a generalist tech recruiter quietly fails. The CV says "Qlik" and tells you almost nothing — not which product, not whether the person builds data models or just drags charts, and not whether they can write a line of set analysis. Qlik rewards a specific engineering depth that never surfaces in a keyword search.

TL;DR: "Qlik" is two products (QlikView and Qlik Sense) and a specific discipline — the load script, set analysis, the associative engine, section access. Screen for those, not the tool name. Most estates run both products at once, so the strongest hire spans them. And Qlik skills don't transfer cleanly from Power BI or Tableau.

Why hiring a Qlik developer trips up a generic tech recruiter

The problem isn't Qlik's relevance — it's how specific the skill is. Qlik was named a Leader in the 2025 Gartner Magic Quadrant for Analytics and BI Platforms (Qlik, 2025), one of six Leaders alongside Microsoft, Salesforce, Google, Oracle and ThoughtSpot. It's everywhere in enterprise BI. But that ubiquity is exactly what makes a lazy search fail.

A recruiter who reads "Qlik" as a synonym for "BI developer" sends you dashboard-builders when you need someone who can model data and write expressions. The two are not the same person. Qlik's differentiator is its associative engine, which lets users explore every data relationship without predefined queries (Qlik, 2025). Building on that engine well is an engineering skill, not a drag-and-drop one.

The talent is also genuinely thin. Across the EU in 2023, 57.5% of enterprises that tried to recruit ICT specialists had hard-to-fill vacancies (Eurostat, 2024). Qlik sits at the specialist end of that already-scarce pool, with a smaller training pipeline than Power BI. In the Qlik searches I've run, the long-list is short before screening even starts.

QlikView vs Qlik Sense: the distinction that decides the hire

The single most useful word in a Qlik brief is which product. "Qlik" spans two of them, and they demand overlapping but distinct skills. Get this wrong in the brief and you interview the wrong people for two weeks.

QlikView is the older, developer-built product: guided analytics, where a developer designs fixed, highly-crafted dashboards (QVW documents) for end users. Qlik Sense is the modern platform: self-service, responsive, governed, and cloud-first, where users build their own visualisations on top of governed apps. Both sit on the same associative engine, but the build model, the UI paradigm, and the day-to-day skills diverge.

So a QlikView specialist knows the document model and its scripting; a Qlik Sense developer knows apps, the newer script, the API and mashup surface, and cloud governance. A CV that just says "Qlik — 6 years" could be either — or a bit of both, done shallowly. Ask which product, on which version, and for how long.

What a genuine senior Qlik developer actually looks like

Real Qlik depth lives in four places, and none of them appear on a CV: the load script, set analysis, the associative model, and section access. A paper Qlik developer arranges pre-built charts. A genuine one writes the reload that shapes the data, expressions that survive edge cases, and a model that performs at scale.

The load script and data modeling

The load script is where Qlik does its ETL — and where most of the real engineering happens. A strong developer models a clean star schema, avoids synthetic keys, knows when to use a link table, and builds incremental reloads so a refresh doesn't take hours. Ask how they'd model two fact tables sharing dimensions; the answer separates modellers from chart-arrangers fast.

Set analysis

Set analysis is Qlik's expression syntax for point-in-time and conditional aggregation — year-to-date versus prior year, ignoring or overriding user selections. It is the clearest single tell of real depth. Juniors avoid it; seniors reach for it instinctively. Hand a candidate a "same period last year, ignoring the region filter" requirement and watch whether they can express it.

The associative engine and section access

A real developer understands the associative model — the green, white and grey selection states that make Qlik feel different from a query-and-refresh tool — rather than just clicking filters. And they can implement section access, Qlik's row- and data-level security. Get section access wrong and you leak one client's data into another's dashboard. On multi-tenant work, that question alone is disqualifying if they fumble it.

Two live platforms at once: QlikView's lifecycle and the Qlik Sense shift

Qlik is not killing QlikView — it shipped QlikView 12.100 in September 2025 — but each release carries an end-of-support date, and you must upgrade to keep support. QlikView 12.90 lapses on 31 October 2026 and 12.100 on 30 September 2027 (Qlik Product Lifecycle). Meanwhile Qlik steers new development toward Qlik Sense and the cloud.

The practical consequence for hiring: most Qlik estates run both at once — a QlikView back-catalogue that still drives real decisions, plus newer Qlik Sense apps, often mid-migration. So the genuinely valuable hire spans both: someone who can keep the legacy QVWs supported and upgraded while building or converting apps into Qlik Sense.

Brief for only one and you shrink your pool for a job that usually needs both. In my experience the most common miss here is a client who scopes "Qlik Sense developer," hires one, and then discovers six QlikView documents nobody can now maintain. Name the estate honestly and the search gets easier.

Qlik vs Power BI and Tableau: does the talent transfer?

Not cleanly. Qlik, Microsoft (Power BI) and Salesforce (Tableau) are all Gartner Leaders (Qlik, 2025), so it's tempting to treat any senior BI person as a Qlik hire. They aren't interchangeable. Qlik's associative engine, its load script, and set analysis have no direct Power BI (DAX and Power Query) or Tableau equivalent.

A strong Power BI or Tableau developer can learn Qlik — but they're not a drop-in hire, because the associative model is a genuinely different way of thinking about data. Treat "five years in BI" as a starting point, not proof of Qlik depth. And the reverse is why deep Qlik people are scarce and worth holding onto: the skill is specific, the pipeline producing it is smaller, and the good ones are rarely on the open market.

If you only have budget for a generalist who'll pick Qlik up, be honest about the ramp. If the work is live and complex, hire someone who already thinks associatively.

How to brief and screen for a Qlik role

Brief four things up front and the whole search tightens: which product (QlikView, Qlik Sense, or both), whether it's greenfield Sense or legacy maintenance and migration, on-premise or Qlik Cloud, and how complex the data model really is. Then screen for the engineering, not the tool name on the CV.

Five questions that separate a real Qlik developer from a dashboard-arranger:

1. Which Qlik products have you delivered — QlikView, Qlik Sense, or both — and on what versions?
2. Walk me through a set-analysis expression you actually wrote and why.
3. How do you model to avoid synthetic keys, and how have you handled a large or slow reload?
4. How have you implemented section access for multi-tenant or row-level security?
5. Have you converted QlikView documents to Qlik Sense — what breaks, and how do you handle it?

This is exactly the kind of role where three CVs that fit beats thirty that don't. A recruiter who knows QlikView from Qlik Sense, and set analysis from chart-dragging, will out-place a volume agency on this niche every time — the full argument for that is in boutique vs volume recruitment for SAP, and it applies just as squarely to Qlik and the rest of our data & analytics work. And if the role sits upstream of the dashboards, in pipelines and warehouses, the companion guide on hiring data engineers covers that side of the practice.

Common questions

What's the difference between QlikView and Qlik Sense when hiring?

QlikView is the older, developer-built guided-analytics product (crafted, fixed dashboards); Qlik Sense is the modern, self-service, cloud-first platform. Both run on Qlik's associative engine, but the build model and skills differ. A CV that only says "Qlik" could mean either — always ask which product and version the person actually delivered.

How do you screen a Qlik developer for real skill?

Test the engineering, not the tool name. Ask them to walk through a set-analysis expression they wrote, how they model to avoid synthetic keys, and how they implemented section access. Dashboard-arrangers go vague on all three; genuine developers answer in concrete detail, because that work is where Qlik's real difficulty lives.

Why are Qlik developers hard to find?

The skill is specific and the pipeline is smaller than Power BI's, on top of a market where 57.5% of EU enterprises already struggle to fill ICT roles (Eurostat, 2024). Genuine depth — load script, set analysis, section access — takes real delivery to build, and the strongest people are usually already engaged.

Can a Power BI or Tableau developer do Qlik work?

They can learn it, but they're not a drop-in hire. Qlik's associative engine, load script and set analysis have no direct Power BI (DAX) or Tableau equivalent — it's a different mental model. Budget for a ramp if you hire cross-tool; hire an existing Qlik developer if the work is live and complex.

---

If you're hiring for Qlik and want a shortlist screened for genuine depth — set analysis, data modeling, section access — rather than "Qlik" on a CV, tell me about the role. Two to four active searches at a time. Three CVs that fit beats thirty that don't.