T-SQL programming and interview questions....
-
I've applied for a Data Analyst postion. On my resume, I specified that I had T-SQL programming, extracting, manipulating, analyzing data.... And these are what I am doing at my job....
During the interview, the hiring manager asked me questions like differences between indexes, how many parameters allowed in stored procedures which I did not remember exactly the number, what table triggers are used, BTREE which I had no clue, error handling...
Personally, I think most of the questions the hiring manager asked were for Developers or DBA's not for a Data Analyst who is just responsible for writing SQL scripts to extract and then manipulate and analyzing data to fullfill business reporting needs. And the job description for this position was also just specified these responsibilites only. Do you think that was right for the hiring manager to ask the questions beyond what specified in the job responsiblities? I was really ambarrassed when could not answer alot of the quesitions that I thought were for Developer and DBA roles only.
-
if the job description u were supposed to receive prior the interview DID NOT specifically mention all those things he asked you, then
1. he should not have asked those questions in the first place, but even if he did, then...
2. more important: u should not have felt embarrassed a tiny bit after he'd asked u about the triggers etc. U needed to calmly explain to the guy/gal that those skills are not (obviously) required for the position, and besides u know some other equally exiting thinds really well and those things are exactly what was written about in the job description.
I myself was in a similar situation applying for Analyst/Developer position, so I'm telling it to u from my personal experience.
Sergei
-
Unless they ask they questions in order to upset you or belittle you I think they are ok with asking them. From personal experience of doing technical reviews of people it is interesting to ask questions that I do not expect the candidate to be able to answer. I watch (listen) how they tackle the subject. There is nothing wrong with saying you do not know the answer to something, especially if it is not in the job description. But from an interviewr's POV it is interesting to see how the candidate reacts, if he asks for more info etc, or if he just answers something without having any idea and does not want to show that they do not know the answer.
So even though you think it went bad since you didn't know the answers you might have performed well anyway and passed the test.
-
I've found that some managers will ask you questions to push you to your limits. They want to know how much you know and in what areas. It gives them a much better feel for their job candidates. When this happens, never feel bad about the questions you can't answer. No matter how skillful you are, there will always be questions you can't answer. They expect this. Again, they're not looking for you to answer _all_ of their questions, they're looking to see how many, and which, questions you can answer.
Also, the questions the manager asked you may relate to a specific project you'd be working on. When I took my current position (as a Data Analyst), I dove right into a data migration project that involves a lot of programming. It'll be a couple more months before I move into my permanent responsibilities.
Another thing, HR may have written the job description. Do you really think HR knows what they're talking about? 😉
-
My view when on interviews as interviewee I try ussually to turn the table around to try to Identify the purpose of the questions being asked and assess the skills of the inteviewer in its own ground.
When on the other side, as interviewer, I assess a lot much more how you go about a problem for which I probably don't even now the anwser so that your problem solving/ creativity skills are stressed.
a technical interview that goes far beyond the basics in my opinion is ussually unfair because normally the interviewer will be asking question in that case releted to his/her personal experience but I am pretty sure that it could be extremelly difficult for that same interviewer to anwser something from an unknown ground where the interviewee may have deep understanding
Keep your problem solving skills trained and your knowledge current and you should be fine!
Just my $0.02
* Noel -
-
A good technical interviewer (who's doing more than simply validating you told the truth on your resume) will *always* go over your head, in several directions outside of the job at hand. At that point, they are going beyond "Can this person do job A, and only job A", and trying to answer some very important questions:
- will this person grow in this position?
- are they interested/capable in other aspects this position may entail, but haven't been fully explained? Most job descriptions miss the mark, the duty list gets skewed after being passed from manager to H.R. to recruiter to candidate, with different understanding and hopes along the way. The manager may also have additional plans for the person who takes the position as part of a larger project. The specific project that generated the opening may end after a period of months, and the person filling it will ben seen as a resource for other internal opportunities.
- will this person be bored (and quit within 2 months) because their skill level and experience are years ahead of what the duties will be? Are there other (and better) openings in the company this person may fill? The 'will they be bored' question is very important to the competant interviewer - you don't want to hire someone who will start looking for another job a week after they start. (They ofter deliver substandard results, leave before the project completes, and chew up the hours on your project budget) The only way to find out is to see if the candidate already outgrew the job before they take it.
- Are they comfortable with saying "I don't know" when it's important, finding it more important to remain credible by telling the truth than guessing in order appear to know the answer when they are fully aware they do not? Similarly, how do they react to being challenged with questions outside of what they are prepared to answer?
- Some skills are just hard to come by, and the interviewer is comfortable hiring someone without those skills with the hopes the new hire will pick them up. If the candidate actually already has those skills, they are putting themselves in the 'bonus round' of salary negotiations. For example, DBAs I hire for my team must be able to manage very-high-transaction 24x7x365 databases, tuning OLTP queries involving multiple tables with billions of rows across several multi-terabyte SQL Server 2005 databases.
There is no way am I putting that on a list of requirements for candidates, it would filter darn near everybody out - including myself and every other person now on the team. A very small percentage of SQL Server DBAs have ever dealt with that kind of stuff, but a decent percentage of those that haven't absolutely could once exposed to it. (Now, I will mention it when recruiting, cus it gets a lot of hardcore SQL geeks like me salivating and want the job.) Now, if someone actually *has* solid experience making a difference in that kind of environment, it's going to show up in the offer letter. But if they haven't I want to see someone who wants to get thrown into that kind of environment.
>> "U needed to calmly explain to the guy/gal that those skills are not (obviously) required for the position, and besides u know some other equally exiting thinds really well and those things are exactly what was written about in the job description."
WRONG ANSWER. That's making excuses for not knowing the answer. No matter how calmly you put it, the message is simple: "Sombody screwed up, and it ain't me". Plus, the job may actually entail some of the stuff, which shows you making incorrect statements without gathering facts, and incorrectly making them directly to the person who may have those facts. (Usually a bad step when interviewing for an analyst position, a position that requires someone to ask a lot of questions and gather a lot of facts.)
When you are hit with a question outside of your ability/interest/industry/etc, especially if it's way out there, simply show a slight about of surprise, point out that you are unfamiliar with the tech/process/product/industry/whatever, and ask if the position requires that knowledge. If it's something you are interested in, ask the question enthusiastically as a way of saying "Hey, hire me! I want to learn that stuff!" If it's something you're not interested in, ask the question as if you're concerned about taking a job you don't want. The key is to ask about the job, not dictate about it. There's opportunity with the question approach to throw in personal abilities the interview may not have asked about yet.
Example out-of-scope question for a data analyst position: "How much MDX have you written?" Note the real questions-behind-the question could be:
- 'OK, let's make him sweat'
- 'I need to make sure he doesn't get sniped by the BI team like the last guy I had in this role'
- 'Is he going to stick with the job?', or
- 'there's several people applying for the analyst position, maybe I can find someone who will want to chip in and get cross-trained with the BI folks - they're harder to hire than analysts are.'
The real motive could also simply be 'I don't know what those idiots in H.R. said, but I need someone with MDX skills.'
Now, assuming you haven't ever written any MDX:
Wrong answer(per prior advice): "I was told that has nothing to do with this job. However, I do like (unrelated tech)..."
Good answer if you are interested in learning MDX: "Well, no, but I got to see some of the stuff the BI programmers were doing with it after I got them the data they needed. That's cool stuff... is this something I might get exposed to in this position?"
Good answer if you want no part of MDX: "I've be working a lot lately on better ways of scripting data out with T-SQL, and getting good requirements out of people. Learning MDX seemed like it would pull me away from my goals. Is this something I would be required to learn in this position?"
Note that, depending on the motive for the question, one of those good answers is right, and one is wrong, unless they are just testing you in which case both answers are right. By telling the truth, you at least retain your integrity, and prevent yourself from being set up for a job you either don't want or can't do.
-Eddie
Eddie Wuerch
MCM: SQL -
Somebody,
If I have a lot of candidates with good resumes all lined up, I'll ask some questions outside of what the job specifically requires as "tie-breakers".
For example... let's say I have a several ace resumes for an SQL Developer... If they all answer my questions correctly, they all have a good attitude and work ethic, but only one of them can tell me what 1416 is in decimal, 24 is in decimal, or how to convert two Cartesian pairs to a distance, which one do you think I'm going to hire?
Never be embarrassed about these "extra" questions. But, in this case, I don't think you were asked that many "extra" questions... So far as the job description goes, extracting, analyzing, and manipulating data requires some very good knowlege of indexes and other things having to do with performance...
--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) -
Yeah, I agree with the things said. I have been asked to perform a technical interview and have thrown things in related indirectly to the specific job as we may have long term expectations that don't apply currently and if I can find someone who can do those things it might mean the difference between a contract job and potential offer for a permanent job.
As well, it helps to weed out the salesmen who tend to BS their way thru versus saying I don't know the answer and would have to research it further. I would rather have someone tell me they will find the answer than to feed me a line a bogus stuff hoping I don't know what I am talking about.
-
Did you guys notice this thread is two years old ?
* Noel -
Ha Ha, sure didn't.
-
Still worth it... maybe someone else can get a leg up on things if they manage to find it...
--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)
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply