Interviewing for a PL/SQL developer position ultimately will turn towards talking about database structures and objects. This article goes beyond the basic table and index questions that you might expect and offers a tip or two designed to impress the interviewer.
Interviewing for a PL/SQL developer position ultimately will turn towards
talking about database structures and objects. But most of us will begin to
fall asleep if we have to answer some of the more basic questions about what a
table is, what a column is, what an index is, etc. Moreover, I don’t want to
bore you with having to read through the more basic questions and answers. Instead,
I thought it would be much more beneficial if I took from my experiences as a
DBA / Developer those pieces of information I actually used and thought could
help you spice up your studying for that next job interview.
Again, as you read these, especially if you’re getting ready for an
interview, remember that these questions are not hard and fast, many of them
beg for further investigation and many of them you should try within your own
sandbox if you’ve not ever encountered them before. Good luck. I hope these
questions get you started down the right path.
1. Define "Normal Form" and give brief descriptions of the
levels
Most shops want everyone to at least understand that there is some order in
the universe and that "Normal Form" is what controls this within our
databases. For most purposes this is correct so do brush up on what
"Normal Form" is by reviewing these very basic definitions; realizing
that there is more to each definition and there are higher levels then third
normal form but this will be plenty for most interviews.
Normal Form – is nothing more than a set of criteria within
relational database theory that aids in determining a table’s degree of
vulnerability against logical inconsistencies and anomalies.
First Normal Form – No repeating elements or groups of
elements
Second Normal Form – No partial dependencies on the primary
key
Third Normal Form – No dependencies on non-key attributes