Job interviews

I’m glad I’ve been for a few professional job interviews, because I think I’ve learnt a few things about myself, and taught myself a few things about interviews.

My first interview with the recruitment agency for Dimension Data didn’t go so well I thought. I was quite nervous and it was an unusual setup. I went to the offices of Dimension Data, into one of their conference rooms, and the interview was done with the recruiter via teleconference. So, I sat at a desk, in a room by myself, and talked to a person on a TV screen. I felt as though I didn’t answer her questions particularly well; my answers were pretty disjointed, some things I said were extremely circuitous and occasionally off-topic.

Though it turns out, whatever it was I said was good enough to get me a second interview. With the team leader/manager of the area I could be working in. This interview, about a week later, was much better. I was more confident. I felt as though I could relate to the guy better, whereas from the recruiter I was getting a serious over-corporate vibe that didn’t sit well with me (though I’m over that now I’ve been in regular contact with her). He asked me a lot of questions that were similar to the first interview, though went into more detail. He also asked me a lot of questions about why I liked networks and networking, what drove me to succeed and all those kind of questions.

I was told beforehand that there would be some kind of aptitude testing done in the interview, but it was just him and myself, and no such aptitude test was undertaken. Unless of course it was incorporated somehow into the questions he was asking me. So anyway: I answered all of the questions as best I could, some still a little indirectly (though if you’ve ever read this blog before, you know I can be quite circumspect in my writing), but overall I felt as though I had done better. And he told me so, too. At the end of the interview he said I had done well and it had been a good exchange. I think we probably talked about random non-interview stuff (company benefits etc) for about 10-15 minutes afterwards; which may’ve been a drain on his time somewhat, but I felt as though it proved that I was able to converse normally, and it also proved that he and I could connect on a semi-professional level, which is important for building a professional relationship with someone. Being able to base your work-related conversations and exchanges on a foundation of common ideals, goals, whatever, really bolsters the chances of success I find. If my boss is a person I can get along with outside of work, I get along with them so much better when discussing work-related material.

Yesterday I had another interview for another job at UQ. It was a very tech-heavy interview: the head Unix sysadmin, Unix sysadmin team lead, and a HR person were all present to ask me questions. The two Unix guys loaded up the technical problems and fired them round after round. I feel as though I could have answered many of them better; but, I also answered many quite well.

Typically where I fell down was the interchange between their formal language and descriptions and my own self-taught (aka: incomplete) descriptions. They asked me about the function of a TCP wrapper, and I outright said I had no idea. Which was wrong, because then they prompted me with the keywords /etc/hosts.allow and /etc/hosts.deny — I use these files quite regularly and completely understand their purpose, but had never heard or seen them called TCP wrappers previously. Of course, now that I think about it, that’s what they are. But I’ve never made the connection from function to name before, and it provided me with a nice stumbling block.

A few of the questions I should have simply known. They asked me what two files are involved in the login process of a user. I told them the shadow file and one other, which I could not for the life of me remember the name of. Anyone familiar with even the basics of *nix knows what I’m talking about: the passwd file. But at the time, I simply couldn’t recall. I even made the comment to them that “that was like Linux 101, I should have remembered that.” to which they seemed a tiny bit sceptical.

However, they asked me a question about what needs to be looked after when setting up a single system on multiple networks: I surprised them by asking if it had one or two network cards, and they said to “choose your poison” — so I said, I’ll take a system with two network cards. They said, OK, what’s the first thing you need to do to ensure it works properly? And I told them: make sure that when the system starts up, the cards are assigned the same device name reliably using custom udev rules. They were taken aback, and impressed, by the level at which I had started to check things. I’m thorough, baby.

Of course, later in the scenario I once again stumbled by not remembering the key words “default gateway”, though I did say the magic word “VLAN ID” when they asked me about that. Even though I have no idea how to setup VLANs using *nix software. Their questions were both exploring my knowledge of the working of *nix software systems and also my problem-solving processes. I feel as though, with the technical stuff at least, I could have done much better. I missed out on many simple things I should have simply known immediately.

However, the I felt like the questions from the HR person were almost trick questions. I’m guessing they expected to interview a lot of anti-social nerd types with no ability to talk to humans, because the questions asked were so basic. For example, I was asked what I would do in the following scenario: the entire email system has gone down, but my immediate boss wants me to install a new widget on his PC. Which is more important and which do I attend to first? Haha, I answered, it depends on the temperment of the boss! But seriously, we all know which goes first, though what they were after is what I would say to the boss: I told them, I’d explain to him that the entire email system was down, his included, and that I would get back to installing his doodad as quickly as possible. Just not right now.

They also asked me what the most important aspect of customer service is, and I explained that in the context of IT support, it is to listen like you have never listened before. And also to make the person you are helping feel like their issue is the centre of your universe and you will stop at nothing to solve it. Because whether it’s a case of them accidentally hiding their start menu, or, they’ve accidentally deleted the project they had been working on for the last 6 months, to them, it’s a fucking-big-issue-that-has-to-get-solved-right-now!

I think I did rather well overall in the interview. The two Unix guys were receptive to the typical IT crowd jokes and jibes about users and at Microsoft, so we had a few laughs and got along quite well. I am afraid though that somebody with better technical aptitude may snag the position, because they were really really into that, for obvious reasons.

Anyway, if you’re still reading at this point, congratulations! And thanks.