Procedures, Functions, and Packages: Acing that PL/SQL Developer Job Interview

Wednesday Sep 15th 2010 by James Koopmann

Being familiar with data types, data structures and code fragments (cursors, loops, exception blocks, etc.) all play a very important piece in understanding PL/SQL code. Yet, when push comes to shove it's how you put these pieces of code together that counts.

Understanding data structures, data types, and code fragments all play a very important piece in understanding PL/SQL code. James Koopman helps you put these code pieces together to better demonstrate your skill and foresight on that job interview.

Understanding data structures, data types, and code fragments (cursors, loops, exception blocks, etc.), as well as others, all play a very important piece in understanding PL/SQL code. However, when push comes to shove it is the putting together of these pieces that separate the men from the boys (or girls from the women). Putting code pieces together and forming an application/program is where skill and foresight come into play. Clearly, I hope that we can discern code that is well structured and maintainable from code that is nothing more than a hack job. This is where this set of interview questions come from, helping you to get started thinking about answering questions when asked about actual programming skills that are required when putting together procedures, functions, packages, triggers, and object types. As always, please just take this article as a jumping off place for you to investigate and practice for your next interview.

1. Would you say you use modularization as a best practice when producing PL/SQL code?

Of course, you will say yes as soon as you hear this question. Nevertheless, I, like many others, have seen way too much spaghetti code in my life that the question begs for an answer on why you do code this way, assuming you do. Just remind yourself that with modularized code we are able to separate by task/function so that we can improve things such as maintainability, reusability, readability, reliability, and actually enforce boundaries between key programming components. I don't know how many times, but it has been many, that I've separated components that were nothing more than a few lines of code. Often times it is these few lines of code that allow me to drastically simplify not only calls to those lines of code but also the components I'd broken them out from.

2. What is the difference between a procedure and a function?

This is one of those questions that, depending on your interview, you may get right or wrong depending on how you answer it. In the past, I've often stated that the difference between a procedure and a function is that a procedure is a program that performs one or more actions while a function's main purpose is to return a value. This is true but since a procedure can also return (interestingly with a RETURN clause) values, there is something else missing. The difference, that should get you some brownie points, is in the way procedures and functions are called. A procedure is called as an executable PL/SQL statement while a function is called like a PL/SQL expression. Consider the following and you will see the difference.

Procedure call

  raiseEmployeeSalary(7369, 200);

Function call

  employeeSalary := getEmployeeSalary(7369);

3. Explain the difference between IN and OUT parameters.

An IN parameter allows us to pass values into PL/SQL code while the OUT parameter allows us to pass values back out of PL/SQL code. Also, remember that a parameter can be specified as both IN and OUT with the IN OUT declaration.

4. What is module overloading and why might you use it?

Overloading modules is nothing more than a mechanism that allows the coder to reuse the same name for different programs that are within the same scope. Overloading is probably one of my favorite mechanisms to share and increase usability within code.

5. Describe read consistency

It has been my experience that, while this is an easy concept, many fall short of understanding it in practice. Read consistency is nothing more than Oracle's way of quarantining that the data / result set you request at a specific time will be available until the request is complete. This means that if I issue a SQL statement at 7:00am, and it takes 10 minutes to produce the result set, and someone were to alter the data at 7:05am, the data I get back will look like it did at 7:00am as if no one had modified it.

6. What is an autonomous transaction and how does it affect the commit process?

An autonomous transaction creates, when called from another transaction, an independent and separate transaction that can issue commits without affecting the calling transaction.

7. What are packages?

A package is nothing more than a way to consolidate/group/organize/etc., common elements of PL/SQL code into a single named entity. While packages do help improve things like portability and maintainability of code, packages can also help improve the performance of the code.

8. How might you hide/protect your source code if distributed to customers?

Oracle's wrap utility provides a good way of hiding PL/SQL source code; protecting it and making it difficult for others to view. You can either wrap source code with the wrap utility or use the DBMS_DDL subprograms.

9. Name two PL/SQL conditional control statements.

Very easily, the conditional statements are the IF and the CASE statements.

10. Name two loop control statements.

The loop control statements consist of LOOP, FOR LOOP, and WHILE LOOP.


These top questions come to mind when I think about procedures, packages, functions, and triggers. Clearly, there is much to know about these objects and you should dive into the structures and usability of them within your coding practices. As always, remember that these questions are not hard-n-fast questions. If I were the interviewer, I'd most definitely jump off into additional real-world scenarios and see if the interviewee had actually coded something. Sample code, if you can get it, is extremely important for this section of an interview. Providing clear samples on how you have pieced together code can be priceless. I'd even go so far as to suggest you create a PDF of your favorite code to send along with resumes. Worst-case scenario would be they never open the PDF, but, honestly, if I was performing the interview you'd get high marks; I'd open it, and I'd assume you were confident in what you are doing.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved