How Nontechnical Managers Can Interview IT Candidates Without Faking Expertise

You do not need to be the strongest engineer in the room to run a good technical interview. A manager without a deep IT background can still evaluate whether a candidate communicates clearly, makes sound decisions, understands tradeoffs, learns from mistakes, and has the depth appropriate for the role.

The mistake is pretending to be technical enough to judge details you cannot verify. Strong interviews separate what the hiring manager can assess directly from what should be delegated to a technical interviewer.

Start with the IT job description. If the role itself is vague, the interview will be vague too.

Define the outcomes before the questions

Write down what the person must accomplish in the first six to twelve months.

For example:

Reduce recurring network incidents.

Operate Azure infrastructure safely.

Improve deployment reliability.

Investigate security alerts.

Lead a data-platform migration.

Own an internal application.

These outcomes are more useful than a list of technologies because they tell you what evidence to look for.

Separate must-have capability from teachable knowledge

Not every missing tool is a hiring failure.

A strong network engineer who has not used your exact firewall brand may still understand routing, segmentation, troubleshooting, change control, and observability well enough to learn the product quickly.

A candidate who knows the product interface but cannot explain why a route fails may have the opposite problem.

Decide in advance which gaps are trainable and which are fundamental to the role.

Use a technical partner for technical verification

For roles where deep implementation skill matters, include an engineer, architect, administrator, or trusted external specialist in at least one stage.

The hiring manager should not guess whether a Kubernetes answer, security architecture, SQL design, or network troubleshooting explanation is technically correct.

Your job is to integrate that technical evidence with communication, ownership, judgment, collaboration, and role fit.

Ask candidates to explain a real problem they solved

One of the strongest questions is simple:

“Tell me about a difficult technical problem you personally helped solve. What was happening, what did you check first, what evidence changed your view, and what was the final fix?”

Listen for sequence.

Weak answers jump from symptom to solution.

Strong answers usually describe evidence, hypotheses, tests, tradeoffs, and verification.

Ask what they did—not what “the team” did

Experienced candidates naturally talk about collaborative work, but you still need to identify their contribution.

Follow up with:

What was your decision?

Which part did you implement?

What did you disagree with?

What would have happened if you had done nothing?

Which result can you directly attribute to your work?

This reduces the risk of mistaking team proximity for personal expertise.

Use scenarios that expose reasoning

You do not need to invent obscure technical trivia.

Give the candidate a realistic situation from your environment.

For a network role: “A branch can reach the internet but not a new internal service. How would you investigate?”

For a cloud role: “A production application suddenly becomes slow after a deployment. What evidence would you want first?”

For security: “An employee reports a suspicious login. What would you do before resetting everything?”

For support: “Three executives report intermittent video-call failures. How would you avoid treating each ticket as unrelated?”

You can evaluate whether the candidate structures the problem even if a technical interviewer validates the details.

Look for evidence before action

Good IT professionals usually want to establish what is actually happening before making disruptive changes.

A candidate who immediately proposes rebooting servers, disabling security controls, replacing hardware, or changing production configuration without collecting evidence may create operational risk.

The troubleshooting methodology is a good example of the behavior you want: symptoms lead to hypotheses, tests, isolation, correction, and verification.

Ask about failure

“Tell me about a technical decision you got wrong.”

This question reveals more than a polished success story.

Look for:

Ownership rather than blame.

Evidence of what they learned.

A change in process afterward.

Understanding of customer or business impact.

Willingness to surface problems early.

A candidate who claims never to have caused an incident is usually giving you less useful information than one who explains a mistake precisely.

Ask how they handle change safely

IT work is not only configuration. It is controlled change.

Ask:

How would you test this?

What would you monitor?

What is the rollback plan?

Who needs to approve the change?

What evidence would prove success?

This distinguishes someone who can operate production systems from someone who only knows how to make settings change.

Evaluate communication by asking for two versions

Ask the candidate to explain the same technical issue first to an engineer and then to an executive.

A strong candidate changes vocabulary and detail without changing the truth.

Technical teams need mechanisms, logs, dependencies, and evidence. Executives may need business impact, options, risk, cost, and a decision.

The ability to move between those levels is especially important for senior roles.

Use role-specific depth signals

For a network engineer, depth may appear in routing behavior, packet flow, failure isolation, redundancy, and change control.

For a cloud engineer, listen for identity, networking, compute, storage, automation, monitoring, reliability, security, and cost.

For a cybersecurity analyst, look for evidence handling, log analysis, triage, scope, escalation, and incident reasoning.

For a developer, look for source control, testing, debugging, code review, deployment, data handling, and maintainability.

Do not use certifications as a substitute for evidence

A certification can show structured learning or validate a defined body of knowledge. It does not automatically prove production skill.

Ask certified candidates to connect the credential to work they can demonstrate:

What did you build?

What did the certification change in how you work?

Which exam domain was hardest to apply in real life?

What have you learned since passing?

Do not reject candidates for not knowing internal jargon

Every company develops abbreviations, architecture nicknames, and tool-specific language.

Judge whether the candidate understands the underlying concept. They can learn your naming conventions after joining.

Ask candidates to challenge a bad requirement

Give them a request such as:

“The business wants every administrator to have permanent global access because approvals take too long.”

or:

“We want to deploy every change directly to production so releases move faster.”

The best answer is not simply “no.” Look for someone who identifies the risk, understands the business pressure, and proposes a safer alternative.

Score evidence, not charisma

Create a structured scorecard before interviews begin.

Useful categories include:

Relevant technical depth.

Troubleshooting and reasoning.

Ownership.

Communication.

Security and operational judgment.

Learning ability.

Collaboration.

Role-specific outcomes.

Define what strong, acceptable, and weak evidence looks like. This reduces the influence of confidence, similarity, and first impressions.

Avoid trivia unless trivia is the job

Questions such as “name every TCP flag” or “what exact command does X” may test memory rather than capability.

If the role genuinely requires instant recall of a specific fact, test it. Otherwise, use problems that reveal whether the candidate can reason and find the correct answer safely.

Use a practical exercise with clear boundaries

For some roles, a short practical task is more useful than another hour of conversation.

Examples:

Review a small configuration and identify risks.

Debug a controlled application failure.

Explain a simple architecture diagram.

Write a short script.

Analyze a small log sample.

Prioritize several support incidents.

Keep the task proportional and do not ask candidates to perform unpaid production work.

Close gaps with references and work samples

If an interview leaves uncertainty about a candidate’s level, use references, portfolios, code samples, architecture examples, or a second technical conversation to validate the area rather than guessing.

A nontechnical manager can still run an excellent process

You do not need to know more technology than the person you are hiring. You need to know what outcome the role owns, which skills must be verified, which evidence matters, and when to bring in technical expertise.

The strongest interviews make candidates explain how they think, how they act when uncertain, how they protect production, and how their decisions create useful outcomes. That is management judgment—not technical theater.