We Keep Coding

Level 1 C# / SQL Server Developer Test

We're looking to hire a Level 1 C#/SQL Server developer. In our company, a Level 1 developer would have 3-18 months of development experience. When we hire developers, we typically have them create an application based on requirements we give them. They are free to do this at home, within a reasonable amount of time.
We've typically hired Level 3 developers (> 10 years experience) in the past. This will be the first Level 1 we have hired.
I'm looking for help on what sort of requirements/project definition I could come up with to fairly test a Level 1 candidate. Generally speaking, I want this to include creating a database with perhaps a handful of tables, and then creating a WinForms application to read and write to that database. I want to test their skills in designing a database and their skills in creating a C# application to interact with that database.
I want to make it a challenge for a Level 1, but not too easy or hard.
Any ideas?

There are plenty of ideas that you could use:
Travel Booking System
Simple Bank Transfers
Pet Shop
Staff Directory
Help desk Ticketing system
These are just a few things off the top of my head. What I would suggest is choosing a subject that the candidate is familiar with.
By this I mean, if they are interested in a certain sport etc then make the example based around something they know rather than something obscure that they don't know anything about.
This is a test of their ability to code and create database schemas - you don't want them to be concerned about whether they have the scenario correct.

You may learn more about a candidate by leaving the problem open-ended. Tell them to create a solution to a problem of their choice that includes at least:
A database with n tables
A UI with m forms
You'll learn about their interests, how they handle vague requirements, and their problem solving instincts. This is usually more valuable than their ability to follow a rigid spec since specs are notorious for changing.
Check their communication skills by having them explain their choices. If you want to be thorough, have them submit a short written explanation with their solution.

How about one of the following:
A simple event planner? say football fixtures or something..
Database to manage a blog (but i guess they would
write a small website for that)
Bug Tracker

You could give him an incomplete database, let him design three or more tables, see if he follows the pattern.
Then, you could give him some sort of integration to do. Like, integrating an Access or plain text file with SQL Server, through a Console Application.
Lastly, you could put some proposital error in this integration, see how he would interact with it, how he would solve it. It could be an extra separator, something like that.
I guess this way, you would test his ability to develop, and his logic to solve problems.

Why do most people say that data services and the database are the most important parts of a system? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Why do most people say that data services and the database are the most important parts of a system?
From what I have seen, it is the front end development: GUI, WEBUI, XAML that is the most important. Certainly more important than the middle and database tiers.
I don't think it is a big deal to build an application's database. After all, the data schema comes from the business analysis and there is very little "creative" work on the part of the database developer. The same is true for the business logic side (middle tier). In addition, J2EE and the .NET enterprise framework both help to make the business logic simple to develop.
So, what is the database developer doing that is so important? Why do we even need a standalone database developer? Why do most companies still pay a higher salary to middle/backend developers instead of front-end developers?
I believe that developers building the UI (in Java or C#) should have database knowledge. This would let them build the entire application. In my view, it is impossible to let a not-database knowledge person develop the application anyway.
Please let me know what I am missing here.
Thanks a lot.

The front end is usually much easier to change while the backend needs a more through requirements and design phases. If there's a change to the backend, then the front-end will most likely need to change, so change requests dealing with the backend services (db, etc.) will often result in lots of changes through the middle and front ends. A change in the front end usually doesn't affect the backend.
The DBA issue really depends on the size of your project. If you're talking about projects with a few simple tables and a few thousand records, then you're probably right. A real DBA would probably consider that beneath his/her worth to work on that project anyway. A real DBA is more like a systems administrator that specializes in DBMS optimizations. Nearly any programmer can build tables, relationships, views, stored procs, etc. And especially with easy to use ORMs, a lot of the stuff that DBAs used to do isn't really needed. However, a DBA is crucial when working on large projects and large database systems for DBMS optimizations, system configuration, failover configuration, etc.
Your original question doesn't talk about the project scope and I think that's where you're confused or don't see the importance of a real DBA (not to be confused with someone that knows a bit of SQL or does data entry and call themselves a DBA).

I believe the front end side: GUI,
WEBUI, XAML is more important than
middle tier and database tier.
That's kinda like saying the color of a car is more important than the engine and the tires.
It's probably not a big deal to build a database. It is, however, a big deal to build one correctly, optimize an existing one, and maintain a well-designed data store. IMO, that is why database/datastore guys get the big bucks.

Some of the most challenging work I've done as a programmer is dealing with user interfaces (xhtml, xaml, servlets, mvc, asp.net etc). That being said, I think you're running into two different issues. On the database side, as Mathew said, a true DBA is going to be able optimize a large (millions of records) database in ways a regular developer will not know how. On the middle tier, I think the reason the UI is often so complex is because often the developer doesn't really build a true middle/business logic tier. So they end up putting all the logic in the application in the user interface, which is wrong. Finding good developers who know how to build a solid, object-oriented business layer who know domain driven design and OO design patterns is RARE. Build a bunch of classes with just getters/setters that match your database objects is NOT object oriented design. Hence they are worth more.
Other than that, I agree that still, UI work is very challenging programming and should be considered more important than it currently is.

It's all important.

For a small app that you throw together the database doesn't seem that important, but let that app grow and evolve over time and you rapidly run into pitfalls due to poor design.
The database layer and middle-tier are the keys to the longevity and maintainability of your app.

Among many other reasons: With a solid middle tier, you can switch from one GUI to another based on requirements.(say from pre web2.0 to web2.0 design) So A lot more planning is needed for middle and backend tiers compared to a possibly exchangeable frontend.

it's impossible to let a not database knowledge person to develop any application.
Not if you hide the database tables with stored procedures wrapped in web services.
The front end is merely a skin over the real application.
The middle business tier is the most difficult to program IMHO as the business people rarely know what their requirements are, despite thinking they do. They change their minds regularly. Edge cases wreck a nice design and can be very difficult to implement.
It doesn't matter how good your GUI developer is if he's writing a front end on a poorly written business tier. And you can't write a good business tier on a poorly designed database.
In the end, it's much simpler to rewrite a GUI than it is to change the database layer or middle tier, as a change in either of those affects all the subsequent levels of the program.

It is impossible to answer your non-question.
It is based on a premise that everyone thinks the database is the most important thing in all systems - which is false, obviously - not only do all people not think that, many systems do not use databases and many experienced people will agree that the most important parts of different systems vary from system to system.
In fact, by the definition of a system, every part has to be important! It's possible that some subsystems can be more expensive than others, some more fault-tolerant that others, some replaceable in a modular fashion and others not, but all are PART of a SYSTEM, and thus ARE important. The idea that one is more important is hard to quantify. It's conceivable that some parts are optional (like "unfunctional" decoration), and thus might not be considered part of the system. However, in the larger view of the system, users participate and their efficient and joyful interaction with the system is vital to ensuring its success.
To use an analogy already posted here, the paint on a car might not be as important as the engine, but would someone sell an unpainted car? - not likely (unless that was the definition of the product - like unfinished furniture).
In the same way that an engine is more expensive than a paint job, I would expect we pay people more to design engines than to select colors of paint.
There's a spectrum of specialties and complexities in all systems.

Logic of business always be simple with J2EE or DotNET enterprise framework help.
Sure, coding the business logic tends to be straightforward...if you don't have to worry about exceptions, error handling, actually getting the right requirements from the business, etc. Add in the ability (needed now more than ever) for a single application to support multiple front-ends (web, desktop, mobile), and all of the sudden that "simple" business logic become a critical point.

It doesnt mean everybody can code well in VC++, even though they have a knowledge in c++.
In current technical world, every developer got basic knowledge about most of the latest technologies. It doesnt mean they are ready to design a system with all the technologies.
Its all comes with experience and your specialization. Remember they paid well for doing DBA, not doing UI design.
It doesnt mean UI developers cannot design a DB. You can also become a good DB designer, if you have enough experience with design a database.

What is the general view on using Staging tables? We use them a lot for Order imports from External vendors

We have been having a lot of internal debate regarding staging tables. Some are view staging tables as archaic and will prevent the ability to build re-usable services, etc. It is also being communicated that these will prohibit the business to grow and handle expanded business channels.
I am not necessarily for or against either option, but I do know that having the staged data has been a life saver in many occasions and has made it really easy to re-import orders we have had issues with.
Just wanted to see what others thought about staging data and what other methods are being used to handle scenarios similar to ours (Taking orders from external partners, Amazon, etc and importing them into our ERP system).
Thanks,
S

Some places I've worked I've used staging tables, others I've used other techniques.
Each one has its own advantages and disadvantages.
That said, don't worry about it.
If some data feed comes along that requires some method other than what you are doing, then you'll come up with a new solution.
Change is driven by requirements.
(personally, when someone comes to me and says "We have to change to X because what we do now is inefficient and bad and witches will come and eat our children", they have this image in their minds that on tuesday, we will have an opportunity to triple our client base but only if we do this new thing, but if we don't get cracking on it now, then we'll miss the opportunity because none of those potential clients is willing to wait even a minute and they'll all demand the exact same thing and we can build exactly what they want right now even though we have no idea what they want HURRY HURRY HURRY AND DON'T BREAK ANYTHING. Which, of course, isn't how anything works. A single client (or whatever) comes along and says "Hey, we want your services, can you accept our XML?" to which the response is always "Sure thing", and then you get tasked with it and can make intelligent decisions, and plan things out. As opposed to the "chicken with its head cut-off" methodology preferred by people who like technical words but hate knowing anything tehcnical)

There is no reason for a debate - you have a working system. Anyone who thinks their "re-usable services" theory can do it better should put up or shut up.
Let them build a test implementation on your development servers for a common high volume scenario, and compare it to the current system - including criteria for recovery and re-import after a failure.
I hear this all the time where I work as well (usually from managers who just read an article about SOA and XML) and in situations dealing with large amounts of data - bulk imports into staging tables can handle a much higher data volume than any type of web service.

What kind of application should I develop for the purpose of learning right concepts of programming

I work as a ERP programmer, mostly with MS SQL and some kind of scripting programming language.
I also wrote some simple projects in C# (a web application for our company and a simple windows service) and I like it very much, so my next job will hopefully be in .NET environment.
Now I'm learning C# from a Wrox book and I went through all the basics chapters. This is all fine and nice, but in my opinion a better way to learn a language is through a real project. So my question is: what kind of application should I write, so that I can use all the fancy-named concepts, like inheritance, delegates, generics, reflection, LINQ,... It would be nice if it also connects to SQL Server.
I thought about personal expense management system or scheduling system. Any other ideas?

Rule number one in such projects: It must be fun thing, or something you expect to profit from it.
When I was in the same place as you (and I mean the same...C#...WROX book...) I went for an engine of text based Adventure Games.
It has everything you described above, and more important I had fun writing it and later see people play it.
So, it really isn't important what you choose, as long as you enjoy it (and it's scope is big enough).

Any well-designed application could use any or all of those concepts. Language-specific books have a tendency to focus exclusively on language details (for good reason) and generally neglect basic design principles. Another important point is that delegates, generics, reflection, etc. all have their place, but they shouldn't be implemented in an application just "because". That can cause unnecessary complexity.
All of that said, pick a project that interests you. Even better, something that you would actually like to use. Then, before even coding, think about how you should structure the application so that it is easy to modify later and add features. If you're putting all the code in the form/code-behind page, you're probably doing something wrong.
Spend some time learning design patterns. These are "best practices" of organizing code that have developed over time. No need to reinvent the wheel.
Hope this helps.

Scratch your own personal itch...

I'd go for some sort of simple CRUD application, which will exercise your database skills (and give you an opportunity to use a LINQ provider against your database), but perhaps not too simple; i.e. more than one table.
There's nothing about a given problem that will make it inherently better to learn from. It's probably a good idea to stick to a domain which you can easily design and model against, to remove that aspect from the challenge. You might look at doing something "more" than just data access operations; perhaps something involving graphing or other processing of the data which will give you an opportunity to learn some other API.
Your suggestions (expenses management, scheduler) seem reasonably good to me.

If you want to try all those "fancy concepts", better make a project that does not reflect at all anything you might do at work. E.g. write a game. If you create a small CRUD application but somehow manage to use inheritance, generics, delegates etc., chances are your program is much more complex than it should. Next time you do something similar at work, you might be tempted to do it the same way. Which would be a real bad idea. (KISS principle)

Thanks for all the answers, with your inspiration I found theme for my project :-)
It is an IS for a Brothel. We keep a list of our Clients, Hookers, Rooms, Available Services, Job histories, Prices,...
Now I created all tables in SQL (with primary, foreign keys and indexes), what is next step? Should I for every table in SQL create it's own class in C# and then add methods to it? And then continue building my Program from this base? Or should I use another approach...?
Thanks

Go for some basic CRUD app - Video Management System, Student Registration System, Pet Store Inventory System, etc...

You could always look at an open-source project that uses C#... Usually, they have a lot of the different concepts that you'd like to look into...
-JFV

You could write an engine that supports adventure-style games - nothing too fancy, but I find that it makes a good beginner project as you can end up working with lots of OO. You could also make a basic media player, although I can't see that being quite so good for getting the fundamentals of the language down. You could even get the XNA Framework and try to write a simple game!

Serializing vs Database

I believe that the best way to save your application state is to a traditional relational database which most of the time its table structure is pretty much represent the data model of our system + meta data.
However other guys in my team think that today it's best to simply serialize the entire object graph to a binary or XML file.
No need to say (but I'll still say it) that World War 3 is going between us and I would like to hear your opinion about this issue.
Personally I hate serialization because:
The data saved is adhered only to your development platform (C# in my case). No other platforms like Java or C++ can use this data.
Entire object graph (including all the inheritance chain) is saved and not only the data we need.
Changing the data model might cause severe backward compatibility issues when trying to load old states.
Sharing parts of the data between applications is problematic.
I would like to hear your opinion about that.

You didn't say what kind of data it is -- much depends on your performance, simultaneity, installation, security, and availability/centralization requirements.
If this data is very large (e.g. many instances of the objects in question), a database can help performance via its indexing capabilities. Otherwise it probably hurts performance, or is indistinguishable.
If your app is being run by multiple users simultaneously, and they may want to write this data, a database helps because you can rely on transactions to ensure data integrity. With file-based persistence you have to handle that yourself. If the data is single-user or single-instance, a database is very likely overkill.
If your app has its own soup-to-nuts installation, using a database places an additional burden on the user, who must set up and maintain (apply patches etc.) the database server. If the database can be guaranteed to be available and is handled by someone else, this is less of an issue.
What are the security requirements for the data? If the data is centralized, with multiple users (either simultaneous or sequential), you may need to manage security and permissions on the data. Without seeing the data it's hard to say whether it would be easier to manage with file-based persistence or a database.
If the data is local-only, many of the above questions about the data have answers pointing toward file-based persistence. If you need centralized access, the answers generally point toward a database.
My guess is that you probably don't need a database, based solely on the fact that you're asking about it mainly from a programming-convenience perspective and not a data-requirements perspective. Serialization, especially in .NET, is highly customizable and can be easily tailored to persist only the essential pieces you need. There are well-known best practices for versioning this data as well, so I'm not sure there's an advantage on the database side from that perspective.
About cross-platform concerns: If you do not know for certain that cross-platform functionality will be required in the future, do not build for it now. It's almost certainly easier overall to solve that problem when the time comes (migration etc.) than to constrain your development now. More often than not, YAGNI.
About sharing data between parts of the application: That should be architected into the application itself, e.g. into the classes that access the data. Don't overload the persistence mechanism to also be a data conduit between parts of the application; if you overload it that way, you're turning the persisted state into a cross-object contract instead of properly treating it as an extension of the private state of the object.

It depends on what you want to serialize of course. In some cases serialization is ridicilously easy.
(I once wrote kind of a timeline program in Java,
where you could draw en drag around and resize objects. If you were ready you could save it in file (like myTimeline.til). On that momenet hundreds of objects where saved, their position on the canvas, their size, their colors, their innertexts, their special effects,...
You could than ofcourse open myTimeLine.til and work further.
All this only asked a few lines of code. (just made all classes and their dependencies
serializable) and my coding time took less than 5 minutes, I was astonished myself! (it was the first time I used serialization ever)
Working on a timeline you could also 'saveAs' for different versions and the 'til' files where very easy to backup and mail.
I think in my particular case it would be a bit idiot to use databases. But that's of course for document-like structures only, like Word to name one.)
My point thus first : there are certainly several scenarios in which databases wouldn't be the best solution. Serialization was not invented by developers just because they were bored.
Not true if you use XMLserialization or SOAP
Not quite relevant anymore
Only if you are not carefull, plenty of 'best practices' for that.
Only if you want it to be problematic, see 1
Of course serialization has besides the speed of implementation other important advantages like not needing a database at all in some cases!

See this Stackoverflow posting for a commentary on the applicability of XML vs. the applicability of a database management system. It discusses an issue that's quite similar to the subject of the debate in your team.

You have some good points. I pretty much agree with you, but I'll play the devil's advocate.
Well, you could always write a converter in C# to extract the data later if needed.
That's a weak point, because disk space is cheap and the amount of extra bytes we'll use costs far less than the time we'll waste trying to get this all to work your way.
That's the way of the world. Burn the bridges and require upgrades. Convert the data, or make a tool to do that, and then no longer support the old version's way of doing it.
Not if the C# program hands off the data to the other applications. Other applications should not be accessing the data that belongs to this application directly, should they?

For transfer and offline storage, serialization is fine; but for active use, some kind of database is far preferable.
Typically (as you say), without a database, you need to deserialize the entire stream to perform any query, which makes it hard to scale. Add the inherent issues with threading etc, and you're asking for pain.
Some of your other pain points about serialization aren't all true - as long as you pick wisely. Obviously, BinaryFormatter is a bad choice for portability and versioning, but "protocol buffers" (Google's serialization format) has versions for Java, C++, C#, and a lot of others, and is designed to be version tolerant.

Just make sure you have a component that handles saving/loading state with a clean interface to the rest of your application. Then whatever choice you make for persistence can easily be revisited later.
Serializing an object graph to a file might be a good quick and dirty initial solution that is very quick to implement.
But if you start to run into issues that make a database a better choice you can plug in a new version with little or no impact on the rest of the application.

Yes propably true. The downside is that you must retrieve the whole object which is like retrieving all rows from a table. And if it's big it will be a downside. But if it ain't so big and with my hobbyprojects they are not, so maybe they should be a perfect match?