How to interview for a role you have never done

Interview for a role outside your own background by shifting what you test: instead of judging technical correctness you cannot judge, test how the candidate reasons, communicates, and handles the parts of the job that touch your own work. Prepare with the job description and one short conversation with a subject expert, ask questions that expose process rather than vocabulary, and bring in a technical partner to score the parts you genuinely cannot.

This comes up more than job descriptions admit: a marketing lead hiring a data analyst, an operations director hiring their first security engineer, a founder hiring a controller. You are not going to become qualified to evaluate the craft in one prep session, and pretending otherwise is how unqualified candidates get hired on confident-sounding jargon. The fix is not to fake expertise. It is to interview for the things you can actually assess.

What you can and cannot judge, and why that split matters

Split the role into two kinds of evidence before you write a single question. The first kind is evidence you can judge directly: how the candidate explains their reasoning, whether their story holds together under a follow-up question, how they handle disagreement, what they prioritized and why, how they communicate with people who do not share their expertise. You do this every day in your own function. The second kind is evidence that requires domain knowledge to judge: whether a specific technical choice was correct, whether a number is realistic for the field, whether a tool or method is current practice.

Most hiring managers in this position try to fake their way through the second kind, nodding at answers they cannot actually evaluate, or they avoid the technical content entirely and hire on likability. Both fail. The better path is to interview hard on the first kind yourself, and get a second, structured opinion on the parts you cannot judge from someone who can.

Before the interview: a 30 to 45 minute prep routine

1. Read the job description for verbs, not nouns. Nouns are the tools and jargon you don't know. Verbs tell you what the person actually does day to day: diagnoses, forecasts, negotiates, builds, reconciles, escalates. Write down the five verbs that matter most for this role. Those verbs become your questions.
2. Get 20 minutes with a subject expert before you write questions, not after. Ask them three things: what separates a strong performer from a mediocre one in this role, what a weak candidate says that sounds fine to a non-expert but is actually a red flag, and one question they would ask that a bad candidate could not fake. Write their answers down; you will use them.
3. Ask for two work artifacts, not a resume summary. A report, a dashboard, a document, a piece of code, a campaign brief, anything the candidate produced. You do not need to judge whether it is technically excellent. You need the candidate to walk you through it, which tests something you can judge: can they explain their own work clearly to someone outside the field.
4. Decide, in writing, which sections of the scorecard are yours and which belong to a technical partner. Do this before the interview, not after you've heard the answers and formed an impression you then have to justify.

Questions that work without domain expertise

These test process, judgment, and communication, the parts of the role you are qualified to score regardless of the field. Each has what a strong answer sounds like and a red flag to listen for.

Reading an answer you can't technically verify

You cannot check whether a technical claim is true. You can check whether it behaves like a true claim, and four patterns hold up across fields.

• Specificity. True claims come with numbers, names, timeframes and constraints. "We improved performance significantly" is unverifiable by design. "We cut it from 40 seconds to 6 by removing a redundant call, over about three weeks" is a claim someone could check, and people who are describing real work tend to reach for that kind of detail without prompting.
• Consistency under a follow-up from a different angle. Ask about the same claim twice, in different words, five minutes apart. A rehearsed or fabricated answer often shifts in small, telling ways. A real memory usually holds, even if the phrasing changes.
• Willingness to name the limits. Ask what didn't work, or what they'd do differently. Someone who actually did the work has an answer immediately, because real projects have rough edges. A vague or defensive answer here is worth more than the confident parts.
• The teach-back test. Can they explain it to you, a non-expert, in a way that makes sense? This is not a test of your understanding of the field; it's a test of whether they understand it well enough to translate it. People who only pattern-match jargon usually cannot.

Bringing in a subject expert without losing the decision

A technical partner adds signal you cannot generate yourself. It only works if you keep the decision, not just the vote, with the hiring manager.

• Brief them narrowly. Tell them exactly which competencies they're scoring and which ones are yours. "Score technical depth and tool judgment; I'm covering communication, prioritization and fit with the team" keeps their input focused instead of a general impression.
• Ask for evidence, not a verdict. "What did the candidate say that supports a 3 versus a 4 on technical depth" produces something you can use in the debrief. "Yes, hire them" does not, because you cannot interrogate a verdict you weren't in the room to evaluate.
• Sit in on at least part of their round if you can. You won't follow the technical content, but you'll see how the candidate handles a harder, more specific line of questioning than you can ask, which is itself useful evidence about their composure and honesty under pressure.
• Do not let a strong technical score override a real concern from your rounds. A candidate who is technically excellent and evasive with you is a manageability problem you will own, not the technical partner.

A scoring rubric for the parts you own

Use this alongside, not instead of, your technical partner's scorecard for their sections.

A worked example

Invented, to show the split in practice: Marisol runs a small operations team and is hiring her first security engineer. She doesn't know the field. Her prep call with a security contractor at a partner company gave her one question: "walk me through how you'd decide what to patch first when you can't patch everything this week." The contractor told her a strong answer references some form of risk-based prioritization (what's exposed, what's exploitable, what's actually running); a weak answer just says "the critical-rated ones" without explaining what critical means in their process.

In the interview, the candidate answered fluently and used the phrase "risk-based approach" immediately. Marisol asked him to walk her through it with a made-up example: two vulnerabilities, one rated higher, which does he patch first. He explained that the lower-rated one was on an internet-facing system actively being scanned, so it went first despite the lower score, and gave a specific past example of the same tradeoff. That is the specificity and teach-back pattern working: Marisol could not judge the security content, but she could judge that the explanation was real, adapted to her example, and held up under a follow-up. She scored him a 4 on plain-language explanation and specificity; her technical partner separately scored the security judgment itself.

Mistakes hiring managers make in this situation

Your checklist before this interview

• You've pulled five verbs from the job description that describe what the role actually does.
• You've had a 20-minute call with a subject expert and written down their strong-answer and red-flag signals.
• You've asked for two work artifacts the candidate can walk you through.
• You've split the scorecard: which competencies are yours, which belong to a technical partner.
• You've told the candidate your background isn't in this field, early in the conversation.
• You have at least one question borrowed directly from your subject expert.
• You know, before the debrief, that you won't let a strong technical score override a real concern from your own rounds.

If you run several of these interviews a year, preparing hiring managers before interviews is worth doing as a standing habit rather than rebuilding this routine each time. Interview Signal builds a live question guide from the job description before the call, so the prompts above show up as a checklist you tick off in the moment rather than something you have to remember mid-conversation.