The interview process can be quite stressful. Here is the first
part of a two part series on helping you answer those tough questions that you
might experience in your quest for an Oracle DBA position.
Ever
since I wrote the past article on the Oracle Technical Interview, I have been
bombarded with e-mails asking for help on getting through the interview
questions that I presented. Most of you I have answered, others I was reluctant
to post all of the answers so that you could begin your own quest for the
answers. Now, however, I have decided to post the answers knowing that we can
all benefit from them. If there are any questions here that you still need
clarification on, please e-mail me and I will do my best to further explain the
answer I have given. Please remember that as you go through the article, it is
not enough to know the answer to a particular question, you must try and put
yourself in an interview situation and experience answering the question for
yourself. Therefore, after you have gone through the questions and answers read
the question yourself and then answer it with your own words. As always, good
luck, and cheers.
Personal
This part of the interview question is not to be regarded as
insignificant. If the interviewer asks you these questions take it as a sign
that they are interested in you, your qualities, and how you interact with
people throughout the day. Take it as an opportunity to prove that you have
been around the block a few times, are willing to work with other people, and
enjoy the job you do. Many times people see DBA types as stuffy and pointed,
not willing to work with others, and only concerned with the database and its day-to-day
operational needs. Put aside the needs of the database and talk about how you
work with people and the different departments in the organization and are
concerned with providing them with top notch database services.
1.
What
DBA activities did you to do today?
Wow, this is a loaded question and almost begs for you to
answer it with "What DBA activities do you LIKE to do on a daily basis?."
And that is how I would answer this question. Again, do not get caught up in
the "typical" day-to-day operational issues of database
administration. Sure, you can talk about the index you rebuilt, the monitoring
of system and session waits that were occurring, or the space you added to a
data file, these are all good and great and you should convey that you
understand the day-to-day operational issues. What you should also throw into
this answer are the meetings that you attend to provide direction in the
database arena, the people that you meet and talk with daily to answer adhoc
questions about database use, the modeling of business needs within the
database, and the extra time you spend early in the morning or late at night to
get the job done. Just because the question stipulates "today" do not
take "today" to mean "today." Make sure you wrap up a few
good days into "today" and talk about them. This question also begs you
to ask the question of "What typical DBA activities are performed day to
day within X Corporation?"
2.
What is
your typical day like?
If you spend enough time on question 1, this question will
never be asked. It is really a continuation of question 1 to try and get you to
open up and talk about the type of things you like to do. Personally, I would
continue with the theme of question 1 if you are cut short or this question is asked
later in the interview process. Just note that this question is not all geared
toward the day-to-day operational issues you experience as a DBA. This question
also gives you the opportunity to see if they want to know about you as an
individual. Since the question did not stipulate "on the job" I would
throw in a few items like, I get up at 5:00am to get into work and get some quiet time to read up on new trends or
you help coach your son/daughter’s soccer team. Just test the waters to what is
acceptable. If the interviewer starts to pull you back to "job"
related issues, do not go to personal. Also, if you go to the office of the
interviewer please notice the surroundings, if there are pictures of his/her
family, it is probably a good idea to venture down the personal path. If there
is a fly-fishing picture on the wall, do not say you like deep-sea fishing. You
get the picture.
3.
What
other parts of your organization do you interact with and how?
Again, if you have exhausted question 1 and 2 you may
never get to this question. But if you have been apprehensive to opening up and
explaining yourself, take note that you may have an issue and the interviewer
might also be already getting tired of the interview process. If you get to
this question consider yourself in trouble. You really need to forget all your
hang-ups and start explaining what it is that you like to do as a DBA, and why
you want to work for this particular company. You are going to have to reel
this interviewer back into the interview process or you might not get to the
true technical question part of the interview.
4.
Do you
consider yourself a development DBA or a production DBA and why?
I take this as a trick question and explain it that way.
Never in my database carrier have I distinguished between "development"
and "production." Just ask your development staff or VP of
engineering how much time and money is lost if development systems are down.
Explain to the interviewer that both systems are equally important to the
operation of the company and both should be considered as production systems
because there are people relying on them and money is lost if either one of
them is down. Ok you may be saying, and I know you are, that we lose more money
if the production system is down. Ok, convey that to the interviewer and you won’t
get anyone to disagree with you unless your company sells software or there are
million dollar deals on the table that are expecting the next release of your
product or service.
5.
Are you
a nuts-n-bolts DBA or a tools-n-props DBA
This question begs for me to give definition around the
terms I basically group DBAs into. These are not good or bad groups but something
I like to think about when talking to DBAs. A nuts-n-bolts DBA is the type that
likes to figure out every little item about how the database works. He/she is a
DBA who typically hates a GUI environment and prefers the command line to
execute commands and accomplish tasks. A nuts-n-bolts DBA like to feel in
control of the database and only feels comfortable at the command line and vi
as an editor. The tools-n-props DBA is mostly the opposite of a nuts-n-bolts
DBA, they like the feel of a GUI, the ease at which things can be accomplished
without knowing much about the database. They want to get the job done with the
least amount of intervention from having to figure out what everything is doing
behind the scenes. Now the answer, I would explain myself as a combination of
the two. I, having been in this business for over 20 years, have grown up in a
command line era where the GUIs never seemed to work. There was high complexity
in systems and not much good documentation on how things worked. Thus, I had to
learn everything about most aspects of the database environment I was working
in and thus became a nuts-n-bolts DBA. I was a true command line and vi bigot.
Times have changed and the GUIs are very reliable, understand the environment
they are installed on, and can generally get the job done quicker for
individuals new to database administration. I too am slowly slipping over to
the dark side of GUI administration. If you find
yourself as a tools-n-props DBA, try to convey that you are aware of some tasks
that require you to be a nuts-n-bolts DBA.
