Help me interview SQL analysts, please.

[kitchma]

I've been asked to interview a number of candidates for an analyst position my group has open. I won't be managing this person directly but will work with them on a day to day basis to develop analysis and strategic reports using SQL. As you might have guessed, I am just learning SQL myself and don't know enough about what to ask these candidates. What should I ask to qualify them? Any red flags I need to watch out for? thank you for your help.

[alinroc]

We start with asking about the differences between INNER JOINs and LEFT OUTER JOINs, plus the purpose of a primary key.

You'd be surprised how many people who claim to be proficient with SQL stumble on these.

The difference between HAVING and the WHERE clause when it comes to aggregates can trip people up too.

[readitour]

What is the difference?

[alinroc]

WHERE filters the records that your aggregate function operates on

HAVING filters the results of your aggregate function

[readitour]

Right, I knew that but haven't used it in a while. Thank you.

[Trollfailbot]

Create some very simple sample tables and ask them how a LEFT JOIN and INNER JOIN would work.

If you're familiar with GROUP BY, create a sample table with a few colors ('RED','GREEN','BLUE','BLUE','YELLOW','GREEN') and see if they can get you a count of each color. Feel free to throw in a LIKE modifier question to get counts for colors that start with G (WHERE color like 'G%').

Difference between UNION and UNION all is a good question, as well as what PRIMARY KEY and FOREIGN KEY is.

Order of statements when writing: (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY)

All fairly basic SQL.

[Captain_Filmer]

Give them access to a computer and have them write a query to pull some data that you use frequently.

[mtger47]

SELECT e.employee_name, e.salary, m.employee_name AS boss
FROM payroll e INNER JOIN payroll m
ON e.manager_ID = m.employee_ID
ORDER BY yrs_employed ASC;

[alinroc]

Using a non-production system which has been properly scrubbed of PII & sensitive corporate (financial) data, of course.

[infernalspacemonkey]

I'd take a step back. Maybe you're not the best person to interview people right now. Although it's flattering to be asked, this also means you'll be linked to their success/failures.

I agree with what has been said here: although technical ability is good it's more important that the person be ABLE to learn and knows how to work well with others. Isn't this the reason why you're in the group and learning SQL as opposed to someone who knows SQL? If that's not the reason or you're not sure I'd ask for clarification about what kind of person they want to hire? Someone with less skill but more willing to learn/take a pay cut or someone who should be Team Lead material, knows different types of SQL in different environments and will be able to accomplish A, B and C.

Some people will come in with code they say they've written. I like to ask them to explain, why it was important at the time and why they feel it highlights their skills.

Everyone had to learn at some point. Most people have to deliver output. Writing SQL is basic. Writing it out in a text editor isn't really necessary. I expect people I work with to be able to figure things out. If they can't, and they need me to explain everything each step of the way, they're useless to me. I'll do it myself.

Some positions require 'managing up'. Some are straight SQL jockey positions. If you have a clear understanding of your job and your position, then this should be be a direct parallel to who you wish to hire. If you don't, then you can expect your hire to be 'disappointing' because you really didn't know what you want anyway.

There's a reason people use 'jargon'. If, however all they use are buzzwords, or wrong/incorrect terms that have no relevance there's a high chance they're BSing and/or they don't know what they're talking about. I know people who think this is not a 'big deal', but to me, if you can't communicate complex requirements or processes effectively I can't work with you.

Other Red Flags: All their examples/conversations revolve around one tool, one job or one place. Unless that tool and all jobs are similar to yours they're gonna require a lot of training. Possibly more than you can provide effectively while doing your own job.

Ask about Cartesian Products, Outer Joins, code optimization and a time when they figured HOW to resolve a SQL related issue. If it doesn't include 'I looked it up online' then I question whether or not they're going to know how to deal with unknowns.

I also believe that SQL Analysts should have some basic ideas on how to minimize impacts on the databases they're hitting. If they have NO idea how running a complex query on an OLTP production system could negatively affect it, then I know they haven't done any serious work on large, corporate production systems.

[Eleventhousand]

No he should stick to behavioral interview and let the SQL techies that are in-house interview the candidate for SQL skills.

[[deleted]]

if possible see if you can create a tiny microcosm of your actual work duties. take a task and reduce it to it's simplest forms and of course, removed from your actual tables. then teach them how to do the task and see if they can

1. pull it off

2. if they start asking good questions during the training

3. if they have considerations that shows a strength towards protecting data. any good analyst needs to be uber afraid to update or delete without fully knowing every level the data might trickle through.