January 11, 2018 at 12:02 am
Comments posted to this topic are about the item Job Interviews: What is Normalization?
January 11, 2018 at 3:21 am
The problem with anything but a fairly superficial description is, that in my experience, it's highly unlikely that the interviewer actually knows anything about normalization.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
January 11, 2018 at 6:14 am
I normally take the same approach you mentioned Steve. I also add in the definition of denormalization to show I know the difference between the two.
Small typo in the article, "Do you there are various forms of normalization?" Think there should be a "know" between "you" and "there".
January 11, 2018 at 8:23 am
I would give the very basic answer that it's how much data duplication exists(noun) or the practice of managing data elements to balance performance/data duplication/ease of use(verb). I couldn't give you any academic definition of any of the normal forms, I learned those just long enough to regurgitate them in college and promptly never had to care about the exact meaning of them again.
January 11, 2018 at 8:35 am
Normalization, and data modeling in general, are good questions for intermediate level and higher database developers, because it's hard for a candidate to talk about without having actually having hands on experience. Again, open ended "explain to me" type of questions are better than questions that require a dictionary one sentence answer for which the candidate could have read up on the night before. Instead of asking "What is normalization?", instead say "Explain why normalization important?". Instead of asking "What is a clustered index?", instead say: "Tell me the advantages a clustered index has over a heap, or a non-clustered table?". I've found that the smartest folks, those who have been around the block a few times, actually enjoy the opportunity to explain things from the perspective of their past experience. Not only that, but those of us in high level IT positions need to explain concepts on a daily basis, it's just part of the job. When asked to explain something, frustration and blank stares on the part of the candidate suggests to me gaps in knowledge or at least a problematic personality.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 11, 2018 at 10:03 am
xsevensinzx - Thursday, January 11, 2018 6:14 AMI normally take the same approach you mentioned Steve. I also add in the definition of denormalization to show I know the difference between the two.Small typo in the article, "Do you there are various forms of normalization?" Think there should be a "know" between "you" and "there".
Thanks, fixed
January 11, 2018 at 3:13 pm
I always like when interviewers ask this kind of question. It's a bit open ended so you have room to explain things and go in depth. Some basic white-boarding designing a basic schema is a useful exercise to gauge whether someone knows how to design tables or not.
January 11, 2018 at 4:48 pm
I like the open-ended questions as well. My last interview for my current employer was interesting. He asked me 3 questions but I answered 10 questions. He asked number 1, my answer and explanation answered 1,2,3,4. He asked number 5, my answer and explanation covered 5,6,7. He asked number 8, and yes my answer covered 8,9,10. He was done in less than 15 minutes. And the rest is history as I am still work here.
January 11, 2018 at 7:27 pm
I've worked with a lot of very good database people that were pre courses (started our careers in the early 80's) so all self taught. They would definitely have some troubles explaining normalization in academic terms and would only use experiences. One of them had worked with Oracle from v4.0 to v8.0 and could not tell you what third normal form was yet always designed and built systems that worked and met normalization rules. He failed an interview because he could not name and academically explain 1st through 5th normal form. Yet he was the go to person for any of our DB designs as his systems always worked, worked fast and had no, I repeat no, data issues.
So I got him to read https://www.amazon.com/Manga-Guide-Databases-Mana-Takahashi/dp/1593271905 and with the information in the book he can now academically explain them and is now a senior database architect with a large Australian bank. Still has no formal IT education not certificates.
Frustrating that some recruiters believe that formal education and the ability to regurgitate learning is more important than experience and proof of value.
January 12, 2018 at 1:35 am
dogramone - Thursday, January 11, 2018 7:27 PMFrustrating that some recruiters believe that formal education and the ability to regurgitate learning is more important than experience and proof of value.
Recruiters are recruiters - if I was trying to hire for a position in a discipline I knew nothing about I would probably default to qualifications as well.
Get someone with deep skills and has been round the block a few times into the interview who has both formal and good experience (if possible) and really have a general conversation on databases for an hour or two. Go light go heavy encourage discussion bring the conversation on and off topic see how the applicant responds see their flexibility see if they can react to what you are saying see if you can react to what they are saying.! I can see why you have these set questions as a starting point.
Its a relevant topic so a reasonable starting point and way better than "give an example of conflict in the workplace and how you dealt with it"
PS you are talking to someone who is after the fact trying to get some formal qualifications - I am enjoying the study and it is definitely more enjoyable to study something you have good experience in I am certain it is significantly improving my skill levels. If someone can learn everything without this great but for me I feel it is vastly increasing the speed of my learning in fact I don't think I would have ever learnt some of this stuff without formal study.
January 12, 2018 at 1:42 am
Thanks for the linked "tutorial" on database design. Nicely written, I've shared it with a couple of colleagues who are pretty new to this.
http://www.sqlservercentral.com/articles/Database+Design/72054/
January 12, 2018 at 2:06 am
As a side note what do people consider the best way of arranging tables for storing family relationships?
My journey was
Stage 1: Flat table (with total ignorance of the fact that a table can be related to itself)
Stage 2 : Junction Tables for children only
Stage 3: Key value relationship with tag for type of relationship
Final Stage : Back to Flat table with two fields for mother and father this time with knowledge that tables can be self referential
My eureka moment was that parent to child relationship can be looked at from the parent or from the child. Yes a parent can infinite children but a child can only have (ignoring messy breakthroughs in science) two parents - so we are dealing with a 1 to 2 relationship where the child is actually the parent record :). Put people in an individuals table enforce completion of parents fields and if you have full field completion you can in theory work out all relationships to all individuals with zero data duplication.
Its an interesting thing a one to many relationship is in itself actually a set of all the 1:n relationships and a 1:2 relationship can be considered as just two 1:1 relationships which hey isn't that the definition of a tuple.
Happy days!
SUGAR - need to revise some former systems!
January 12, 2018 at 2:40 am
Hmm, I have known the formal definitions and not too long ago, I think I know all the elements and I certainly know what to actually do, however I couldn't define the forms without looking them up. Not worth actually doing until an interview as I'd forget it anyway IMO!
January 12, 2018 at 9:15 am
Preppingfor an interview shouldn't be a cram session to learn more, but really a reviewof concepts you understand.
Exactly. At the moment I would have a little trouble keeping the normal forms straight, although I could give lots of examples. Normalization, ACID, transaction isolations are examples of things I review before an interview just to refresh the details.
January 12, 2018 at 9:52 am
call.copse - Friday, January 12, 2018 2:40 AMHmm, I have known the formal definitions and not too long ago, I think I know all the elements and I certainly know what to actually do, however I couldn't define the forms without looking them up. Not worth actually doing until an interview as I'd forget it anyway IMO!
Similar here. There is a lot of mundane stuff out there you just can't speak to in terms of correct and technical definitions. Doesn't mean you can't do it or understand it.
For example, I played guitar for 10 years, still can't read sheet music. I still don't hold the neck right compared to what a guitar teacher showed me. I still can't name all the notes, but I still play very complex music.
But there are certain things too, like point-in-time recovery. If you're working with a mission critical system, the time your wasting to look it up, some doctor may not be able to access critical information to save a patience life versus the senior DBA who actually knows his stuff is midway through the recovery while you are still on Google reading some SQLServerCentral.com post from 2014 that Jeff Moden made. :crazy:
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply