as you may or may not know, we are looking for a senior unix system administrator. i’m involved in the interview committee, which is kind of interesting. i haven’t been involved with hiring since m. and i left the JFI and hired our replacements, and before that, since i hired a summer intern at fastweb.

i do enjoy sitting down and brainstorming interview questions. it’s kind of fun to exercise your brain to see what you can come up with, not just for the quibbly technical details but also coming up with questions that present some sort of gauge of the respondant’s technical skills — i.e., not just “yes” or “no,” but giving them something where they have a chance to demonstrate their comfort level with something. as an example (and a freebie for anyone reading this who might happen to interview with me), i often like to ask people to describe some of the differences between berkeley style and system V style UNIX — you can say something as basic as “csh vs. bourne shell” or “the options to ps,” or you can get just as complex as you like, and whatever your answer is, it’s going to tell me about what you’ve had experience running up against.

but this is not a blog entry wherein i tell you how to ace all of sabrina’s interview questions! although i do have a list of some interview questions that people suggested on the sage-members list ages ago — mostly just because i stashed them there against the next time i would be interviewing candidates. and maybe i’ll even update it someday, once this round of hiring is done, with the new questions i’ve been using lately. but no, today’s entry is a few tips inspired by the resumes i’ve looked at and the people i’ve talked to. i may add more thoughts as the interview process slogs on. hope they help someone.

  1. applying:
    • be realistic. if you have never run any sun equipment, maybe applying for a senior unix system administrator in an environment consisting of over 70% sun gear is a waste of your and our time.
    • on the same note, if you cannot even tell me whether your usual login shell is a sh-alike or csh-alike, you’re not right for a senior position. this is like not knowing whether your car uses gasoline or diesel — it’s fine if you’re not the only driver and someone else can help you when you get to the gas station, but if you’re on your own you’re going to be screwed.
  2. your resume:
    • SPELLCHECK IT, FOR GOD’S SAKE! if you say you worked in “Los Angles, CA,” you can be pretty sure i’m going to be impressed unfavorably. especially if this is the sort of resume that was copied and pasted from your format onto the recruiter’s letterhead, which means NOBODY caught that stupid mistake.
    • three pages AT MOST. one is great, assuming you can actually convey useful information in that amount of space. two is good. three is approaching “you need an editor” territory. four or more is unreasonable and i’m not going to read it.
    • if you have half a page of certifications, it’s time to summarize: turn that twenty-line bullet point list into a one-liner, such as “Certifications: 12 relevant Microsoft system and application certifications, 6 Sun hardware and system certifications, and 2 RedHat Enterprise certifications, all current as of 6/2005.” boom! that’s what i care about: what areas you were trained in, and whether or not they’re recent. i don’t actually care at this point that you took both Solaris Administration I and II.
    • please, please, please give me a list of what tools and applications you’re familiar with. saying in your description of a former posting that you were “responsible for installing, updating, and running common open source utilities” means less than nothing to me. are we talking emacs or sendmail, here? give me a nice four-line section that says which operating systems and versions, which hardware architectures, which tools you are most comfortable with or most commonly use, and what languages you use.
  3. your interview:
    • if you come in and you are willing to honestly answer “i don’t know” with good humor when we ask you hard questions, that’s okay.
    • … unless you answer “i don’t know” to everything.
    • … and you decline to guess when we ask you to throw something out there.
    • you’re going to be interviewed by a group of techheads, and we’re going to be scattershot with our questions — each person will bounce around their individual priorities, and we’ll ask you some really hard and some really easy questions. we don’t expect you to ace everything. we expect you to try, though.
    • if i ask you something like “cubs or sox,” or “vi or emacs,” that is a question designed to give you a minute to decompress. relax and enjoy answering a question nobody’s grading you on.
    • don’t expect that unix is all you’re going to have to know:
      • i’m going to ask you networking things. i expect someone with six years of unix to understand the difference between classful and CIDR networking, if only in the context that you know you have to update your netmasks map.
      • likewise, if you claim you have experience running a datacenter, i’m going to ask you about BTUs and power.
  4. everything else:
    • yes, of course i’m totally gonna google you.
    • i probably do not, however, have the CFT necessary to stalk your web page through the ages using the Internet Wayback Machine. do with that knowledge what thou shalt.
    • if you answer my questions by looking at my male counterparts in the room, as though they asked the question, and won’t look at me — just so you know, (a) yes, i will notice; and (b), yes, you’ll lose credibility.