The Job Approach: Round 3

As many of you know, I was approached by an intermediate-sized company which I would like to work for about taking a role as one of their lead UNIX administrators a couple of weeks ago. For Round 1, I prepared a few code samples, updated my resume, and wrote a lengthy cover letter pitching myself. For Round Two, I spoke with a fellow named Mike about an interview. Today, Round Three, was the technical interview.

I interviewed with two fellows named Chris and Matthew. Chris, apparently, is moving on to the Engineering department, and they need to replace him as well as attempt to backfill some head count of other UNIX admins who have moved into development within the company. A third fellow, Hung, was unable to make the interview as scheduled.

We chit-chatted about technical topics for about thirty minutes. Both guys were very amiable, and it was obvious within a few minutes that we all spoke the same “language” as far as computers were concerned. I expressed some concern that, despite hunting on the Internet, I had been unable to find any information regarding the back-end server configuration for their flagship product (though I had found some bits, pieces, and pictures regarding a competing product from 2005).

Well, it turns out there is good reason. Operating system, supporting software, and configuration is regarded as company proprietary information. All I can say is that I currently work in a data center with over 7,000 machines, and this company’s configuration dwarfs it by an order of magnitude. From their description as well, it’s a marvel of hands-off systems management and exploitation of favorable power rates and taxes in certain states. Virtually none of the servers are housed in their Southern California offices, but are located around the globe, remotely administered except for occasional trips out by admins.

There are a few weeks of travel involved, and of course the Southern California locale would require relocation. However, they treat their employees very much like a startup — despite the old-age of the company compared to most others in the industry — and have memorable company events, product launches, and so forth. They have very few admins for the huge number of customers and servers they support and, according to these fellows, no UNIX admin on the staff has ever left the company in its history.

Moral: Treat your employees well, and they will treat you well.

Anyway, from their descriptions it sounds superb compared to the somewhat ignor-ific treatment I routinely receive from UltraMegaCorp where I work now. The next step would be to be flown out to headquarters, spend a day with them in interviews and negotiations, and then fly home to either put in two weeks notice or else continue with my job as if nothing had happened. Of course, that’s the real question, isn’t it? Will it happen, or won’t it happen?

My general sense of the interview was that, although I know I bombed a few of the technical questions, I’d rate myself as a 7 out of 10. Not quite senior administrator material, but I could grow into the position. And the fact is, a lot boils down to what my competition is. I think I did very well on the code samples they requested (thanks to friends for reviewing, you know who you are!), and that I’m a fairly obvious fit personality-wise and experience-wise, but that there are some fundamentals I’m sketchy on.

Specific things I blew:

• “Uh, an inode is a data structure on a disk which has a start block and end block.” No, doofus, an inode is the data structure that points to the disk blocks which contain the data on the disk and also contains information about the ownership, access time, modification time, and other information about a file. When you do an “ls”, you’re seeing inode information.
• “Well, yes, I know that you *can* mount a filesystem which has a bad superblock because there are multiple copies of the superblock, but I can’t remember the specific argument to mount the filesystem.” Again, doofus mistake, it’s not an argument to “mount”, you have to use newfs (or mke2fs) to identify the superblock locations, then modify the superblock pointer using fsck. Not thinking well under pressure there.
• “The /etc/passwd file contains the username, GECOS, password hash (or, if the system uses shadow passwords, an x or !), userID and groupID.” Yes, genius, it also contains the user’s home directory location and shell.

Overall? Well, they are trying to fill several positions, and apparently have had trouble finding competent senior admins to do the job. I really only have to be better than whoever the next fellow is.

I’ve interviewed a lot of UNIX administrators. Most of us, sadly, are idiots and end up out of the business inside of a few years. Other ones get so pigeon-holed into a particular role that they stop learning new aspects of their job.

So it’s up in the air whether or not there’s going to be a “next step”… but at the very least, I realized that despite my experience there are certainly a few areas I need to work on.