Is all code really code? One question from an interview
-
My answer would be that embedding "200 lines of business logic" in the data layer violates three-tier (or N-tier) architecture and the programmer should remove the business logic from the database. It's interesting to me that all the previous responses take a programmer/developer point of view but nobody has responded from an architectural point of view.
-
I had a newbie programmer that loved T-SQL. He would write long, complex stored procs and do things in T-SQL that I would never consider doing (being a big fan of simplicity). When he would ask me to help him debug his unexpected results, I would always give him the same answer: start small and build up your query. Do a SELECT on your main table. Did you get the expected results? Add a join and rerun. Still get the expected results, then keep building. This process will pinpoint whether the problem is your data or your syntax. He usually had it solved within 15 minutes. My only question is why did I have to give him this advice more than twice???
-
I think it's difficult to compare SQL code to VB (or any other language) code. There are both real and perceived differences.
SQL code is generally on the back-end. VB (or any other language) code is generally on the front-end. They often have fundamentally different tasks to perform.
The use of variables in both kinds of code is fairly similar and a debugger can help resolve those issues. Using a debugger with VB code makes it simple to step through each instruction and see exactly where things go wrong. Each statement usually has a rather narrow impact on the overall functionality. However, a single statement in SQL code often has a profound impact on the overall functionality. That difference may render a debugger ineffective when working with SQL code. As an example, consider an incorrect INSERT/SELECT statement used to populate a temporary table for further operations later in the routine. A debugger would not reveal what might be wrong with the statement. A debugger would not "step into" the statement and show the internal workings. Even if it did, a debugger would not understand that some inner join should really be an outer join. That kind of problem is common and it's probably going to be found only by examining the source data, the result data, and the requirements.
There also seems to be a perception shared by many SQL Server professionals (including, but not limited to, developers) that SQL code is merely "script". I suspect that something called "script" will not receive the same level of respect as something called "modules". SQL Server professionals do not seem to consider SQL code to be comparable to VB (or any other language) code. They appear to believe that all SQL code, regardless of how complex it may be or how well-written it may be, holds no value. I do not know the reasons behind this thinking. It could come from the nature of SQL code as discussed here. It could be because the vast majority of SQL code that's publicly available is "script" slapped together for a specific administrative purpose. It may even be because all SQL Server professionals think they could write better SQL code themselves. Whatever the reasons, they combine to form a perception that SQL code is less sophisticated than other forms of code.
There are both real and perceived differences between SQL code and other forms of code, so it's not surprising that there are different approaches to writing and debugging the code.
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
-
Number one reason not to use the debugger is that, simply put, it sucks!
A) You have to type in all of the parameters. This can be extremely time-consuming if you happen to have a lot of parameters. Or you can create another stored proc with the parameters already typed in, and debug that. But that just seems like a hack.
B) You can't use the debugger to debug large queries. A 200-line query is not out of the question, and the debugger is totally useless for that purpose.
C) As someone else already pointed out, you can't interrogate temp tables or table variables.
I have found that it takes more time just to get the debugger started, on many occasions, than it would to simply insert a few prints, figure out the problem, and move on to the next issue.
There is simply no comparison between the quality of the Visual Studio debugger and the quality of Query Analyzer's T-SQL debugger...
I also concur with those who said that "check the data" should be the first response.
--
Adam Machanic
whoisactive -
I'm with you! The older I get, the more irritated I get with interviews designed to "stump" the interviewee. Especially when the question is timed at the worst possible moment in an interview (i.e., interviewee is being overwhelmed with "too much information").
As for the answer to this question, I think the answer is that it is subjective and all suggested answers can apply.
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
Interesting responses, but keep in mind this is an interview, not a real life situation and Andy is assessing how the person "thinks". I'd personally lean towards print statements to ensure each step proceeds as expected, though the debugger works as well. Wondering about whether the debugger works or you have rights would be "qualifications" given by the interviewee. "I'd suggest the debugger if they have rights".
I do agree the debugger can be a pain to get working, one of the reasons it isn't my first choice. However, it is a valid way of looking at the problem. Keep in mind as a senior, you're a busy guy, expected to lead and mentor, and working with every issue isn't something you can do. Or be expected to do. I've worked with lots of developers and more often than not they come find me after it fails the first time.
-
But if you are posing this question in an interview, don't you think it's up to too much interpretation to be a good interview question and are you really allowing the interviewee enough time to analyze it? I tend to keep questions in an interview to streamlined definitive questions and answers, not subject to too much interpretation. You just don't have time to play with in an interview for a question like this. Look at how many responses you've already received in this forum and how many differ. Do you think there is any one right and any one wrong? If not, how would you be the expert to determine if the interviewee was really qualified to answer it if you are still questioning the answer yourself? Maybe, he/she has had experience/environment that you have never encountered and they may be right in their opinion.
Still, I dig the whole ponderance the subject brings up!
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
Being a consultant I really dislike questions like this. From my point of view you are waisting my time. With any answer that I could give you won't know if I will or won't be able to perform. NOBODY knows everything and I could know stuff that you might have never dreamed off and the same goes the other way around because we all have different experience. I understand that you want to know more about the "extra mile" abilities but questions like this, for sure, will not get you there.
My $0.02
* Noel -
Seeing as I get this question almost daily I turn the question back on the developer usually such as: Define not getting the expected results? Are you expecting a small or large result set or a single value or row? Then I ask for a 1 minute synopsis of the business logic. We have good developers so with what they describe I can usually point out particular areas where they might start looking for problems.
dab
-
I'm primarily a developer, but also have the DBA responsibilities.
A former colleague of mine (brought up on VB ) actually wrote SQL procedures like VB code. His SPs would therefore be primarily cursor-based rather than set-based.
Bearing him in mind, I'd be tempted to ask first if the SP used cursors. Primary reason being that it may give an impression of the complexity of the job in hand. I would however expect a reasonable effort to have been made to actually find the problem before coming to me. I'm a helpful guy, but when you ask a simple, obvious question and can't get a straight answer on the logic, then you know they haven't looked at it in depth.
PRINT is my friend in most cases.
-
Lots of good responses. Without belaboring the point, Im not trying to stump anyone in an interview. I like questions that elicit questions, that show me how they think. Wow'd would I be if someone could talk about the debugger and the problems related to it. Overall I think very few people walk away from our interviews thinking they didn't get a fair chance to show their skills. And while interviewing is an interesting topic, I think the difference in how we view code and what we consider good architecture are more interesting - at least around here.
-
I tend to agree with most of the people here with my approach to debugging:
- Print statements, or a variations thereof
- Taking apart the sp and running each part separately and comparing the results from the top down
- review the data that I'm using for the test
- Lastly, make sure that NO ONE ELSE is playing with the same data. I cannot tell you how many times this has bit me
I have only known 1 person that couldn't develop (actually REFUSED to develop) without the QA debugger. I looked at it and it doesn't feel right to use it... I know that sounds strange but, I like to walk the code myself.
On the other side: When it comes to VB I use print statements, the watcher, debugger but that IS the tool to use..
Call me crazy I guess....
Good Hunting!AJ Ahrens
webmaster@kritter.net -
"...I think very few people walk away from our interviews thinking they didn't get a fair chance to show their skills."
In the true spirit of 'Office Space' I have to offer some humor.
I can just see the interviewee that hung up from your phone interview, and now has the 'dear in the headlight look' saying, "Yeahhhh, rightttt." 
Technical interviews are tricky and really depend on the interviewer, the team, and the technical environment. However, I really liked this article I had read on how to interview a programmer:
http://www.artima.com/wbc/interprog.html
I tend to lean towards Chris Sells, Scott Myers, Matt Gerrans, and Josh Bloch (sort of); but then, there are other opinions...
...and there ain't nothing wrong with that!Have a great weekend!
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
I think debugging technique is one of the most interesting topcis in programming. As such, this is a great question, IMHO, for an interview. Honestly, the content of the answer may be less important than the mental processes the person being interviewed goes through to answer it.
Lots of people have pointed out that the answer MUST be contextual to the environment. If this were a production app that worked yesterday and for the prior three years, you would have a different response than if this developer was building a new report or extending the existing app in a dev environment. I've personally never used the debugger, but when I was coming up (I've only been around since 6.5) getting the debugger to work was almost a myth. I'd heard of people getting it to work, but I'd never actually talked to anyone that had. I suppose I just got good at 'got here' programming with print statements and never bothered since.
If I were to ask this question in an interview, I don't know that I would really care if the answer I got was 'turn on debugging', 'turn on tracing', 'add print statements', 'use raiserror', 'insert into a debugging table', etc... There are a ton of perfectly valid ways to debug a stored procedure. What I would look for is to see if it sounds like the candidate has done it enough to be able to effectively describe good debugging technique to a junior developer in a way that they can apply it to the environment that they are in. I would half assume that details of his answer will be based on either the last environment he worked in, or the environment that he liked most that he worked in.
I guess to sum what I'm saying, I think the question, as I would use it, would be best suited to finding out if the candidate were clever and could teach that cleverness, or if they were not/could not. I might even hope to get a good anecdote out of them that might provide insight to how they responded to a real situation rather than just how they respond to an academic question.
Matthew Galbraith
-
Matthew,
"Honestly, the content of the answer may be less important than the mental processes the person being interviewed goes through to answer it."
That's an excellent point!
--------------------------
Andy,
"While you you might not agree with the question, I hope you'll think about the range of answers and why so few developers use a debugger on stored procedures."
You definitely accomplished your goal! Thanks for opening this discussion!
Cheers!
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
Viewing 15 posts - 16 through 30 (of 41 total)
You must be logged in to reply to this topic. Login to reply