Main | The Danger of Knowledge »

A Tale of Two Interviews

As a contractor, the purpose behind your work is to put yourself out of a job - job done, you move on to the next project. It keeps life interesting, you have to stay on your toes, and you end up doing a few interviews.

Interviews, I have had all kinds, but this last week I had two that were polar opposites of each other, one where the interviewers did everything right, the second where they did everything wrong.

So I get a call on wednesday afternoon.

"I hear you're looking, because we're looking." said they, "keen to have a chat?". I was keen. "How about now?" I said, and in a flash I was in an office on the 3rd floor meeting with the two key players on a risk management project for one of South Africa's big four banks.

There are three things that make me nervous, one is public speaking, the second is appearing on television, and the third is dealing with strangers, so I appreciate it when people put me at ease, which is exactly what the person leading the interview did.

They started with some idle chit chat, and then began with where they had found my CV - via a project manager I had worked with previously.

First step, establish context, I now know why I am there.

Then the selling started. They needed to find somebody that fulfilled two key requirements:

- Someone who could do the job.

- Someone who wanted to do the job.

They kicked off with some brief questions, what kind of technologies had I worked on in the past, what kind of projects? could I do Java? No really, could I do Java?

I wasn't a Dot Net person masquerading in the other camp, they had been sent a couple of those.

Next, a description of their system, starting with an apology: "We're sorry, we haven't followed the full J2EE thing, we wanted to keep it simple".

Simple. I like simple. 'We kept it simple' means they understood the task at hand and hadn't wasted time on unnecessary complexity.

Their system allows traders to trade exotics, and handle the day to day trading and the risk analysis behind it. The more reliable the system, the more numbers they crunch for the buck, the more competitive the division is within financial markets.

Some key parts thrown in, they use RMI on their server, and they use an application developed for the Eclipse platform on the client.

Wow, an approach I have not seen before.

Their problem is their system was built in a bit of a hurry, they needed to bring the system under control, clean it up, relook at security and encryption, and make it faster, and they needed someone with experience to add to their existing already experienced team. Was I keen?

Looks good so far.

What then followed was a long chat about distributed computing, what had they tried, what approaches others in the industry have tried, what could work in their case.

Throughout the interview the two people conducting it showed confidence they knew what they were doing, something not entirely widespread within large organisations, and they showed that it was clear this was a job they needed to get done properly. They weren't there to waste my time, and didn't want to hire someone who was going to waste theirs. They had done a thorough vetting of me by the time they had finished.

"The director has a large wallet" they said.

They were spending their money on people.

Was I interested? I was. But I had an interview the next morning, could I give an answer after then? Sure no problem. "Don't sign anything" they said.

So, the next morning at 8am I found myself at an interview for a software company doing systems for financial markets. I had been there some months before to do an "exam" of sorts, a written test to work out if I knew my Java from my coffee. I type sixty plus words a minute, but was forced to use a pen, something I haven't done for years. The "hour test" took two and a half, and I left with an aching wrist. Their test was some standard stuff, with a focus more on theoretical computer science than engineering and system delivery, but they included some probing questions.

Hmmm. Ok. Don't seem too in tune with the people they hire, don't know anybody in this business who can still use a pen.

But regardless, there I was, at 8am, ready for an interview. Some helpful people at reception tried to find the people I was there to see, none of whom were there. I loitered for 20 minutes before two people finally arrived and said "this way". We sat down in a meeting room, an interviewer and their manager, with a pile of paper, my CV, and what looked like that exam from way back when.

Clearly I was here to be tested, I had had an unfriendly reception and that made me nervous. But no worries.

The interviewer began with the major companies I have worked with, started ten years ago with VWV Interactive. "What did you build for them?". Given time, more coffee, and a less nervous environment, I could probably reminisce for hours about the country's first auction site we built for SAA, Nando's 98, built for Nando's, or the Y Files, an online game built for newsagent CNA. I started by thinking back and saying "ooh gosh", and mentioning the auction system, but I was cut off, we were moving onto the next one on the list, apparently that was all I did back then.

The next item on my CV is a useful little litmus test as to whether the interviewer knows software engineering. Since 1999, I have been associated with The Apache Software Foundation, a not for profit organisation that offers a legal umbrella for the development of projects like the httpd web server, and have been a member of the Foundation since 2002. The acceptance of the use of free software by the business community has been a key part of the politics of software engineering over the past decade, and the ASF has been at the forefront of this issue. Today, business trusts Apache, and its projects are widely used, even though developed by volunteers, and overseen by unpaid members. This makes the question "So how long have you worked for the Apache Software Foundation" ridiculous. The ASF doesn't employ its members.

The interviewer asked anyway, and giving them the benefit of the doubt, I asked them to confirm whether they were familiar with the foundation. "Of course" they said curtly.

