Tough Interview Questions

Question

Tough Interview Questions

Steve Jones - SSC Editor

SSC Guru

Points: 734434
More actions
February 5, 2021 at 12:00 am

#3836477

Comments posted to this topic are about the item Tough Interview Questions
February 8, 2022 at 6:45 pm

This was removed by the editor as SPAM

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply

Eric M Russell SSC Guru Points: 125520 More actions · Answer 1

When I've done interviews in the past for an intermediate or above level position, I've asked mostly 'why', 'how', 'give an example of', and 'tell me about' type questions.

Instead of "What is a clustered index?", I ask: "Why would you create a clustered index on a something other than the primary key?". To really answer this question, the candidate must know what is a clustered index, what is a primary key, and physical data modeling.
Instead of "What is blocking?", I ask: "Give me an example of how a missing index can cause blocking.". Here the candidate needs knowledge of not just physical modeling skills but also put it in context of T-SQL coding skills.

For these situational style questions, someone can't study up the night before; only experience can prepare them to give a meaningful answer, and sometimes their answer will lead to an extended discussion (like if they suggest a solution I never considered). These are exactly the type of situations they would encounter week 1 on the job. At the end of the interview, I have a solid (although subjective) feel for who were the one or two strongest candidates and which candidates are not worth perusing.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Steve Jones - SSC Editor SSC Guru Points: 734434 More actions · Answer 2

I like those kinds of thoughtful questions. The best interviews I've had have used those, working through some process or scenario rather than looking for trivia.

Jeff Moden SSC Guru Points: 1003857 More actions · Answer 3

I mostly agree, Eric. I DO ask the "What" question first, though. The reason why is that most candidates are as nervous as a chicken wearing a pork chop necklace in a lion's den and I use the "What" question to help the candidate relax a bit and to let them know what the next set of questions is going to cover. Then I drill down with the "How" and "Why" questions. Well, not always... if they can't answer the "What" questions, it's usually a pretty short interview because I don't want to punish the candidate or myself. 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

webrunner SSC-Dedicated Points: 31715 More actions · Answer 4

The more I learn about SQL Server (mostly through painful lessons lol), the more I find it useful to consider somewhat higher-level interview questions.

Things like version control. Not necessarily product or syntax details, but does the candidate mention version control as a DB process at all? Are they conversant about why version control would be used if they are asked?

That's just one example, but in my experience, a lot of interviewers get tunnel vision about overly specific technology questions and don't spend enough time gauging overall conceptual understanding of the role.

-- webruner

-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Jeff Moden SSC Guru Points: 1003857 More actions · Answer 5

So, you're saying that a Senior DBA doesn't need to know about Clustered Indexes or even how to get the current date and time in T-SQL? Heh... I've seen what happens when that happens.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

skeleton567 SSCertifiable Points: 5670 More actions · Answer 6

During my 11-year stint in IT management I interviewed and hired a number of candidates, only one of which did not work out for the company and had to be let go. My experience taught me that the technical questions were secondary to the questions that revealed outlook, attitude, motivation and method. I needed people who were positive, could work well with our group, and were up for a challenge.

Knowing the answer was not nearly as important as knowing how to find the answer and being willing to expend the effort to do so.

I have always remembered one interview where my prospective new boss ask me if I knew Fortran. My response was truthful: "No, I don't, but I guarantee I will by the time I start the job".

I got the job and was very lucky that I was able to get Microsoft's Fortran compiler and bury myself in learning Fortran in the following three weeks before I went on board. I immediately began to support a fair number of Fortran programs that had been created by a quite talented gentleman who had served as a consultant to the company and developed their library of technical design applications which we were integrating into an Ingres database environment. Ingres was probably the third database system I had worked with, and was definitely not my favorite, but it served as a stepping stone in my IT career possibly due to my response to that interview question.

Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )

Jeff Moden SSC Guru Points: 1003857 More actions · Answer 7

I totally agree that "outlook, attitude, motivation and method" are incredibly important. However, there have to be technical questions/discussions, as well. I've found that they're actually important in me the a fore mentioned qualities of the candidate. For example, when trying to hire a Senior DBA or Senior Developer, what does it actually say about attitude, motivation, and method if they can't even tell you how to get the current date and time using T-SQL? Or, how about someone that advertises themselves as an "expert" in performance tuning and you ask them about clustered indexes and they tell you they've never had to work with clustered INDEXES because they've never worked on clustered SERVERS?

Yeah... those are all true stories.

When hiring for senior positions, both the form/fit and the function (knowledge/experience) matter and those attributes are not mutually exclusive.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)