How mrkd hires — the three questions that tell us everything

We do not hire the way most agencies hire. We do not filter on tenure, degrees, previous employers, or the length of the resume. Those are lagging indicators of things we care about, at best — and at worst they are noise that hides the signal.

The signal is what someone has built, how they built it, and how they talk about the work now that it is done. Everything we ask in an interview is designed to surface that signal in the shortest honest conversation we can hold.

Here is how we do it.

What we deliberately don't hire for

Naming what we ignore is the fastest way to explain what we look for. We do not hire on:

• Tenure. Five years at a well-known agency tells us the person survived five years there. It does not tell us what they shipped or how they thought about it. We have hired people three years into their career who are better than people fifteen years in, and we have passed on senior candidates who could not explain the reasoning behind a single piece of their work.
• Degrees. We do not require one, we do not weight one, and we do not ask about one until it comes up naturally. Some of the strongest people we have hired studied something other than software. Some studied it and are excellent. Neither correlates with the work they ship for us.
• Prestige employers. A famous logo on a resume tells us someone passed that company's hiring bar. It does not tell us they were the reason the work was good. Reality is that most people at any large company did one small part of a much larger system.

None of the above are disqualifying — we just do not use them as positive signals.

Portfolio is the one thing we do look at closely. It is the starting point of every interview — the artefact that proves the work exists. But a portfolio on its own is not enough, and this is the honest reason: a beautiful portfolio can be built by someone who did the work brilliantly, and a beautiful portfolio can also be built by someone who was standing next to it. From the outside, those two portfolios look identical.

That is why we do not hire on the portfolio alone. We use it as the map, and then we walk it together. Three questions do the walking.

The three questions we ask every candidate

Every interview at mrkd is anchored on three questions. They are plain-spoken, they take about an hour to work through together, and they surface more real signal than any structured competency framework we have ever tried.

1. "Walk me through what you've actually built."

We open the portfolio together and we unfold it. Project by project. For each one: what was it, who was it for, which part of it was yours, what did you decide, and how did it end up.

This is the question that separates the person who did the work from the person who was in the room while it happened. We have seen both. We have seen resumes and portfolios where every project is impressive — logos, screenshots, awards — and the candidate cannot explain how any of it was built when we walk through it. We have also seen modest-looking portfolios where every project opens up into real decisions, real trade-offs, and a person who clearly drove the work.

The portfolio is the map. The walk-through is the terrain. From the outside those two candidates looked the same. Ten minutes into this conversation, they never do.

The signal is not perfect — some people are simply better at talking about their work than doing it, and some are the reverse. But taken together with the two questions that follow, it is the most reliable indicator we have found. We are not looking for volume. Some of the best people we have hired have shipped five things in five years. What we look for is that they can talk about the work like it is theirs — the specific decisions, the trade-offs, the parts they would change if they built it again.

2. "What's the hardest thing you've built — and what nearly broke it?"

This is the question that separates the people who have really built things from the people who have been near people building things.

The right answer is specific. A real problem, a real constraint, a real point where the project could have failed, and the decisions the candidate made to hold it together. Bonus signal if they can describe the mistake they made before they got it right — because that is the person who is still learning.

The wrong answer is a smooth story with no rough edges. Software that has been genuinely hard to build always has rough edges. If the candidate can only describe smooth curves, they were probably not driving.

We watch specifically for three things in this answer:

• Problem-solving. How did they decompose the problem? Did they isolate what was actually hard, or did they treat everything as equally difficult?
• Judgement. Which trade-offs did they make, and can they defend them a year later? Or has the reasoning gone stale?
• Self-awareness. Do they know which parts of the work were their strongest and which were carried by someone else on the team? Honesty here is a strong positive signal. Everyone has weaker parts.

3. "What are you most proud of — and why?"

The one that tells us who the person actually is.

The answer to the first two questions can be prepared. The answer to this one, usually, cannot. What a person is proudest of is a window into what they value, how they see their own work, and what kind of craft matters to them.

The specific project is not what we listen for. It is the why. Some candidates are proudest of the technically hardest thing. Some are proudest of the piece of work that helped a colleague grow. Some are proudest of a small, unshowy piece of work that solved a real problem elegantly. All of those can be great answers. What is telling is whether the why is coherent, specific, and honest.

If the candidate has no answer, or the answer is generic ("I'm proud of everything I ship"), that is also information.

What we watch for underneath the answers

The questions are the vehicle. What we are actually reading is four things across the conversation.

Craft. Do they care about the details of the work? Do they notice the same things we notice — spacing, empty states, error handling, the small kindnesses that separate professional software from software that just runs? Craft shows up in how they describe things they are proud of, not just what they list.

Problem-solving. Given a real constraint, do they decompose, scope, and prioritise? Or do they build until something works, without a model of why? We are looking for the first, at every seniority level.

Communication. Can they describe a decision in plain English, without technical jargon covering for a fuzzy answer? Can they disagree with something we say, in real time, without becoming defensive? A candidate who cannot tell a client "we should not build that yet" will not tell us either.

How they think, out loud. We ask follow-up questions that force a real-time judgement. "You mentioned you chose X — would you still choose X today? What would change your mind?" The best candidates update their model in the conversation. The weaker ones hold their ground because they said it, not because they believe it.

What the interview does not include

The specifics of what we skip, because it is not incidental:

• No Leetcode-style problems. We are hiring people who build software, not people who memorise algorithms.
• No unpaid multi-day take-homes. We may ask for a small piece of work, but it is small on purpose, and we compensate for anything more than an afternoon.
• No panel of eight. The people who interview a candidate are the people who would work with them. That is at most four.
• No trick questions. If a question is testing something, we are transparent about what it is testing. Games do not surface craft.

What this means for clients

The client-facing version of "we have a high hiring bar" is usually vague marketing. Ours has three specific outcomes.

The person in your kickoff is the person doing the work. We hire practitioners whose judgement we trust, then we put them on the client call. There is no PM layer translating for a hidden delivery team.

Fewer people, more coherent output. A small team of people who have all cleared the three questions above produces more consistent work than a large team where the average is being defended.

When we say no, we mean it. Because our hiring bar does not move with the project pipeline, we will occasionally say no to work we cannot staff correctly. That is not a virtue we invented — it is the only honest way to keep the bar in place.

The answer

Tenure, degrees, and prestige employers are not what we hire on. What someone has built, how they built it, and what they are most proud of — those three answers tell us everything we need to know about whether they belong on a mrkd project.

If you want to see what our hiring bar produces on real work, send us a short brief. We reply within one business day.