Unix Administrator Interview Questions

[Cara Tock]

I need to write a guide for interviewing a Unix Administrator. I came up with a list, but I would like some input on some questions. The questions should be for a Unix Administrator with 3-5 years experience.
Thanks

[Rick Garland]

Some quizzing about the various flavors of UN*X worked with. Command line vs GUI (SAM). Experience with backup/recoveries - what applications. Any disk array work? Scripting experience and preference.

[RAC_1 · Accepted solution]

I generally divide the questions into different areas. If the candidate is new this field (sat 2-3 yrs experience), my questions would relativley easy and would aim at getting the basic understanding of a candidate. For experienced sys admin, I would ask wuestions in details.

User, Group Management

1. How would you add a user?? For experienced admin, I would ask alternate ways to do it.
2. How many groups a user can belong to???

Disk/SAN/NAS management.
1. What are the steps involved in creating a volume?? About mirroring the root disk. How SAN is different from NAS. About stripped LVs.
2. What is JFS, what advantages it offers over HFS?? About VxVM.

Secuity Access and Control.
1. What precautions/methos will you follow to secure the system??
For experienced admin, I would access him a little further. User level security, at file level, user of third party products, use of ssh/tcp wrappers etc.

Kernel tuning, Performance monitoring and tuning.

1. Is a queue of four is Ok on a system with 6 cpus and questions like that???
How shmmax can be set for oracle. about dynamic buffer cache.
2. How would you check disk bottleneck?? How would you acertain the swap space use, dynamic buffer cache etc.
3. Steps in kernel re-config, boot into single user mode etc.

Print, Application, Patch Management
1. What is a patch database (IPD etc.)??
2. How would you roll back the patch??

Backups and Recovery
1. What products??
2. About Ignite??
3. Systems tools and their usage.

Network Administration
1. About having two ips on same subnet?
2. Calculation of subnet.
3. About ipfilter, adding routes, deleting it. USer of net stat. About ndd.

In order to access the psyche of the candidate.

Which is more powerful? The pen, the sword, or the prompt?

I depend more on how candidate re-acts. I prefer tolet him do the talking. Sometimes it happens that hey may not know correct optins, syntaxes, but it is important to know that he knos how to do this and that.

Anil

[RAC_1]

I completely forgot about adding few things.

About NIS, NIS+, DNS and NFS.
1. What advantages nfs 3 offers?? How??
2. The different records in DNS.

Hope this helps you.

[Geoff Wild]

I also like to have them talk about themselves...what they are good at - things they have trouble with, how they work under pressure - and can they provide an example.

IE - is someone puts on their Resume they are an expert with EMC - yet can't tell you anything about SRDF - well...they might be strecthing their skills :)

Rgds...Geoff

[A. Clay Stephenson]

I almost always start out with something like "How do I replace all instances of 'turnips' with 'collards' in a file using vi. If they know this, at the very least, I know that they can spell vi -- an absolutely essential requirement for any UNIX guy. I then expand the question to include batch processes and their weapon(s) of choice - sed, awk, shell, Perl, C, etc.

I also have them tell me about the various man sections. For example, what's the difference between section 2 and section 3?
I'm never too concerned about answers to specific questions but rather about their approach to getting those answers.

I always ask increasingly difficult technical questions until I hear "I don't know" (the desired answer) or until I hear BS. An employee (or interviewee) should never
be afraid to answer "I don't know".

[Prashant Zanwar_4]

Few questions can be like below:

1. tombstone vs core file generation.
2. using ioscan to attached device driver to the hardware path.
3. How do you know the patch level of the system
4. How to recover system using ignite.
5. steps replacing a failed drive on your system, using veritas or LVM.


Basic goal all employers will be to test your experience and offcourse your approach at various problems..

Hope this helps
Prashant

[H.Merijn Brand (procura]

What would be your approach if the system crashes badly (disk(s) all inaccessable), and there are apparently no backups made (ever).

This will probably show a great deal of how someone will take an inventory of what is/was/should be (re)installed on the system, including users, databases, software packages, patches, documentation, services, security and networking issues, interoperability with other systems, etc. etc.

A more serious question could be how to set up a complete new system from scratch, where he has to address most of these areas anyway, but he'd then be missing the pressure of phoning people asking "where is the database", and "when will I be able to see my files again".

Enjoy, Have FUN! H.Merijn

[Mark Greene_1]

Here's a few from a different perspective:

- do you prefer to work as part of a group or individually? And what percentage of your time would you feel comfortable working in the not prefered mode?

- what do you consider more important: risk management, or getting the job done?

- in general, would you describe yourself as being more long-term or more short-term focused?

- what was the most difficult work-related thing you've ever done, and what did you learn from it?


Keep in mind that some of these questions are deliberatly open-ended so you can see what a candidate is, and is not, willing to voluntarily talk about or disclose.

Hope this helps,
mark

[John Poff]

Hi,

There are always good technical questions to ask, and many of them depend on the environment you work in. For example, we never ask about NIS here, because we don't use it. You can probably cruise the forum here and come up with some great technical questions.

I agree with Mark in the last post. I like to ask some open ended questions for which there isn't a yes or no answer. Also, don't be afraid of silence. If you ask them a question and they are thinking or seem unsure, don't prompt them or say anything. You can actually get a bit of a feeling about how they think and act under a little stress, which is good to find out in the interview and not after you have hired them.

Here are a few of the open questions I like to ask:

1. What would your current/former boss say your strengths are, and why?

2. What would your current/former boss say your weaknesses are, and why?

3. Tell me about a time you were faced with a difficult technical problem and how you came up with a creative solution to the problem.

4. Have you ever been faced with a problem where you had to do something or come up with a solution that was outside company policy? (For example, looking for stories like, "I changed a production server without telling anybody" - which could be good or bad, depending on the situation).

5. Tell me about a time when you had to work with a fellow employee or supervisor who was difficult to get along with, and how you worked around that.

Most technical people with experience are smart. I'm more concerned with people that can learn things fast than with finding people that already know it all. Not that I have anything against the wizards, but the places I have worked generally couldn't afford them. :)


JP

[Steven E. Protter]

I would ask them what their security outlook and tools of choice were.

For HP-UX./Linux do they use Bastille?

What is /var/adm/inet.sec ? What does it do?

IDS/9000?

Secure Shell?

How to set default password policies?

In the post 9-11 world its no longer enough to administer the box, you have to make it safe.

SEP

[Timothy Czarnik]

In addition to the fine questions listed above, I would ask them if they were a ninja cuz, let's be honest, how cool would it be work with a ninja?

This may not apply in all situations.







P.S. Sorry, I'm just in one of those moods today :)

[Jeff_Traigle]

I hope busting out laughing is the appropriate response to the ninja question. If it is, can I work with you? :)

Seriously though... the questions you ask should really depend on your environment and what you need the person to do. There are some definite fine examples above. Of course, if you're not using SANs or NASs, it wouldn't make much sense to ask about them.

Regardledd what else you might like to ask them, I would definitely have to second SEP's comment about the security stuff. After seeing systems that have been administered for years by "experienced" people who were not properly trained or self-educated about UNIX security (even the basics that have been unchanged for decades), I would want to know that a candidate with a few years of experience knew the importance of security issues and knew what most, if not all, of those issues are.

I tend to dislike the blatantly HR type questions mentioned (both giving them and receiving them). I know they do serve a purpose, but I tend to like those types of characteristics to be evaluated from other aspects of the conversation during an interview. Of course, everyone has their own style so I don't really see one way or the other being the "right way" to do it.