Not.

The employment history angle wasn't going well, so they opted for the curve ball. "Don't you think that not doing maintenance meant you lost the opportunity to learn?".

I learn for a living, and own a research company, what a silly question.

I said "no".

Ok, it was time for a practical test. They would give me a scenario, I was to solve it. The problem was a pretty straightforward one, the delivery of a continuous rates feed via HTTP for 5000 users. When a client says "5000 users" what they really mean is "we want to begin with 5000 users and scale up from there". Another classic case for a distributed system, that scales up as customers scale up. You start with a cluster of one machine, nice and cheap, and the new customers pay for new capacity, which you don't need to shell out for at the beginning. A bit of careful design makes sure that each additional user is as cheap as possible, but other than that none of this is rocket science.

But the interviewer already had their own ideas, and weren't interested in what I had to suggest. They were convinced the task meant very high system load, and the large number of threads was a showstopper. They switched into lecture mode, and started laying out their plans to write a custom webserver, based on an event driven model, that ran on one box. It was quite clear that the interviewer's design was correct, and mine was wrong. "The key issues here are performance, and latency, don't you agree?" they asked, reading from the textbook. "Er, no." I answered, "It's a lot more involved than that". Having been involved in building a real webserver, I could see they were getting into uncertain territory, something clients are seldom happy to pay for. They weren't impressed at being disagreed with, time to change strategy.

When you need to catch someone out in an interview, the classic fallback is the old "make up some new computing term on the spot" trick. I remember being asked at an interview "what I did think of OT?"

Occupational Therapy? I don't see what this has to do with anything, can you elaborate?

They meant "object technology", what everyone else calls "OO".

Today's question was "how well do you know your databases? What is an asset transaction?".

Um... to be honest, I don't know, tell me.

And I got the definition for a "transaction". Um... ok, why didn't you just call it what it was? I checked on Google afterwards, and could find no mention of a computing term "asset transaction", only lots of references to bank transactions involving assets. Restricting the search to "database asset transaction" found nothing relevant either. Cheap trick.

In hindsight, what had happened in the interview was that the interviewer's view of computing was that each question had just one correct answer. The "what if" analysis that is so key to the engineering approach had no place in this organisation - what the architect said was final, and my disagreement with their design approach had no place within their organisation. The problem with this attitude is that the architects are like glory boys on a sports team. You've seen the people who won't pass the ball so they can score themselves, when everyone else can see the defender bearing down on them? In the world of business, clients want solutions to problems, not excuses as to why the solution the architect dreamt up failed. And this means that a successful software team needs people who are sharp enough to come up with a design, but flexible enough to bury their ego, and modify their design to solve issues raised by others.

It was clear at this point that their organisation needed no people upsetting the apple cart, and I was not suited at all to their culture. That meant the first interview won.

I called the bank up and said "if you need me, I'm in".

I start monday.

TrackBack

TrackBack URL for this entry:
https://www.pier29.net/cgi-bin/MT-3.2-en_US/mt-tb.cgi/948

Comments

Fun reading. I've typically been on the interviewer side, but think all the points are equally relevant. I've generally found that having a "good chat" about technology achieves several things: breaking the ice, learning about the other persons skills and interest, and giving that person the opportunity to sell themselves by also having some control over the direction of the discussion. I've seldom learnt something from the CV and any formalized tests that I did not learn in the informal interview, and I've always learnt something in the interview that was not possible to learn from the CV or testing.

I once interviewed a person who knew nothing about the technology we were using. But the interview convinced me the person would pick it up in no time. I gave him a yes, and he quickly became a key part of the team. A test doesn't show you a person's mind, or how keen they are to learn. It only shows you what particular situations they've dealt with, and were able to commit to long term memory before carrying on with the next task.

I think I wrote that same test Myn, very recently. I pitched up, and was escourted by the receptionist to a room with a pen and a test. That's it. No hello's from staff, not a shake of the hand, nothing. I didn't see a single other employee. I thought that was quite rude. My test was all about C++. It seems they have a large set of pre-defined sections that they assemble into a test for each applicant. Mostly theoretical stuff as well, it didn't have much to do with reality. (not MY reality, at least).

I can't really code on paper anymore, I used to, when I was in varsity, The test had much more to do with how long ago I had read my varsity C++ textbook, than how much I had worked on real systems. It seemed very geared toward freshly-graduated material. How well I could parrot stuff I had long-since forgotten about.

Question: In every interview I've been, I've been questioned and prodded and poked about design patterns, somewhat like it was CRITICAL to me being hired. and how I couldn't possibly cope without them. And after entering the workplace, the whole concept evaporated almost instantly. I have used design patterns in my work, yes. But I've never heard them even mentioned in any work environment, or seen anyone else reaching for the book/net. Is it just me?

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)