Karl Seguin

Wow,

I would fail soooo bad....

Then again I've only just begun doing stuff in C#.  So obviously I love DataSets. lol

Sorry.

But these did make very good points.

Datasets aren't always bad...  that said, there is a very limited place they should be used.  Usually in winforms.

hello karl, can you spare me a plane ticket to Canada so I can give your exam a try. hehe ;). Nice one.

You might also look if its localized, db properly normalized, uses side-by-side assemblies, multiple projects instead of app_codes, this is extreme lols...

I agree with Baz, Datasets are great for setting up parent child relations when doing reporting with nested repeaters on the web.  Other than that I don't use them for anything else.

My company administers a test to each of our candidates, and most of them are astonished and hint that they've never done this during an interview. I agree with most of this post, with the exception of the inclusion of Google (other web access).  

We had a candidate that was admittedly an inexperienced developer, but since we were (and are) tight for people, we decided to give him a shot at the test, expecting him to ask questions and do as much as he was capable.  Several hours later, we had a freshly Google'd application which met most of the criteria.  The only reason we even caught it was because he had trouble integrating all the requirements in the time allotted.  After a few searches we found the identical source code ourselves.  Had he just a little more experience, we would have been stuck with a near-novice, plus the cost in terms of time getting him up to speed only to later learn that he was incapable of the performing the job.

I believe it is sufficient to supply the candidate with the full MSDN documentation (which contains structures of things like connection strings :) ) and let them figure it out.

Also make sure you clean out the machine they'll be working on, I had one person copy code from a previous candidate, and call it his own.  One problem, he copied the files with a create date of 6 months before he did the test, if he copied the code with notepad into his own project we would not have picked this up.

Very good article, Karl. Lot's of good points. I'm just curious to hear why you think DataSets are so bad? We use them all the time in our ASP.NET 2.0 web projects to pass data from the Data Access layer up to the GUI layer. I know they are not perfect but it's a lot quicker and simpler than writing custom objects.

Even better is to pair program with them on the real production codebase.  A canned coding test is never as good in my experience.

Take into account that in an interview, I don't know a lot of people who would be able to make use of a good framework in that timeframe.

Given a computer and access to the net, it would take about an hour just to set up the env so I can start working.

There is also the issue about what people will think if they can't understand what I am doing. I was in interviews where I literally had written a piece of code in 10 minutes, and spend 30 trying to explain how / why it worked.

   * Datasets and SqlDataSource are very bad

XXDataSource - Bad, DataSet not so much for this particular case.

   * Data access shouldn't be in the aspx or codebehind

   * Objects should be properly disposed of (using either try/finally or usings)

Agree! to both.

   * Check how exceptions are handled: I don't expect anything in the global.asax Application_Error but exception swallowing is also very bad

In general, I tend to not handle exceptions in asp.net, and leave it to final production, by sticking an error page.

some stuff (db down, for instnace) you just can't do anything about, and it is useless to try.

   * Naming convention might not be a big deal, but I hate Hungarian notation

I really don't care about what they use. As long as they are internally consistent, that is fine.

If they aren't, that is a problem

   * No hard-coded connection string (or at least a //todo, move to config)

   * Parameterized queries for either sprocs or in-line

Agree!

   * Caching!

Not something I would do in a task like this, to tell you the truth.

I would also like to add my weight to the "data sets aren't that bad" argument. I agree that they are not suitable for every application, but they do have a place.

If you gave me a spec in which you said it was "very simple" and only gave me an hour to write a solution,  I would use datasets and I believe I could defend my approach.

I would also not attempt to write a caching solution for something like this.

You have to remember the that over complexity is BAD!

"Datasets...are very bad" and "Caching!"

Could you please elaborate?  I'm guessing that you don't want to see a 0-tier solution.  Meaning, you don't want to see DataSets populated from SQL and then widgets populated by directly iterating through the DataSet object.   You'd prefer to see Employee objects defined and then populated from the Datasets returned from the SQL call.  You're looking for separation of data access and data presentation. Right?

And I certainly would not implement caching unless explicitly instructed to do so.  

Sorry everyone...I've always had a thing against datasets...I could see past it for this particular example (it's true that they are particularly well suited). The only justification that I have is that I did state it would be part of a larger enterprise application.

