Every DBA and PowerShell engineer who has ever changed jobs has sat through the same screening call. A recruiter, working from a script that was written for a generic "IT professional" requisition, reads out questions that were never designed to tell anyone whether the candidate can keep a production database online. What follows is a field guide to the worst offenders, why they measure nothing, and what a hiring manager should ask instead.
"On a Scale of 1 to 10, How Would You Rate Your SQL Skills?"
This is the single most common question in technical screening, and it produces the single least useful answer. A candidate who has spent five years fixing other people's index strategies will say "7" out of professional humility. A candidate who wrote one SELECT statement in a bootcamp will also say "7," because 7 sounds confident without sounding arrogant. The number is not a measurement, it is a social performance, and every candidate has learned to perform it the same way.
Worse, the scale has no anchor. A 7 out of 10 in query writing means nothing next to a 7 out of 10 in index tuning, execution plan reading, or AlwaysOn failover design. Nobody defines what a 10 looks like, so nobody's 7 means the same thing as anyone else's.
"How Many Years of Experience Do You Have With SQL Server 2022?"
SQL Server 2022 released in November 2022. A requisition asking for "5+ years of SQL Server 2022 experience" is not rare, it is the default template with the version number swapped in by whoever last edited the job posting, and nobody checked whether the arithmetic still worked. The honest answer is a number the calendar makes impossible, and the honest candidate who points that out on the call has, in a lot of shops, just talked themselves out of the role for being "difficult."
The underlying mistake is treating version number and calendar time as a proxy for depth. A DBA who ran SQL Server 2016 in production for six years and migrated it to 2022 last quarter knows more about 2022's real-world behavior than someone counting months since a specific major version GA date.
"Are You a Team Player?"
Nobody in the history of interviewing has answered "no" to this question. It is not a filter, it is a formality, and both sides know it going in. Asking it wastes a slot in the call that could have gone to something that actually discriminates between candidates.
"Where Do You See Yourself in Five Years?"
For a production DBA role, this question is answered correctly by "still able to restore a database at 3 a.m. without panicking" and incorrectly by whatever career-ladder fiction the candidate invents to sound ambitious without sounding like they'll quit in eighteen months. It measures storytelling ability, not database administration ability, and the two are only loosely correlated.
"Do You Have Experience With Big Data, Cloud, and AI?"
Strung together like that, the question is really three unrelated questions wearing one trench coat. "Big Data" could mean Hadoop, could mean a 200 GB table that someone once called "big," could mean nothing at all. "Cloud" could mean Azure SQL Managed Instance, could mean an EC2 box someone installed SQL Server on and called it a migration. "AI" in a DBA req usually means "have you used Copilot," not "have you built a model." None of these terms is specific enough to answer without first asking the recruiter what they actually mean, and most candidates don't get the chance to ask before the next scripted question arrives.
"Why Should We Hire You Over Other Candidates?"
The honest answer requires knowing who the other candidates are and how they compare, information no candidate has. What actually gets said is a rehearsed pitch that would be identical regardless of who else applied. It's a confidence test wearing a comparison question's clothes.
The Salary History Question
Illegal to ask outright in a growing list of jurisdictions, and not much more useful where it's still legal. Past salary reflects a past employer's budget, location, and internal pay bands, not the market value of the skill being hired for today. It anchors negotiation downward for candidates who were previously underpaid and tells the hiring manager nothing about whether the person can run a restore test or diagnose a blocking chain.
What These Questions Have in Common
| Question | What it's supposed to measure | What it actually measures |
|---|---|---|
| "Rate your SQL skills 1-10" | Technical proficiency | Willingness to self-report a socially acceptable number |
| "5 years with a 2-year-old product" | Depth of hands-on experience | Whether the job posting was proofread |
| "Are you a team player?" | Collaboration fit | Whether the candidate knows the expected answer |
| "Where do you see yourself in 5 years?" | Ambition and retention risk | Storytelling ability |
| "Big Data / Cloud / AI experience?" | Modern skill coverage | Whether the candidate will nod along to undefined terms |
Every entry in that table shares one root cause: the question was written to be asked, not to be scored. There is no wrong answer that a screener without a technical background could actually recognize as wrong, which means the question does no filtering work at all. It fills fifteen minutes of a call and produces a transcript, not a signal.
What to Ask Instead
A technical screen doesn't need to be adversarial or take an hour. It needs to ask about specific, checkable things a working DBA or PowerShell engineer would encounter on the job, where the answer reveals depth or its absence within a sentence or two.
| Instead of | Ask |
|---|---|
| "Rate your SQL skills 1-10" | "Walk me through how you'd find out why a specific query got suddenly slow." |
| "5 years with SQL Server 2022" | "What's changed for you in how you tune indexes over the last five years, regardless of version?" |
| "Are you a team player?" | "Tell me about a time you disagreed with a developer's schema design. What happened?" |
| "Where do you see yourself in 5 years?" | "What's a production incident you were on-call for, and what did you actually do first?" |
| "Cloud/Big Data/AI experience?" | Name the specific platform and workload in the job, and ask about that. |
Every question on the right side of that table has a wrong answer. That's the whole point of a screening question: it should be possible to fail it, specifically enough that passing it means something.
The Bottom Line
None of this is a case against HR or recruiters generally. Sourcing, scheduling, and running a fair, consistent process across dozens of candidates is real, difficult work, and most of the questions above exist because someone downstream, usually a hiring manager, handed over a template and never revisited it once a technical lead was in the room to help calibrate it.
A screening question is only doing its job if a wrong answer is possible and recognizable. If every candidate can pass it by saying the expected thing, it isn't screening for anything, it's just filling time on the call.
The fix costs fifteen minutes: get a technical lead to write or review the actual screening questions before the requisition goes out, anchor each one to something checkable, and retire anything that can be passed by guessing the socially correct answer. The candidates get a call worth their time, and the hiring manager gets a signal instead of a transcript.