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