I would like to see a hint of an actual business layer and some type of representation of a "User" class (especially since it's basically 4 properties). If the actual data-access behind the scenes uses DataSets that would be totally cool.  What I'm specifically trying to avoid is the..

Page_Load

if (!IsPostBack)

{

  SqlConnection connection = ....

  da.Fill(ds);

  Grid.DataSource = ds;

  Grid.DataBind();

}

AS a couple people mentioned..there are some other things worthy of taking into consideration..namely how they setup their DB and whether localization fits in at all (especially since I live in a VERY bilingual town).

As for caching...I just think it's underused...you're all right that if I expect it to be there I should specify it. It's not like it's a NO SOUP FOR YOU kinda deal, always just nice to see :)

Barend: How on earth would you NOT notice the candidate copying a previous solution? Do you leave the candidate alone during the interview?  If so, what's the point of giving them a programming exercise at all.  The point of the interview is to find out how they work and whether they will be able to work in your team.  If you're not there while they're working how will you find that out?

Matt:

Personally I like to sit them at a desk and let them work on their own. I keep an eye on them though, and like I said, pop over 2-3 times to ask how they are doing. A L shape configuration is nice, so you can just take a quick peak over your shoulder.

Great post.  Since a great deal of a developer's work is usuallly fixing/maintaining legacy code, what about giving the candidate some smelly code (with unit tests) and asking them to refactor it. Billy McCafferty has contest going on where's he doing this (http://devlicio.us/blogs/billy_mccafferty/), but I think it would be a good for interviews as well.

Ok, so "DataSets" are Evil, but Custom classes are ok?, So, if you use Typed DataSets, then you are closer to Custom classes, right?, and then less evil? :)

Well, I use TypedDatasets, and that works very well.

The code-example you provided in you last comment here is violating everything, one thing is that you use an generic dataset, another thing is that you bind directly to the dataset itself, not giving anyone any clue about what you want out on the form, third, you are doing dataccess in code-behind...

So, that was not an good way of telling datasets is evil, Or?

AsbjornM:

In my code example, I said that was the kinda of code i wanted to AVOID. So yes, I've violating EVERYTHING...which is exactly what I don't want to see :)

I don't want to see untyped datasets (yes, typed are better) and I don't want to see dataaccess in codebehing :)

dr. job, swear to me you won't push me to use typed datasets again ;). Now Im almost done cleansing some my modules that initially uses typeddatasets. I know its bit OFF topic to the original post but I take it from my experiences with TD. Its a failure to me, its very difficult, its pain. Got  to always bring Subversion with you so you can always Revert onces things messed up.

I had something to say here, http://community.devpinoy.org/blogs/dehranph/archive/2006/09/26/.NET_3A00_-10-TypedDatasets-Pitfalls.aspx

And I have lots of negative experiences with TD. My friends who comments might be corrct that maybe I'm just a newbie to TD, but I dont want to take chances and compromise my project again.

So dr. job, swear to me lols ;)

DataSets Suck

DataSets really are very evil for anything that has to do with performance and code quality. Here are just some of the drawbacks that you can't work around in my experience:

- Allocates massive amount of objects on the heap, which puts a LOT of pressure on the GC in any high usage scenario. Time in GC % exceeding 20 % is not uncommon in server applications that use DataSets extensively (When GC runs, all other threads are suspended, effectively choaking your application throughput...). Just doing a 'new' on a reasonable sized dataset class can allocate several hundreds of Kb (I have seen 400+ kB and hundreds of objects allocated from a single 'new MyDataSet()' several times).

- DataSets serialize bloatedly. Since the DataSet object model is massive, a serialized dataset is very large.

- DataSets as a part of any web service interface makes integration with other platforms very hard, which rules it out in any mixed architecture (DataSet serialization is memory intensive, formated rudely and a pain in general).

- DataSets do "too much". Most of the times you only need some of the features, but you always have to pay for all of them. For instance, the event model is very rich which means that it is not uncommon that ds.AcceptChanges() consumes 95 % of your CPU resources in highly compute bound applications (actual result when profiling server application) - even when you are not sinking a single event. Since you can't turn off these features you are powerless unless you stop using DataSets.

- DataSets encourage working with data in a relational, set oriented way instead of instance of types, which works agains the OO nature of .NET. To elaborate:

- DataSets forces a separation of data and behavior which firmly pushes the coding style towards being very procedural (OOP becomes unnatural). This leads to several bad things. Some examples are no data encapsulation, fragile client code, massive amounts of fan-out-dependencies in client code and the same maintenance problems that plagued structured programming, etc.

To be honest, DataSets as a general purpose data access mechanism for large application is just a bad choice. I would only use it for small, in-house apps or maybe, maybe, very specific scenarios involving zero performance requirements and multiple data sources.

Well said Mathias. I agree.

We had to pull out some data from a database and dump it all to a table recently. This was a 1 time operation. Of course we used a DataTable with a DataGrid, but otherwise I've managed to avoid them for the better part of 2 years :)

I read this article recently, and ironically enough had an interview very similar to this earlier today. I got the job...I owe you a virtual beer (kinda ;-) ).

Well I agree to the exam pattern recommened except for giving the whole MSDN to start with .... If hiring a Programmer how bout start with a Little Logic exercise ..offcourse all of them and us also know it but sometimes given a situation it helps if the person has coded or went through the Syntax atleast ...then talk bout Adding data to a dataset ....... cuz many of the guys dun pas the if then else .....

First off, a correction. In my recent post on OLTP using DataSets, I gave four methods that would allow

I agree that DataSets are bad. However, I don't think you should necessarily hold it against a candidate for using them in an interview. Having said that, it's always a good idea to ask them why they're using them, what the pitfalls are, and what alternatives they might consider.

Hungarian notation is similar -- it's very much a matter of taste, and it's a good idea to ask your candidates why they are using the specific conventions that they have chosen. A good candidate will be able to tell you the difference between Apps Hungarian and Systems Hungarian, or even point you to Joel Spolsky's essay "Making Wrong Code Look Wrong" where he explains how to form Hungarian conventions to help you write secure code. (www.joelonsoftware.com/.../Wrong.html)

I think it's somewhat fair.  I've been to an interview where I had to do all that plus the database and they nitpicked at not having the PK set.  Well I did not have enough time dipshits.  Um, yea, I build databases without a PK.  Um, I was trying to hash out the layers and the damn UI.  I did not have time in an hour do to the Database too.  I like the fact that you stated you'd create the Database For them.  Instead of them having to hash out the procs, just ask them a lot of questions about procs if you're concerned about their SQL skills after the fact and let them concentrate on the OOP code during the interview.  Obviously you want good SQL skills but an hour for all that is not fair.  I like your approach.

You didn't state what LEVEL this position is for.  

If it's for a mid-to-Sr. or Sr. fine. I say that because you are expecting caching and a couple of other things I personally would have kept out and then instead I would just asked them about how they would handle those situations verbally to see their response which would tell me if they even knew what they were talking about.   I think testing for n-layer is essential (basic DL, BL, and PL) but I guess I'd give the candidate a couple  hours at the least and make sure you tell them that's what type of architecture you expect.  Why do I say this?  because they may not assume you expect all that in an hour...and maybe typically they would use an N-layered approach but maybe they are doing a rush job and focusing on other aspects for you because you only gave them 1.5 hours to begin with.  If you expect them to stub out an n-layered example, make that clear.  The developers who have not done this, will fail.  You can count on that so letting them know beforehand is not a risk to you in my opinion as to being able to test their skill set.

There are certain questions you can ask to gauge if the know what they are talking about rather than having them hash out caching and a couple of other things in an hour.

Otherwise I do like your approach in general other than having to include the caching bit and a couple others that I think are just nit picky such as not hard coding your connection string, etc.  Sure while it's definitely critical that they don't hard code connection strings, I'm sure that's a minor detail they would probably do in clean-up later or just when they had time.