January 17, 2015 at 3:55 am
Dear all,
I'm preparing for SQL DBA interviews and came across Brent Ozar's DBA Job Interview Question & Answer Kit, which is a 90 min. online training video. Has anyone bought it? Since there're already resources for DBA interviews on the web, how is this video different from the other resources on the web?
It'll be great to hear some reviews from someone who has used it for his/her job searches.
Thank you!
January 20, 2015 at 11:03 pm
I purchased it and liked it a lot. There are a wide range of questions and great advice about how to think through questions that you may be asked but know little about.
January 20, 2015 at 11:17 pm
I have not seen it, but I've watched some of his presentations. He knows his stuff, for sure. There aren't many SQL Server Masters, and he is one - so that says a lot.
January 22, 2015 at 12:20 am
So, did you buy it? And if so, was it worth it?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2015 at 9:17 pm
I don't think it's worth it...
the tech questions are too basic and the answers are too short. For situational questions, I pretty much was able to predict what's going to be in there before I purchased and the answer to situational questions were "take a deep breadth and calm down... "
compare to other brent ozar product, i think they could have done a lot better job.... 🙁 I hope they will provide a free "upgraded" version of this training video in the near future.
January 30, 2015 at 11:32 pm
yoshii (1/30/2015)
@JeffI don't think it's worth it...
the tech questions are too basic and the answers are too short. For situational questions, I pretty much was able to predict what's going to be in there before I purchased and the answer to situational questions were "take a deep breadth and calm down... "
compare to other brent ozar product, i think they could have done a lot better job.... 🙁 I hope they will provide a free "upgraded" version of this training video in the near future.
Not slamming here but I do have to ask. If people think they know enough to apply for an SQL DBA job, why do they think they need to go through any sample interview questions? Especially ones that cost money?
What kind of DBA position are you shooting for? Pure admin DBA, application DBA, or hybrid DBA?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2015 at 2:58 am
not sure where's this thinking of "reading interview questions = cheating a job" coming from. there're billions of people on earth. there are people trying to cheat a dba job. but, there are people out there with experience and knowledge, however don't have good interviewing skills.
an interview usually last 45min to an hour. for phone screening it may only be 30min. It takes quite a skill to show ur skills and knowledge to a stranger within a short time-frame. it goes without saying that there maybe tricks built-into questions. It goes without saying that interview settings are not mean to be the most comfortable chitchatting session. Psychological effects also play a role.
I don't think it's appropriate to assume one's trying to cheat a job when he's reading interview questions. but, I do think it demonstrates that he is doing his homework for researching and getting familiar with the situation he's gonna face. I would think anyone would be scare to have an employee who doesn't get as much as information he can when he's on or before an assignment. A interviewee's assignment is the interview. When resolving a critical situation at work, I get as much as the information (either from technical side or business side) I can in order to exercise best judgement for my boss and my company. I see no reason not to do the same for my own critical matter, which is interviewing. I think it's an act of being responsible to myself.
I would appreciate you asked my intent of purchasing at the first place, instead of pretending to ask me to review the content of the training video. I did give you a sincere review of the training video.
and why spent money on it? brent ozar is pretty successful in his SQL Server Training and does have good products. I would like to see if they have different perspective on interviewing.
Lastly, I do think one can cheat on a certification, but I don't think anyone can cheat a dba job just by memorize all those interview questions. DBA requres not only technical skill, but also much of process of thinking skills, research and evaluation skills, decision making skills... and etc. It should be easy to identify who is memorizing the answer, who does have experience.
Anyways, i sepnt too much time on this thread.
January 31, 2015 at 2:11 pm
yoshii (1/31/2015)
not sure where's this thinking of "reading interview questions = cheating a job" coming from. there're billions of people on earth. there are people trying to cheat a dba job. but, there are people out there with experience and knowledge, however don't have good interviewing skills.
BWAAA-HAAA-HAAA!!! Ah, my young friend, you've got it all wrong. Where did anyone say it was cheating in any of the previous posts on this thread? :blink: I sure as hell didn't. So far, you're the only one. Think about that for just a minute before you produce another outburst and read on. I've got some good stuff for you if you're willing to listen and understand. Seriously...
Heh... ironically, what you posted about them saying "take a deep breath and calm down" is probably the best advice there is. Go in, be yourself, and take every question as an opportunity to show your stuff. Pretend you've been working with them for a thousand years.
an interview usually last 45min to an hour. for phone screening it may only be 30min. It takes quite a skill to show ur skills and knowledge to a stranger within a short time-frame. it goes without saying that there maybe tricks built-into questions. It goes without saying that interview settings are not mean to be the most comfortable chitchatting session. Psychological effects also play a role.
Ok... let me play your words against that... "not sure where this thinking of "them trying to trick you"" comes from. Consider that a lot of people are "book smart" and have memorized a whole bunch of things by rote memorization. Interviewers are well aware of that problem and don't want to hire someone that can, for example, recite what the rote definitions of what a Clustered and Non-Clustered index are. They want someone that can use the similarities and differences of each to the advantage of the system and the code. There's only one way to find that out and that's to ask some of the questions that you call "trick" questions. For example, if you just sit there waiting for the next question after you've done such a recital of the basic definitions of the two, then you can expect someone to ask "OK, good. Can you tell me what Non-Clustered Indexes have in common with the Clustered Index, why that's important, and when you would choose one over the other?" or "What can you add to a Non-Clustered index to sort of make it behave like a smaller version of the clustered index"? And, is it a "trick" question to give you some column names in a table and ask which one(s) would make the best clustered index and why?
You can avoid such questions by anticipating that such follow-up questions will be asked and answering them as part of your answer on what the differences and similarities are. You say that it takes "quite a skill show ur skills and knowledge to a stranger within a short time-frame". No it doesn't. All it takes is the understanding that the more you can correctly spill your guts about things they've asked you simple questions about, the better off and more impressive you're going to be. Just be careful not to be arrogant about it because they're also evaluating for whether you'll "fit in" with the team.
Here's another example of what I'm talking about. To loosen up the interviewee, I tell them that I'm going to ask them some simple questions and that I never ask trick or even esoteric questions. Then I ask them how to get the current date and time using T-SQL (it's actually amazing how many people I've interviewed that don't know the answer to that simple question, but we'll save that for another discussion on "resume liars, fakers, and posers").
Of those that actually do know the answer, most answer with either GETDATE() or CURRENT_TIMESTAMP or both (if I'm lucky) and then they just freakin' sit there instead of strutting their stuff! Anyone can regurgitate the name of those one or two functions including those that ONLY know the answer(s) to the question without understanding anything about the functions. Here's how I end up answering such a "simple" question when I'm being ingterviewed. Ready?
"There are currently six functions in T-SQL that will return some form of the current date and time. GETDATE(), CURRENT_TIMESTAMP, and SYSDATETIME() are nearly identical in that they all return the current date and time according to the clock in the server. GETDATE() and CURRENT_TIMESTAMP are accurate to 3 miliseconds as a DATETIME data-type and SYSDATETIME() is accurate to 100 nano-seconds as a DATETIME2(7) data-type. At the max, both take 8 bytes of storage but, at the expense of what can be displayed, DATETIME2 can take as little as 6 bytes. You could use the 4 byte SMALLDATETIME but you have to be really careful of the "minute" rounding into the next day. There are two additional functions that will return the UTC version of a DATETIME and DATETIME2 data-type and one that will return the "datetime offset" version. I don't use those last 3 very much so I don't have them memorized but I know where to find them in 'Books-Online'. The range of DATETIME-based functions is 1753 through the year 9999. The DATETIME2-based functions have a range that starts in year 0001. I question how accurately though because the current Gregorian Calendar wasn't 'universally' accepted until sometime just before 1753. Since the DATETIME data-type doesn't take up that much extra room and has some serious advantages in the calculation and aggregation of duration over DATETIME2 and the other newer data types, I generally stick with the DATETIME data-type unless there's some compelling reason not to such as increasing the possibility of portability."
Something less than 2 minutes to say that and I now have their full attention. If they cut me off somewhere in all that, that's OK. I consider that a part of the "fit in" test. Depending on how they've cut me off, it might be a good indication to me that I might not actually want to work for them. You see, I'm not the only one being interviewed. I'm also interviewing them for attitude, thoughtful communication abilities, and whether or not I could actually "fit in" with the team. 😉
Could YOU answer that "simple" question in such detail? Maybe not. But if you just say "GETDATE()" and sit there like a dog waiting for the next piece of cheese to be balanced on your nose, you're not going to make as good an impression as you could. Offer up what you do know. It's not like you have to "plead the 5th" during the trial known as a "job interview". 🙂
You should see how I answer the "Why is a manhole cover round" question...
"The standard answers are that circular objects are easier to mill to a tolerance, the pipes they cover are usually round, you get the greatest diameter/width for the given amount of material making it a very strong shape as well, you don't have to align them in any fashion to properly set them in place, and their constant diameter makes it impossible to drop the cover into the pipe provided that the hole is a tiny bit smaller and also of constant diameter and proper rigidity. On that last point, circular and spherical objects are NOT the only shapes with a constant diameter." That's when I go into a short explanation of Reuleaux geometrical shapes and Meissner bodies. Then I show them the trick of how to pass a quarter through a hole in a piece of paper the size of a dime without tearing it while explaining that the paper represents some people's perceptions and limitations and the quarter represents that "impossible task" that they insist cannot be done with SQL Server and T-SQL. 😛
I don't think it's appropriate to assume one's trying to cheat a job when he's reading interview questions. but, I do think it demonstrates that he is doing his homework for researching and getting familiar with the situation he's gonna face. I would think anyone would be scare to have an employee who doesn't get as much as information he can when he's on or before an assignment. A interviewee's assignment is the interview. When resolving a critical situation at work, I get as much as the information (either from technical side or business side) I can in order to exercise best judgement for my boss and my company. I see no reason not to do the same for my own critical matter, which is interviewing. I think it's an act of being responsible to myself.
I would appreciate you asked my intent of purchasing at the first place, instead of pretending to ask me to review the content of the training video. I did give you a sincere review of the training video.
and why spent money on it? brent ozar is pretty successful in his SQL Server Training and does have good products. I would like to see if they have different perspective on interviewing.
Lastly, I do think one can cheat on a certification, but I don't think anyone can cheat a dba job just by memorize all those interview questions. DBA requres not only technical skill, but also much of process of thinking skills, research and evaluation skills, decision making skills... and etc. It should be easy to identify who is memorizing the answer, who does have experience.
Anyways, i sepnt too much time on this thread.
Heh... if all that's what you think is the reason I asked, then you need to spend a LOT more time on this thread because I'm telling you much more than what you paid Brent's group for. For what it's worth, you just failed the first tests of effective communication and fit by not actually determining what or why something was asked before jumping to the wrong conclusion. 😉 If you want to be a DBA, you need to grow a bit thicker skin and never jump to such conclusions without much more information.
The reason I asked at all instead of just blowing you off like I do most folks with the type of question you asked is because you seemed to want to do some proper homework, although you did complain later about the overly simple questions (that could be a good thing or a bad thing). And that's the whole point I'm trying to make if you'll take the chip off your shoulder long enough to hear and understand. If you think any of the questions on an interview deserve a one or two word answer or a rote definition, you're dead wrong. All sorts of fakers and posers can do that.
The real question behind every question that an interviewer asks is "What does this person actually know and what will (s)he bring to the table if we hire him/her"? Expounding on such simple questions will demonstrate that you not only know your stuff but that you've actually used them and that you can communicate that knowledge, as well.
If you want questions to practice with, do a Google search whether they're T-SQL or System questions. That's why I said I don't understand why anyone would pay for such a thing. If you understand the point I've been trying to make about what to do during an interview and practice that using those questions a guidelines and actually do understand what you're saying, then you'll be golden.
I can't help you get that thicker skin you'll need or get you to drop that silly chip off your shoulder, though. The best way to get a thicker skin is, like I said, pretend you've worked with and have known the interviewers for a thousand years. As for the chip on your shoulder, make sure that you actually understand what's going on before your alligator mouth overloads your hummingbird butt. ;-):-D
And take all of that as a form of "tough love" from a fellow DBA that's been where you currently are.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2015 at 2:34 pm
To continue a bit, if you don't go into an interview with a nicely indexed couple of clamshell clear folders that clearly demonstrate that you know how to solve problems (well documented code examples that you've written) and some examples of system or application level diagrams that you've produced, and haven't practiced walking someone through that work, then you're just like everyone else... unprepared for the interview. 😉
Also, if you participate in any forums or have a decent blog, make sure that they're aware of that. Just make sure that you don't have stupid things in your blog like using a WHILE Loop instead of good set-based code.
Of course, make sure that NONE of that information is proprietary or personal information in any form. They have to be generic as possible so that they don't think you're going to blab their trade secrets if they hire you.
This is the "YOU" show and you need to make it a good show without coming across as being arrogant or... having a chip on your shoulder. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2015 at 2:42 pm
Heh... almost forgot. I asked you a question so that we might be better able to help and you didn't answer it because you were too busy taking things the wrong way. 😀 Now that you know that I'm truly "not slamming" here, here's the question again...
What kind of DBA position are you shooting for? Pure admin DBA, application DBA, or hybrid DBA?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2015 at 3:31 pm
Jeff Moden (1/31/2015)
yoshii (1/31/2015)
not sure where's this thinking of "reading interview questions = cheating a job" coming from. there're billions of people on earth. there are people trying to cheat a dba job. but, there are people out there with experience and knowledge, however don't have good interviewing skills.BWAAA-HAAA-HAAA!!! Ah, my young friend, you've got it all wrong. Where did anyone say it was cheating in any of the previous posts on this thread? :blink: I sure as hell didn't. So far, you're the only one. Think about that for just a minute before you produce another outburst and read on. I've got some good stuff for you if you're willing to listen and understand. Seriously...
Heh... ironically, what you posted about them saying "take a deep breath and calm down" is probably the best advice there is. Go in, be yourself, and take every question as an opportunity to show your stuff. Pretend you've been working with them for a thousand years.
an interview usually last 45min to an hour. for phone screening it may only be 30min. It takes quite a skill to show ur skills and knowledge to a stranger within a short time-frame. it goes without saying that there maybe tricks built-into questions. It goes without saying that interview settings are not mean to be the most comfortable chitchatting session. Psychological effects also play a role.
Ok... let me play your words against that... "not sure where this thinking of "them trying to trick you"" comes from. Consider that a lot of people are "book smart" and have memorized a whole bunch of things by rote memorization. Interviewers are well aware of that problem and don't want to hire someone that can, for example, recite what the rote definitions of what a Clustered and Non-Clustered index are. They want someone that can use the similarities and differences of each to the advantage of the system and the code. There's only one way to find that out and that's to ask some of the questions that you call "trick" questions. For example, if you just sit there waiting for the next question after you've done such a recital of the basic definitions of the two, then you can expect someone to ask "OK, good. Can you tell me what Non-Clustered Indexes have in common with the Clustered Index, why that's important, and when you would choose one over the other?" or "What can you add to a Non-Clustered index to sort of make it behave like a smaller version of the clustered index"? And, is it a "trick" question to give you some column names in a table and ask which one(s) would make the best clustered index and why?
You can avoid such questions by anticipating that such follow-up questions will be asked and answering them as part of your answer on what the differences and similarities are. You say that it takes "quite a skill show ur skills and knowledge to a stranger within a short time-frame". No it doesn't. All it takes is the understanding that the more you can correctly spill your guts about things they've asked you simple questions about, the better off and more impressive you're going to be. Just be careful not to be arrogant about it because they're also evaluating for whether you'll "fit in" with the team.
Here's another example of what I'm talking about. To loosen up the interviewee, I tell them that I'm going to ask them some simple questions and that I never ask trick or even esoteric questions. Then I ask them how to get the current date and time using T-SQL (it's actually amazing how many people I've interviewed that don't know the answer to that simple question, but we'll save that for another discussion on "resume liars, fakers, and posers").
Of those that actually do know the answer, most answer with either GETDATE() or CURRENT_TIMESTAMP or both (if I'm lucky) and then they just freakin' sit there instead of strutting their stuff! Anyone can regurgitate the name of those one or two functions including those that ONLY know the answer(s) to the question without understanding anything about the functions. Here's how I end up answering such a "simple" question when I'm being ingterviewed. Ready?
"There are currently six functions in T-SQL that will return some form of the current date and time. GETDATE(), CURRENT_TIMESTAMP, and SYSDATETIME() are nearly identical in that they all return the current date and time according to the clock in the server. GETDATE() and CURRENT_TIMESTAMP are accurate to 3 miliseconds as a DATETIME data-type and SYSDATETIME() is accurate to 100 nano-seconds as a DATETIME2(7) data-type. At the max, both take 8 bytes of storage but, at the expense of what can be displayed, DATETIME2 can take as little as 6 bytes. You could use the 4 byte SMALLDATETIME but you have to be really careful of the "minute" rounding into the next day. There are two additional functions that will return the UTC version of a DATETIME and DATETIME2 data-type and one that will return the "datetime offset" version. I don't use those last 3 very much so I don't have them memorized but I know where to find them in 'Books-Online'. The range of DATETIME-based functions is 1753 through the year 9999. The DATETIME2-based functions have a range that starts in year 0001. I question how accurately though because the current Gregorian Calendar wasn't 'universally' accepted until sometime just before 1753. Since the DATETIME data-type doesn't take up that much extra room and has some serious advantages in the calculation and aggregation of duration over DATETIME2 and the other newer data types, I generally stick with the DATETIME data-type unless there's some compelling reason not to such as increasing the possibility of portability."
Something less than 2 minutes to say that and I now have their full attention. If they cut me off somewhere in all that, that's OK. I consider that a part of the "fit in" test. Depending on how they've cut me off, it might be a good indication to me that I might not actually want to work for them. You see, I'm not the only one being interviewed. I'm also interviewing them for attitude, thoughtful communication abilities, and whether or not I could actually "fit in" with the team. 😉
Could YOU answer that "simple" question in such detail? Maybe not. But if you just say "GETDATE()" and sit there like a dog waiting for the next piece of cheese to be balanced on your nose, you're not going to make as good an impression as you could. Offer up what you do know. It's not like you have to "plead the 5th" during the trial known as a "job interview". 🙂
You should see how I answer the "Why is a manhole cover round" question...
"The standard answers are that circular objects are easier to mill to a tolerance, the pipes they cover are usually round, you get the greatest diameter/width for the given amount of material making it a very strong shape as well, you don't have to align them in any fashion to properly set them in place, and their constant diameter makes it impossible to drop the cover into the pipe provided that the hole is a tiny bit smaller and also of constant diameter and proper rigidity. On that last point, circular and spherical objects are NOT the only shapes with a constant diameter." That's when I go into a short explanation of Reuleaux geometrical shapes and Meissner bodies. Then I show them the trick of how to pass a quarter through a hole in a piece of paper the size of a dime without tearing it while explaining that the paper represents some people's perceptions and limitations and the quarter represents that "impossible task" that they insist cannot be done with SQL Server and T-SQL. 😛
I don't think it's appropriate to assume one's trying to cheat a job when he's reading interview questions. but, I do think it demonstrates that he is doing his homework for researching and getting familiar with the situation he's gonna face. I would think anyone would be scare to have an employee who doesn't get as much as information he can when he's on or before an assignment. A interviewee's assignment is the interview. When resolving a critical situation at work, I get as much as the information (either from technical side or business side) I can in order to exercise best judgement for my boss and my company. I see no reason not to do the same for my own critical matter, which is interviewing. I think it's an act of being responsible to myself.
I would appreciate you asked my intent of purchasing at the first place, instead of pretending to ask me to review the content of the training video. I did give you a sincere review of the training video.
and why spent money on it? brent ozar is pretty successful in his SQL Server Training and does have good products. I would like to see if they have different perspective on interviewing.
Lastly, I do think one can cheat on a certification, but I don't think anyone can cheat a dba job just by memorize all those interview questions. DBA requres not only technical skill, but also much of process of thinking skills, research and evaluation skills, decision making skills... and etc. It should be easy to identify who is memorizing the answer, who does have experience.
Anyways, i sepnt too much time on this thread.
Heh... if all that's what you think is the reason I asked, then you need to spend a LOT more time on this thread because I'm telling you much more than what you paid Brent's group for. For what it's worth, you just failed the first tests of effective communication and fit by not actually determining what or why something was asked before jumping to the wrong conclusion. 😉 If you want to be a DBA, you need to grow a bit thicker skin and never jump to such conclusions without much more information.
The reason I asked at all instead of just blowing you off like I do most folks with the type of question you asked is because you seemed to want to do some proper homework, although you did complain later about the overly simple questions (that could be a good thing or a bad thing). And that's the whole point I'm trying to make if you'll take the chip off your shoulder long enough to hear and understand. If you think any of the questions on an interview deserve a one or two word answer or a rote definition, you're dead wrong. All sorts of fakers and posers can do that.
The real question behind every question that an interviewer asks is "What does this person actually know and what will (s)he bring to the table if we hire him/her"? Expounding on such simple questions will demonstrate that you not only know your stuff but that you've actually used them and that you can communicate that knowledge, as well.
If you want questions to practice with, do a Google search whether they're T-SQL or System questions. That's why I said I don't understand why anyone would pay for such a thing. If you understand the point I've been trying to make about what to do during an interview and practice that using those questions a guidelines and actually do understand what you're saying, then you'll be golden.
I can't help you get that thicker skin you'll need or get you to drop that silly chip off your shoulder, though. The best way to get a thicker skin is, like I said, pretend you've worked with and have known the interviewers for a thousand years. As for the chip on your shoulder, make sure that you actually understand what's going on before your alligator mouth overloads your hummingbird butt. ;-):-D
And take all of that as a form of "tough love" from a fellow DBA that's been where you currently are.
When we meet at PASS 2015 you are going to have to show me that trick with the quarter.
January 31, 2015 at 4:14 pm
Lynn Pettis (1/31/2015)
When we meet at PASS 2015 you are going to have to show me that trick with the quarter.
Not sure I can make it to PASS 2015 but you don't need me to show you. I already gave a strong clue as to how it's done in the "manhole" paragraph. 🙂 Here's another hint though...
In 2 dimensional space, which is longer? The diameter of a quarter or half the circumference of a dime? As Scott English and Larry Weiss would say...
"Bend me, shape me, anyway you want me
You got the power to turn on the light"
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2015 at 5:57 pm
Well, that escalated quickly! :hehe:
I read your epic post(s), so I figured I would chime in too.
Jeff Moden (1/31/2015)
The real question behind every question that an interviewer asks is "What does this person actually know and what will (s)he bring to the table if we hire him/her"? Expounding on such simple questions will demonstrate that you not only know your stuff but that you've actually used them and that you can communicate that knowledge, as well.
I have to disagree with this. I get what you're saying for sure. BUT, big BUT here, sometimes you can come off as a complete snob or know-it-all when you go that detailed or even that long into simplistic questions.
If you can get around that bad judgement of character, you can also risk running the interviewer out of time where they cannot fully evaluate you as a potential candidate. This is actually common advice across all industries and positions that has been given for a few years now.
Regardless, I've experienced simple questions like that in my past as a new guy to SQL Server. I think my last one is whether or not I knew what a CTE was. I just smiled and said, "Yeah, I know common table expressions and use them all the time." Then I shut my trap. The Interviewer then asked without skipping a beat what the basic syntax was and I told him. He then asked how I used it in practice. This is where I used some more time to go into even more detail based on my own work experiences using common table expressions.
As someone who has a big mouth who runs off the beaten path all the time, I could have went in on this guy as soon as he asked me about what CTE stood for. But I didn't. I figured if wanted to know more he would ask and he did.
That's just my opinion though. I kept it simple and fun. Most of my interviews in the past outside of the database world have been pretty much the same. I actually focus more on my fun attitude and outgoing personality most of the time because I'm not applying to be a master at SQL (which I almost always say to the interviewer that I'm no master, but I love SQL and growing in knowledge every day). I'm applying to be a team player, someone is able to learn from my work and someone who knows enough to succeed or better. 😎
January 31, 2015 at 6:48 pm
xsevensinzx (1/31/2015)
Well, that escalated quickly! :hehe:I read your epic post(s), so I figured I would chime in too.
Jeff Moden (1/31/2015)
The real question behind every question that an interviewer asks is "What does this person actually know and what will (s)he bring to the table if we hire him/her"? Expounding on such simple questions will demonstrate that you not only know your stuff but that you've actually used them and that you can communicate that knowledge, as well.I have to disagree with this. I get what you're saying for sure. BUT, big BUT here, sometimes you can come off as a complete snob or know-it-all when you go that detailed or even that long into simplistic questions.
If you can get around that bad judgement of character, you can also risk running the interviewer out of time where they cannot fully evaluate you as a potential candidate. This is actually common advice across all industries and positions that has been given for a few years now.
Regardless, I've experienced simple questions like that in my past as a new guy to SQL Server. I think my last one is whether or not I knew what a CTE was. I just smiled and said, "Yeah, I know common table expressions and use them all the time." Then I shut my trap. The Interviewer then asked without skipping a beat what the basic syntax was and I told him. He then asked how I used it in practice. This is where I used some more time to go into even more detail based on my own work experiences using common table expressions.
As someone who has a big mouth who runs off the beaten path all the time, I could have went in on this guy as soon as he asked me about what CTE stood for. But I didn't. I figured if wanted to know more he would ask and he did.
That's just my opinion though. I kept it simple and fun. Most of my interviews in the past outside of the database world have been pretty much the same. I actually focus more on my fun attitude and outgoing personality most of the time because I'm not applying to be a master at SQL (which I almost always say to the interviewer that I'm no master, but I love SQL and growing in knowledge every day). I'm applying to be a team player, someone is able to learn from my work and someone who knows enough to succeed or better. 😎
I will have to disagree. One of my phone interviews for a position with my current employer actually ran shorter because as I elaborated on an answer to one question I answered the next two the interviewer was going to ask as well. As to knowing the syntax of things, basic syntax I can talk about off the top of my head, getting into more complex syntax, that's what Books Online is for, no need to memorize everything just that which you use on a regular basis.
January 31, 2015 at 10:27 pm
Thanks to Jeff and others' contributions. All discussions are valuable.
@jeff. Thanks for the valuable feedbacks!
In my opinion, communication not only happens verbally, but also at implication level and non-verbal level. Actually, research shows that only about 30% of communication is in verbal form. Cheating is not the best sounding word. If I got you wrong, my apology. It's just I know that there're people who do not recommend reading interview questions before going into an interview.
for trick questions, in my opinion, ur examples are elaboration of technical facts, which stay on the technical side. I think trick questions will be more like you are being presented with 2 choices without scenario given, while u know there're advantages and disadvantages for both options, but u are being asked to choose one from the other. let's say you choose something different from the interviewer and the interviewer use ur choice to predict how u will work in his place, while you actually is willing and no problem of adapting to their practice. or any questions that may lead you to think ''so what's the story behind? something happened at this comany/team before?'' In short, a behavior test hiding behind technical facts.
about money, i have no problem spending money, if I think I can benefit from the products. However, after using it, I have no problem writing a review on how I like or dislike the products.
Thanks again, wish everyone well in his/her career path.
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply