Question regarding an interview method - need feedback
-
There are two rooms - one has three switches, and one has three lamps and the two room was seperated by a wall. You can only go to see the other room once. How can you tell which switch for which lamp ?
-
For those of you who figured it out with 3 lights. Now try to figure it out with 4 lights.
You have 2 minutes this time around
. -
Personally I agree Loner's opinion. But I don't think someone will change their mind.
But I will choose walk away, if interviewer wants to test me in such as 5 min.
-
I think I'd go for the ride and accept the challenge (just for myself). No need to burn bridges right then and there. Maybe they are just evaluating how you react to the situation.
That reminds me of an article I saw today on Yahoo :
http://hotjobs.yahoo.com/jobseeker/tools/ept/careerArticlesPost.html?post=47
-
So many people misrepresent their skills and experiences. So many people survive for long periods of time in jobs without significant accomplishments. I've seen DBA teams of 8-10 with 1 guy that shouldn't be on the team, IMHO, but they've been there 10 years. Someone that I wouldn't hired to be my sole DBA, or maybe not my 2nd. Especially not at a senior salary.
Getting tested isn't an insult. At least I don't think so. It's a way of doing a low level screen of people. And it isn't a make or break thing. If you can't remember syntax and someone held that against you, I'm not sure they're worth working for.
If you're looking for a job, you're looking for a fit as well. Let them challenge you and challenge them back.
-
I agreed with you that a DBA with no skills could still survive in a company for years. I saw many SQL developers with no SQL skills stayed with the company for years too. (It happened in my last company I worked for.) But if those companies allowed those people working for them, testing did not do them any good because obviously they could not tell who was good and who was not good. Basically the management was not good themselves so they allowed those people staying in the company.
I worked for a company that everyone they hired had excellent technical and interpersonal skills. They did not give any test. It was the manager who could spot who was good and who was not good. The manager had excellent skill to interview people.
-
In my 4 years of experience as a SQL DBA, I've always thought that the cleverest approach to interviewing was scenario based questions as opposed to technical 'what is a transaction, what is a primary key' type questions. It gives you an opportunity to mention what you can do and what tools you'd use, as well as demonstrate to the employer a logical thinking process. Plus anyone can read a book and memorise the answers, whereas not everyone has good problem solving skills.
At the end of the day, if you have a major disaster at work with managers standing over your shoulder, knowing how to recite definitions or exact TSQL syntax won't come in handy.
-
I've had nine contracts or jobs the last eight years, so I've interviewed a bit. I much prefer Joanna's scenario-based questions. I've had a few tests, but mostly they were trivial pursuit-style questions that don't really measure the whole breadth of what I need to do (T-SQL, DTS, design, architecture, C#, JavaScript, VB COM, ADO, HTML, etc.). And if they try to measure the whole gamut, the test becomes so time-consuming that the results become misleading. I went for an interview last summer for a DBA position, and they handed me a nine-page test of definitions and code to write, and three sharpened pencils. They parked me in a conference room and left me for an hour. I ground my way through it for about 50 minutes until I came to the question that was something like, "Discuss SQL Server architecture." I dropped my pencil and just kicked back until the interviewer appeared a few minutes later. The interviewer nit-picked my responses for about 20 minutes, showed some anger at me for not finishing his test, and finally came to this question:
Interviewer: "So why do you want to work for us?"
Me: "Actually, I don't."
OK, I didn't actually say that out loud, I just gave the standard answer. But it was a valuable hour spent in testing how the hiring manager deals with people.
There is no "i" in team, but idiot has two. -
I think it is mostly the interviewers without much DBA experience who ask bookish , memory oreinted questions . Someone (current message thread) commented about DBAs who work for years without ever having to improve their skills or do any do anything substantial . Imagine what would happen if the same kind of DBAs are also the interviewers too !!!!!!!! Without any real experience to draw on ..the only course of action is to ask questions that rely on ability to memorise and judge the candidates based on such questions .
-
"Imagine what would happen if the same kind of DBAs are also the interviewers too !!!!!!!!"
Then they would be managment.
There is no "i" in team, but idiot has two. -
Michael you are telling the kids you have candies, but they cannot have them?.
Come one, spit it out as next Question of the day. I'm sure you can replace it with some of the daily posts.
-
I think the guy wanted you to answer in writing so that he could take the answer to the guy who wrote the question to see if it was correct. Continuing the interview would be like courting a witch just because she had a good figure.
Regards,Carlos
-
I have been asked similar questions in an interview. I was asked to get the results by writting three different syntaxes. It was a telephonic interview. The interviewer did give me sufficient time to think, I gave him two syntaxes quickly and was looking for third one, but by then there was already lot of silence on the phone to which I was un comfortable and pressure was building on my head as I was concentrating on breaking the silence on phone and at the same time thinking about the code. We moved on with the next questions...
Within 5 Minutes after the interview, I wrote the code in 3 different syntaxes in SQL Server and emailed them. I will rather suggest the below method.
1. If onsite interview, give them a test environment and ask them to write the code in it. If your focus is to test whether or not he knows the queries I would not bother him by sitting on top of his head and looking each and every word he writes. On the other hand if ur testing how he performs in pressure and not interested in his code that is OK .
2. If telephonic, I will tell him he can use the test environment if required and will ask him to take the time and call back or will remain on the line and will ask him to buzz after he is done. I will make him feel that I am not waittign to hear back the answer from him.
It all depends on what you are looking in the candidate....
-
Nobody can know all the syntax of any language - and anybody who claims they can probably is lying. Not test, yes - for problem solving ability and ability to research and learn. How about giving them a book on a language they claim not to know and asking them to solve a simple problem in that language? That would show an ability to cope with the unfamiliar (I don't care whether they get the right answer, just whether and how they try).
-
Earlier this year I was interviewing candidates for an analyst job. My boss (not an IT person) wanted me to give each a test on SQL, Cognos, AS/400 (via iSeries). I resisted that. I was looking for a problem solver, not a coder. The code is out there to be referenced, problem solving is not. So I created a set of problem solving questions and made it a discussion, not a test. We all know that problem solving requires both discipline and creativity. I have to admit, it was fun to go over ideas each had. I didn't need them to know verbatim the proper logical forms, but I wanted a thinker. That's what I got. He was a great hire.
Viewing 15 posts - 16 through 30 (of 44 total)
You must be logged in to reply to this topic. Login to reply