Brandie Tarvin (10/24/2008)
Jeff may disagree with me on this, but here's my take on interviews.
Know your stuff, but if you can't answer the question, be honest about it. Tell the interviewer that you don't know. I've told prospective employeers before that "I don't know the syntax, I usually check BOL before I do it" or "I haven't played with that functionality before" or things like that, depending on the question.
In my book, there's nothing wrong with those kinds of answers. And if the interviewee seems to know the other stuff, but is weak in an area or two, I'm willing to let them learn on the job, so long as they're not trying to BS their way through the interview.
No... no disagreement there. How you answer or don't answer a question is nearly as important as the actual answer itself.
I've told this story before, but it seems very appropriate here. I was the AppDev manager and I had open billets for a GUI programmer who also knew SQL Server a bit better than average. I gave the recruiting agency a copy of a test I wanted candidates to pass before even thinking of sending them to me. The exam wasn't difficult... it was a pretty straight forward exam that anyone with a year or two of SQL experience should easily pass without studying.
Well, after a couple of days, the recruiter sent me a handful of resume`s along with each person's exams. Some did pretty well on the exam, but I was mostly disappointed because most gave some really poor and incorrect answers on 5 or 6 of the questions. You could tell they didn't know the answer but wrote a lot of rhetoric trying to convince me they did instead of just saying "Don't know, would have to research it or look it up in Books Online".
Then, I ran across this one fellow's test... it was perfect. He had all correct answers and the additional explanations he gave were spot on. On top of that, he had teaching experience and a great background in Math. So, I picked up the phone and called him. We talked for a while about what turned out to be an impressive work and experience history, and then I asked the question... "No one else gave all correct answers and they certainly didn't give the detailed explanations you did. For example, your explanation about what a "Firehose" cursor was, was absolutely spot on. How is it that, as a GUI programmer, that you know so much about SQL?"
His answer absolutely floored me... he said, "Unbeknownst to you, they allowed all of us to take the exam home... to take it in an unsupervised fashion. I didn't know a "Firehose" cursor from a ticked off fireman. So, I looked it all up on the internet."
He appologized for the "deception" and for "wasting my time" and was on the verge of hanging up. I stopped him, of course. In fact, I hired him for a couple of reasons...
First, he was honest to the point that it could have worked against him. That's pretty damned honest and I need people to be honest enough to tell me they broke something or whatever.
Second, even though it wasn't planned that way, ALL the other applicants had the same opportunity to get the answers absolutely correct the same way this fellow did, yet they did not. They apparently didn't have the research skills or, worse, couldn't be bothered.
Joe worked for me only a couple of years before the company decided to pull up and move back to Chicago... but during that time, he continued to demonstrate not only the ability to do the correct research to get a job done, but he was absolutely honest. He broke some code, one day, and came and told me not only that he broke the code, but what he was doing to try to fix it and then stayed late to stay on schedule. Even if he didn't know how to fix it, ya gotta love absolute honesty.
YES! I want someone that knows how to write code. There are certain basics that I believe you must know. But, I've had a couple of certified geniuses apply for similar jobs that knew just about everything I needed them to know about SQL... and I didn't hire them because either they were arrogant, they tried to BS me in the interview, or they lied on their resume.
Like I said, how you answer a question is nearly as important as the answer and absolute honesty is an absolute requirement.
is pronounced ree-bar and is a Modenism for R
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs