Gary Davies
At Data Intellect we focus our training on fundamental understanding, engineering and applied use of AI. This is underpinned by the core consulting skills focusing on the ability to communicate effectively and deliver in fast paced environments.
As a consultancy, interviewing is a critical part of our day-to-day and it takes on three forms:
- External interviews, meeting the kdb+ demand from the market
- Internal interviews, part of learning, developing and preparing for a client role
- Client interviews, consultants going forward for roles
In the last year we have conducted over 500 internal interviews, over 100 external interviews and been part of approximately 100 client interviews.
This blog explores three shifts: what we ask, how we ask it, and where it goes next. Along the way it looks at the influence of AI and hypothesises what comes after.
Walk into a kdb+ interview and there is a very good chance you will be asked about attributes. It is the most common question across the board, and you can understand why. It is one of the fundamentals, and it poses a design, performance, experience and knowledge test all in one. It also works irrespective of seniority, with the detail in the answer providing the means of assessment.
Attributes may be the most common question, but there is a wider pool that makes up the interview fundamentals: attributes, tick architecture, enumeration, IPC, joins, functional selects and slow subscribers. Combined they show whether someone understands how kdb+ actually works, and the basic architecture and issues that come off that setup.
That core is the anchor for everything that follows, it remains a static feature while the world around it changes.
Total recall is dying
Unlike Arnie, I don’t see this coming back. There has been a decline in what could be described as quick-fire language trivia, examples being reciting each of the internal functions (-9!, -25!, -30!) or recalling what a particular .Q does.
Back when I first started out in 2010, I had a battered copy of q for Mortals and the original code kx site. As we’ve progressed to 2026 the volume of kdb+ content has significantly increased, and AI is becoming increasingly better at kdb+. AI was able to tell me there are well over 1000 git repositories linked to kdb+.
Recall doesn’t have to be as simple as a reference card, though. I spent some time with KX’s own Ask AI (a fantastic new addition) and asked it something a developer would be interviewed on; how to replay a tickerplant log into an in-memory table.
It answered accurately, and as with any interview I presented a follow up including constraints and a modified requirement – the AI adapted, filtering the replay and flushing to disk in chunks. That is worth noticing, the tool is doing the applied reasoning we used to reserve for the interview itself. If the how is a question away, the value in asking someone to produce the how drops with it. You can see the conversation below.
Recall may be dying, but application is very much alive, as is the core we’ve already discussed. The internals now tend to surface inside questions on gateway design, use cases, or the core topics above. You might not need to remember -30!, but you will need to understand deferred response and why it matters in gateway design and IPC within an application architecture.
Real-world application in the here and now
Strip back the theory and the recurring themes and you are left with questions rooted in the real issues facing teams, the architecture challenges and the things breaking in production.
This doesn’t surprise me. It has been a feature of how I have interviewed for years. If I am facing a design decision, or have recently had a prod outage, I would use it to my advantage in an interview. It gives the candidate something current to work with, and lets them lean on their experience to solve it. I like these questions because they spark conversation and debate, and you see the problem solving shine through. Occasionally you get a solution you hadn’t thought of, a happy by-product. You see the engineer beneath the candidate.
These have evolved too. You are now less likely to be asked to replay a tickerplant log (as witnessed above), and more likely to have to deal with a WDB failing mid-write.
Interviews show the kdb+ role is fragmenting
In an AI era I would be remiss not to have AI analyse this blog and the data behind it. Its summary on this point was that the kdb+ specialist is becoming the kdb+ plus engineer, and I couldn’t put it more succinctly.
kdb+ interviews used to focus on the technology, with perhaps some unix given the deployment environment. There are still fully kdb+ centric interviews, but in 2026 there has been a clear rise in questions around python, airflow, docker, kubernetes and beyond. You can see why: the deployment environment has shifted to hybrid infrastructure, there is a constant need for scale and stability across huge data volumes, and the system has to interoperate with the world around it. kdb+ has been a stalwart in finance for over twenty years, but that world has changed, think cloud, containerisation, and the move from monoliths to microservices.
I would also be remiss not to flag the rise in questions on AI usage and application in the kdb+ space. That will only grow as the models and adoption grow. It is no accident that Data Intellect is so focused on AI enabling our engineers. We are preparing for the kdb+ engineer of the future.
Which way is this heading
Step back and the direction is clear. Content has moved from what you can recall, to what you can apply, to how widely you can operate across the stack. Each shift tracks the last, and none of it is slowing.
Where it is also accelerating is in the direction of AI, with questions beginning to focus on how people are leveraging it in their software development cycle. That being said AI, at least right now, feels more like the elephant in the room as interviews look to minimise the potential of AI involvement.
Interview formats have varied over the years, but as we head into the winter of 2026 it is safe to say live-coding is becoming a new standard for kdb+ interviews. It has always had a place, but it was never as prevalent as it is now. If I had to hypothesise why, I would say AI.
I have never been one for live-coding interviews myself, preferring to interrogate experience and the application of fundamentals. But over the last twelve months I have sat in a few that left me feeling AI had played a significant role. Live-coding doesn’t remove that possibility, but it does narrow it, especially when someone is screen sharing and talking through their thinking at the same time.
There is a logic to it. If AI can answer the how, then watching someone work in real time is one of the few ways left to see how they actually think. Live-coding is, in part, a defensive move: it narrows the room for an AI-assisted answer. Which raises the obvious question. If we are designing interviews to keep AI out, are we testing for the right thing?
Where this goes next
Bring AI into the room
If interviews evolved to assume folks can google, we should now assume the same folks can Claude (other models are available, but this one verbs better). In 2026 they should assume you can reach for a model. So rather than design around AI, the more interesting path is to design with it, bring the elephant into the room, and adjust expectations accordingly.
Here is a version I have been debating. Give the candidate a small board of tasks, let them pick one, and solve it in a set time using whatever AI they would use on the job. Then sit with them and have them walk you through it. Think back maybe ten years when kdb+ homework assignments where prevalent. Nobody watched over your shoulder, but you owned the approach and the solution, and you could explain it. This would be the kdb+ homework assignment returning, AI-era. In an AI world you stand over the solution as if it were your own: explainable, maintainable, and yours to defend.
From writing code to reviewing it
Follow that thread and what you are really assessing shifts. If the model writes the first draft, the skill on show is judgement. Can you read what came back, spot where it is wrong, and know what good looks like? We may end up assessing the review of code more than the writing of it, which, given the actual day job, is no bad proxy. Generating a query is cheap now. Knowing whether to trust it is not.
The core still holds
None of this retires the fundamentals. Attributes, tick architecture, IPC, the core we opened with is still the core, and there is still room for the experience-led questions that let good engineers show their range. Interviews need variation, both to assess accurately and to give the candidate the best chance to show their skillset and experience.
What changes is the emphasis. Less grinding the reference guide, more explainable, rounded engineering. The kdb+ specialist is becoming the kdb+ plus engineer, and the interview is evolving to assess that.
That’s where I’ll leave it for now, as my pondering and planning continues offline, however I’d like to leave this blog with some questions I’d love input on
- Do these changes align with what you are seeing?
- How do you see interviews changing?
- Have you brought AI into an interview yet? Did it unlock insights about the candidate?
- Are we right to treat live-coding as a way to keep AI out?
The fundamentals aren't going anywhere, but the interview around them is being rewritten, so the real question is whether we rewrite it deliberately or let AI do it for us.
Share this:
