May 12, 2009 at 12:21 am
Comments posted to this topic are about the item Testing Skills
May 12, 2009 at 1:37 am
Kobayashi Maru
I once did something like KM on my best programmer I ever trained. After a week, I told him inheritance could be done in Visual Foxpro but not in Visual Basic (not .net). My purpose was for him to sense what was impossible, but to always keep on trying to find a solution. I couldn't apply it to the rest of the team since it was a cube office so everyone heard the answer.
If this was done in an interview, it may or may not be nice. For one, not being an employee, the person would say it is unfair to give an impossible question on a desperate person.
Perhaps something light and a bit funny on a VM?
May 12, 2009 at 2:32 am
That specific technique would only really be applicable if you were trying to hire someone to fill a purely support role - you would need a different task if you were looking for a developer. I have found the latter to be a little hit-and-miss, as it depends whether or not your developer is in a comfortable environment. If he is used to a different IDE, it would only take a matter of days to get up to speed on how it worked, but a rival candidate who is already used to that IDE would have a massive advantage, not just in speed, but also knock-on effects in other areas.
May 12, 2009 at 3:14 am
Mike is spot on - I myself have been in exactly that situation where I was given an hour to sit at a PC with a spec and code a database solution. However, the company interviewing me had a different IDE to what I was used to, and although in the feedback I was told I was the better candidate of the 2 people they shortlisted, the other guy got the job because he had worked on the IDE the company used. A year later, I got a call from the company asking me if I was still interested, as the guy they recruited did not fit in and had left them......
If you are going to do something like that - and I agree it does give a good indication of technical ability - then the idea of something less formal like sitting round a workstation and discussing possible defects and solutions is definitely preferable; people tend to be nervous at interviews and being put on the spot in a formal way does nothing to relax candidates and endear them to you!
May 12, 2009 at 6:46 am
I've been asked to program in an interview and I have offered to program for an interview. I was offered the job in both instances. The second one liked the idea that I made the offer. I didn't have to actually write code. I'm comfortable in this situation. But, I can see someone who doesn't like surprises not doing well. But, our industry is full of surprises and you have to expect to have to deal with them.
I don't know how accurate doing this is. Sure, you find out if the person can work under pressure and perform the tasks but is she the right person for the job?
May 12, 2009 at 6:50 am
When I interviewed with Brian Knight, he handed me his laptop and said "Write me a query to do such-and-such." The SQL Server instance had been corrupted. There was no way any query was going to be executed in that instance. I started running down the issue and found a good symptom in a few minutes.
Brian watched the whole time, not saying much. He wanted to see what I would do. That's about the best interview technique I've seen - it came as close as anything to allowing him to watch me think.
While this worked out well for me, there are no silver-bullet shortcuts I'm aware of in 2009. I agree with Steve - you can make money if you have one.
Nowadays, as a manager, I balance my time between identifying team members' strengths and aligning assignments accordingly; and identifying obstacles and weaknesses, and helping them overcome them.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
May 12, 2009 at 7:04 am
bear in a box (5/12/2009)
Kobayashi MaruI once did something like KM on my best programmer I ever trained. After a week, I told him inheritance could be done in Visual Foxpro but not in Visual Basic (not .net). My purpose was for him to sense what was impossible, but to always keep on trying to find a solution. I couldn't apply it to the rest of the team since it was a cube office so everyone heard the answer.
If this was done in an interview, it may or may not be nice. For one, not being an employee, the person would say it is unfair to give an impossible question on a desperate person.
Perhaps something light and a bit funny on a VM?
The Kobayashi Maru, as I understand it, is about testing how someone deals with failure, since no amount of skill can result in a successful outcome. This is OK if that is what you want to test, but it is unfair if the candidate is misled to believe that there is a real solution.
However, the idea of a SQL VM with issues that have real solutions would be a good idea. Judging from some of the comments so far, there would need to be some thought put into it, such as would it need to be standardized - SSMS simulator so candidates know how to work it, or a proprietary interface if that is what the organization uses and thus is what a prospective hire must know how to use.
Otherwise, the Kobayashi Maru scenario is really just a variation of a pressure interview, I think.
- webrunner
-------------------
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
May 12, 2009 at 7:15 am
Its been my experience that trying to interview someone by playing the "Stump the Chump" game only gets you someone who might be very good at trouble-shooting, but may lack any strategic knowledge in the day to day essential work. Take your example and suppose you had a guy come in who could debug and resolve your VM installation - does this mean that the next time you are charged with a major project that requires design, vision, and intuition that this "McGyver" you just hired is going to be your person? I don't think thats any kind of overall indicator.
For me personally, I am most impressed by people who show me their work. I am even more impressed by someone who shows me their work and is excited about it. On the other hand, when a candidate comes to an interview with nothing to show, I worry and frankly, its a strike against them. I want to see someone "sell" me as to why they are the best candidate, and their work speaks volumes to that (or not). I don't need any installable - even screen prints, query listings, illustration of projects - these things impress me (most of the time) and the lack of them does just the opposite.
However, we have found our biggest success with SQL candidates (DBAs or just line workers) comes from 1/2 day interviews where the candidate meets various team members, each testing different areas of knowledge, and then we all get together and discuss whether or not we have a second interview candidate - or a person who will not make the cut. In these extended interviews we get to judge team-fit, as well as skill set and aptitude for being a positive contributor.
This has worked very well, avoids the "Stump the Chump" game and usually highlights not only SQL skills, but the crucial team-player skills we seek.
May 12, 2009 at 7:20 am
We've recently hit a similar snag in trying to see if candidates are a good fit or not. It's one thing to go through the interview and get good answers, but a completely different thing to have these same people sit down and do actual work. We came up with a test to get a feel for what candidates can do and how they respond when they encounter problems. We cover some pretty basic tasks and use the MS toolset (to address Mike's concern). We ask them to write a simple Select statement and then a select w/ Aggregate functions. We ask them to troubleshoot a poorly performing query (and to rewrite it or at least make suggestions on how to improve it). We ask them to use SSIS to do a basic Fact table load. We then have a variety of other questions from which to choose a small number to complete. We give them more than enough time to finish enough of the tasks for us to judge their skill-level. They are given a full copy of BOL to reference while taking the test.
This wouldn't have been a problem a couple of years ago, but we needed someone who could come in and actually start working. Too many candidates seemed to have mostly manager experience or no experience. This let us see who could start off by helping us with a relatively short ramp-up time.
We went through several revisions to get to a relatively final version of the test and had to give some pretty heavy hints about the table structures and column locations for the first parts to help people past their unfamiliarity with the data model. However, I think we now have something that can give us a pretty good idea about a candidate's skill level and it could be given as a "take at home" test as needed.
Our developers do something like this already. The candidates are given a simple web service to write at home and submit. A lot of candidates don't bother to submit their work, but those who submit something will have their code reviewed to see if it's worth proceeding. The code doesn't have to be perfect, but it should work and more experienced developers are expected to produce something more polished than those just starting out.
I think testing has a lot of value in certain areas. If you're looking for a really junior person, this may not apply. If you need to know if someone can do the work, an eval is really helpful. I'd hate to have been Andy, though. My abilities definitely lean more toward writing T-SQL than Admin type work. I'm sure I could have figured it out, but my first reaction would probably have been to tell Brian that his DB was corrupt and ask if he had a backup. 🙂
May 12, 2009 at 7:43 am
It is an interesting premise. However for a first interview in an alien environment it may not be fair - but you will probably find the best candidates that can think on their feet - not necessarily those that can think out of the box. In this situation there should probably not be a choice to be left alone. I state this because team players and environments are now the norm. The day of the 'lone gunman' is long past. What better way to see how go a fit will be when 'the chips are down'. I feel that the best use of this type of interview is when one is interviewing a senior applicant for a position no matter whether they are internal or external.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
May 12, 2009 at 7:47 am
blandry (5/12/2009)
Its been my experience that trying to interview someone by playing the "Stump the Chump" game only gets you someone who might be very good at trouble-shooting, but may lack any strategic knowledge in the day to day essential work. Take your example and suppose you had a guy come in who could debug and resolve your VM installation - does this mean that the next time you are charged with a major project that requires design, vision, and intuition that this "McGyver" you just hired is going to be your person? I don't think thats any kind of overall indicator.
True, although I think again you have to refer back to what the goal of the interview is. If the goal is to test troubleshooting, a SQL VM test has its place. But it won't necessarily reveal the person's skill in strategic thinking or show you what projects they have designed in the past or what they did to make sure the SQL servers didn't break in the first place.
blandry (5/12/2009)
For me personally, I am most impressed by people who show me their work. I am even more impressed by someone who shows me their work and is excited about it. On the other hand, when a candidate comes to an interview with nothing to show, I worry and frankly, its a strike against them. I want to see someone "sell" me as to why they are the best candidate, and their work speaks volumes to that (or not). I don't need any installable - even screen prints, query listings, illustration of projects - these things impress me (most of the time) and the lack of them does just the opposite.However, we have found our biggest success with SQL candidates (DBAs or just line workers) comes from 1/2 day interviews where the candidate meets various team members, each testing different areas of knowledge, and then we all get together and discuss whether or not we have a second interview candidate - or a person who will not make the cut. In these extended interviews we get to judge team-fit, as well as skill set and aptitude for being a positive contributor.
This has worked very well, avoids the "Stump the Chump" game and usually highlights not only SQL skills, but the crucial team-player skills we seek.
That does sound like a great approach. I like the fact that you ask to see examples of work. That says a lot either way - if they have great examples, you can be impressed, and if they have bad or no examples to back up their resume, you know they're not for real.
But I think the above approach might be combined with the proposed SQL VM approach as well if testing troubleshooting skills is desired - not as a "Stump the Chump" exercise but as a scenario with a little more thought behind it and perhaps time afterward for the person to explain why they did what they did. I think it depends on the organization and what they want to test for in an interview. Sometimes you can measure a person's excitement for the work from what they show and tell; sometimes you need a structured set of questions to find out; and other times you may need to have them meet more (or certain) people at the organization to make a reliable assessment. And, human nature being what it is, there is a chance that despite the best efforts, someone is hired who doesn't work out.
- webrunner
-------------------
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
May 12, 2009 at 7:51 am
webrunner (5/12/2009)
if they have bad or no examples to back up their resume, you know they're not for real.
I am curious about that - how exactly do you expect a candidate to provide details of work he has carried out on presumably confidential, internal systems?
Public websites are great, but we don't all have the luxury of working on them.
May 12, 2009 at 7:53 am
I wouldn't have an issue being presented an environment where I had to troubleshoot something, write a query, or create a data model. Several people have mentioned how this might not identify the right person, but I think this is a part of the interview process, not the entire determining factor. You might take the 2nd or 3rd best person on the test because of other factors, personality, cost, etc...
I don't know that I think it would be appropriate for a first interview, but definitely a second interview, particularly if you had the time to develop the test to target skills the person claimed on their resume or in the first interview.
I had to take a test like this for one position and the interviewers were excited that I was excited by the test. Didn't get the job even though I aced the test. May have been because I wasn't overly impressed when they mentioned how complex the database was because they had queries with 3 and 4 joins;-)
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
May 12, 2009 at 7:54 am
I fill the business analyst role in our small Company.
Whenever I interview someone for an Analyst role, I pose a series of problems ranging from basic algebra to identifying the result set from a relatively simple 2 or 3 table join. With the exception of basic algebra, I do not expect them to get it right. But I do want them to explain their answer to me. I.e. what were they thinking.
It is important to me to see creativity in a problem solver.
Aside: A KM type of scenario is only unwinable if ones continues to color between the lines. Redefine the lines!
May 12, 2009 at 7:58 am
I'm surprised at how many people seem to think ability to troubleshoot isn't a necessary skill for a developer or for strategic thinking. Troubleshooting is, at its essence, problem solving and unless you give someone a simple problem that they can read the solution from a script "Did you try rebooting? Is it plugged in?" then a person who shows they can solve a problem can likely solve the problem of translating from a "goal" (business problem) to a "solution" (application that meets the goal). Certainly there are other factors that will contribute to how good their solution is, but ability to troubleshoot is IMNSHO one of the big indicators that a person can actually think, reason and solve problems.
--
Anye Mercy
"Service Unavailable is not an Error" -- John, ENOM support
"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya in "Princess Bride"
"Civilization exists by geologic consent, subject to change without notice." -- Will Durant
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply