Demonstrating - Backend DB skills

RicardoSmith

Not sure if this should be in work or here. I'm sure someone will move it if needs be. How would you demonstrate a knowledge of back end databases to a prospective employer or client. Other than having a laptop with you I don't see how you can do this. You can direct them to weblinks but then you might not always have net access would you.

Gavin

Show examples of your DB design skills, diagrams with
the various stages, first normal form, second etc.

maybe UML diagrams of the code you then created to interface with the DB.

UML is good for demonstrating code.

Gav

deadl0ck

Give examples of database designs you've done and why they were good.
Give example of queries and how you might optimize them.
Also talk about DB scalability and how you might load test the DB.
Stuff like that.

RicardoSmith

Excellent idea - Verb. Don't know UML, its one of those things I have on my "to do" list. But I have done topology diagrams for some of my apps. Though none of the ones I'd need to talk about. I can put some together though. I also have some Psuedo code written out, though I'd have to modify it a bit to show other people, so they can understand it.

deadl0ck - I hope I wouldn't need that kinda depth, since its not a dba role but a developer one. I did a MsSQL course but we didn't cover those kinda subjects since we had a dba on our team and the rest of us were only doing the front end in VB/ASP. Wish I had done the rest of it know though, not that I had a choice at the time.

Evil Phil

Talk about how you write stored procedures and views etc. give examples of when you'd use them and why you do so. Also talk about how to access these from code. You've mentioned VB/Asp; you need to demonstrate a working knowledge of ADO too.

RicardoSmith

I brought along some print outs of the schema and some screengrabs of the interfaces built. In the end they didn't go into that much detail anyway. All that preperation for nothing. Ah well.

Typedef

Say things that imply you know lots about SQL , waffle about, cursors and how inline SQL is faster, about how SQL is a language that is first and foremost about data retrieval and storage, as opposed to data manipulation, then tie in MySQL it's lack of stored procedures and contrast it to SQLServer and it's supporting of stored procedures.

This will make you look knowledgable about the intricies of SQL.
For doubleplus points, you could extoll the virtues of using a Unix of someform because the underlying OS offers performance, cost and security advantages to it's decrepit Windows supplicant.

And so on.

Talliesin

Originally posted by Typedef
This will make you look knowledgable about the intricies of SQL.
For doubleplus points, you could extoll the virtues of using a Unix of someform because the underlying OS offers performance, cost and security advantages to it's decrepit Windows supplicant.

Of course unless you can actually demonstrate concrete examples of this you are just repeating a truism rather than demonstrating any real knowledge.

bonkey

Id take a slightly differnt approach.

If I was asked to present something on it, Id open by mentioning that clearly this topic should cover such essentials as database design, normalisation, etc. etc. etc. and then explain that you're not going to discuss these because you dont consider them to be "in-depth" backend database knowledge, but rather the basic essentials (albeit ones which too many developers dont know fully).

Then look at more interesting stuff like optimisation - how to write maintainable and efficient SQL. Think about the uses of indexes, doreign keys, triggers (if the DB supports them), and other slightly more esoteric issues.

Every single applicant will mention that they can design a database normalised to whichever level you wish, and say why normalisation can be ignored when there is sufficient reason. Thats all DB101 stuff, and while you need to know it, and be able to discuss it at need, you should prepare some more "expert" topic material which you can present or lead the questioning towards...

You know....

"Yes, I prefer in-line SQL over the use of XYZ, and would prefer stored procedures if they were supported, but from a performance issue the gains here are secondary to far more important issues which are all too often overlooked, such as index-determination, query optimisation, etc. etc. "

Oh - another big one for me would be a developer who knows how to consider security implications in database design and implementation. Again - its bloody simple and obvious stuff for the most part, but the number of systems Ive had to work on over the years where the original designer though database security consisted of giving you a login and password.

I would also expect any employer giving an interview to ask about Views in a database, and your opinion on them. To answer this "well" (in my opinion) you need to know both the good and bad aspects....too many people only talk about the text-book benefits.

Hope that helps or gives you something to think about anyway.

jc

RicardoSmith

You've made me realise I need to buy and read a lot more books anyway : )

nahdoic

Originally posted by RicardoSmith
You've made me realise I need to buy and read a lot more books anyway : )

I think practise is more important than reading a lot more books. Create some database applications and then benchmark them, and then try to break them. And then try to fix them, you learn a lot that way. Or at least I did.

bonkey

Originally posted by Typedef
For doubleplus points, you could extoll the virtues of using a Unix of someform because the underlying OS offers performance, cost and security advantages to it's decrepit Windows supplicant.

Of course, if the emplyer or client you are talking to is a Windows-head, then this will not earn doubleplus points, but rather be more akin to aiming at your foot with a loaded elephant gun and pulling the trigger repeatedly

Religious advocacy (software/hardware evangilism, if you prefer)is one of the most dangerous things to ever get into a discussion on during a sales pitch, and I woul davoid it like the plague unless specifically asked about it.

Having said that, I would pitch that it is important that every project be individually assessed to determine the "best" database solution for it, within whatever flexibility is permntted by any corporate standards or policies which may affect the decision making process.

jc