How to pass a programming interview with rusty skills?

March 15, 2010 1:31 PM

How to pass a programming interview with rusty skills?

I've changed careers to research and haven't hacked in over a year and a half. I'm applying for everything that appears to match my skillset. However, the only job interviews I'm getting are for hacking-intensive posts, even though it's the less technical ones I'd expect to be getting interviews for. How can I get through these interviews alive?

I'll explain in reverse chronological order. My research interest is in a niche technology which is named in my most recent job title. However, the nature of the project meant I spent all my time on end-product evaluation and administration, and none at all on software development. My friends and ex-colleagues told me to be very confident in my job search, because I have a great publication record and tons of achievements over a short time, and by golly they think I'm just great. That's nice to hear.

But the discrepancy between my job title and the actual work I did has been remarked on by every interviewer since then. I do have mastery of the technology itself, but the latest tools and related technologies I have no experience in and the concepts are fairly fuzzy.

It's worse. When I left my last permanent programming job in industry, before becoming a researcher, the main technology I'd been using was Microsoft Access with some Oracle. I had grown to loathe Access dearly (okay, handy for some things, but boring and doesn't pay well) and wanted to go back to working in Java or at least .NET. However I'd never used .NET commercially and had not used Java commercially in several years.

I had recently finished a Master's degree from a world-class university that was developed in partnership with a major tech company to meet the practical needs of industry. I learned about 10 new skills, consolidating each one with a 100-hour homework assignment based on what seemed to me realistic representations of common business scenarios. I earned high grades on each one. But of course none of these skills was any help to me in finding work, because I hadn't used any of them commercially, and recruiters and peers alike were completely scornful of any skill picked up at university rather than in the "real world". Not only was the Master's degree no help in finding work, I actually found myself being shoehorned into interviews for graduate schemes or junior roles, despite 10 years' industry experience.

So all in all it was very difficult to get interviews. But when I did, I then of course had problems answering questions about technologies I was rusty and/or inexperienced in. I laboriously read up and made notes and drilled myself for each interview, and I got better and better at predicting and answering questions as I went along. But even if I got every question right, it still wouldn't be enough as I would be up against candidates who also got every question right and had lots of experience. And it can be very hard to get every question right in tech interviews, because some of them are based on trivia. I found myself being questioned on topics I expected to ace because I'd been working on them for years and years, only to have the interviewer ask about an aspect of the technology I hadn't used much, and have to say "I don't know". On two occasions I even blew it because the interviewer used an unfamiliar piece of jargon for something I'd used day in and day out for years (I've had a few people report similar experiences, so I know I'm not imagining it.) It's hard to anticipate trivia like unfamiliar jargon, so chalk that up to fate. What's harder is how to allocate my time: do I spend precious time on details of very familiar technology when I also need to be learning enough to be secure with the less familiar stuff?

But it gets worse still. If each interview were only on one or two major topics, I could be confident that if I just kept plugging away, hacking up stuff at home and reading comprehensive texts, I would eventually know enough about each one to have a good shot at the next interview.

But each job ad invariably specifies a stack of at least a dozen technologies. I have tried brushing up on those listed as "essential" but it always turns out that they ask detailed questions on the "desirable" ones too, which I may or may not be able to answer. I have tried getting a grasp of what I think are the salient features of each "desirable" or more granular technology, but the interviewer's idea of the salient features, and mine, may differ - and they could ask me ANYTHING. I've resorted to memorizing APIs beforehand because I know I might be questioned down to the syntax level, but that doesn't protect me from the kind of interview where I'm expected to write AND COMPILE code with Help disabled and no net access.

I did finally find work in industry. And then I went into research and I thought I'd put this kind of thing behind me.

Instead it actually seems to be worse. At a recent interview the ad listed just four technologies, and I was already familiar with all of them. Better still, my speciality was listed as one of the "desirables". I cracked my knuckles and set about brushing up on everything I possibly could on all the technologies I knew well. I read the papers produced by the department interviewing me until I had a thorough grasp of their activities. I crammed in as much domain knowledge as I possibly could.

I went in with a big smile on my face and was immediately asked about a related, but completely different technology not mentioned in the job ad and not within my experience. Ironically, I'd been reading up on that exact topic for an interview the month before - but from a different angle. I certainly didn't know the exact steps for implementing it, which was what they kept asking me. Asking me over and over again. I scraped up parts of the answer from what I remembered of my reading. But they didn't want parts of the answer. They wanted the answer, the whole answer, and nothing but the answer.

Then they asked me about ANOTHER technology stack - comprising about a dozen subtopics - that, again, was not mentioned in the job ad. The awful part was that some of these subtopics were mentioned on my CV - but only as context for a very short-term job I held two years ago. I was totally unprepared to answer these questions and wouldn't even have applied if they'd been listed on the ad.

The hat-trick was when they asked me the name of a process in *nix. I don't know *nix. I don't apply for jobs that require experience in *nix. Of course, the job ad didn't mention *nix.

And then they finally got around to the technologies they had mentioned in the ad, that I did know something about, and about which I was prepared to answer questions. By this time I was so paralytic with fear I flubbed those questions too even though I knew the answers full well.

In my horribly extensive experience, as I said, even getting every question right isn't enough. It takes at least 10 seemingly "perfect" interviews (i.e. I know I got every question right and I very often get excellent feedback but they picked someone with a better experience fit) for every one job offer.

The only problem is that I don't see how I'm going to get the 10 "perfect" interviews I need before I can get that one job offer. Last time I was jobhunting, I had interviews every week or two. In this market, I've been looking for FIVE MONTHS and had a grand total of TWO interviews.

I don't want to drop out of research when I was enjoying it and doing really well at it.

I am looking at shorter contracts in industry to keep me going. Or even longer contracts. Or anything really. But they're just as hard to get.

Changing job titles to something that leverages my related/softer skills but requires less programming is possible, but the trouble is my experience either is insufficient or is presumed inefficient by recruiters because I don't have those job titles already on my CV. For example, I've picked up a number of project management techniques along the way, but I've never been a project manager, am not qualified to be one, and indeed don't want to be one (I would if I had to, but). I've done small-scale administration for databases with <10 users, but I'm certainly not a DBA and would need large-scale enterprise experience as a DBA before I could consider applying to become one. I've led end-to-end development of systems from requirements through testing through release, but again only for <10 users. I have no accounting knowledge so can't become a business analyst. Etc, etc.

The only jobs I've been hired for over the last few years are ones where few or no technical questions have been asked, or else I was given the questions beforehand and told to prepare a presentation. Interviews of this kind are so rare I can't count on ever having another one.

So, I know that's a long ranty whiney exposition, but it leads me to my actual questions.

1. Given that I've now not done any hacking in at least a year and a half, how can I bring my technical knowledge up to the point where I have a reasonable chance of achieving a "perfect" interview?

2. In current market conditions, how can I get the 10-15 "perfect" interviews that experience tells me I need in order to get one job offer? Due to family commitments I can't relocate.

posted by anonymous to Work & Money (9 answers total)

I think you have a mistaken idea about what a perfect interview is. You don't need a perfect interview. You need a good enough interview. That's anything that gets you a good offer.

Interviewers are trying to take the measure of not just what you know, but how you solve problems, how you communicate, whether you're reliable, whether you'd be easy to work with, whether you'd complement the existing team. Also, you don't know whether your interviewer is a bozo and you flunked the minute you walked in with the wrong color socks. In short,

FACTUALLY CORRECT ANSWERS ARE NOT THE ONLY OR THE MOST IMPORTANT PART OF A GOOD INTERVIEW.

Every modern tech job has a ludicrous list of required skills, even for junior positions. No one they interview is really going to have fluency in all of them. Everyone learns the details of the particular job on the job. They're going to pick someone they think can do that.

I suspect your problem may lie elsewhere than the technical. You may be somehow coming across badly. What you want most is to portray yourself as quick to learn, good at solving problems in general, easy to work with, a good communicator, and relaxed about the things you don't know because you know how good you are at remedying that. Don't worry about missing a trivia question, and be comfortable with saying "I don't know."

Of course, it's a tough market and it's possible to be doing nothing wrong and still have a dozen interviews with no offers. I could be off base here. But your emphasis on correct answers over all raises a big red flag for me.
posted by Zed at 1:59 PM on March 15, 2010 [5 favorites]

I agree with Zed. It's not so much about the correct answer (it does help, but it's the final answer by any means), but more about how you get there. They want to know how you think, how you problem solve, if you can get along with the team, and if you're capable of doing the job. The technical specifics can be learned, or looked up. They kept asking you the same questions over and over because they want to see what you can deduce (perhaps given a hint or two), and see what kind of questions you ask in return -- basically, how your brain works. They will throw you a curve ball or two -- because the job will throw you curve balls. How are you going to handle it?

On the other hand, some technical interviews (and interviewers) are just duds. If getting the job or not is based on whether or not you actually know the name of some random unix process, you probably don't want the job anyway.

Another random note -- I really hope your technical explanations in the interviews are a lot more concise than this post... whoa. If you're frustrated by a lack of answers here, it's because this question is *really* long. Way too long.
posted by cgg at 2:13 PM on March 15, 2010

When I saw the title of your question, I was ready to recommend Programming Interviews Exposed.

Having read the substance of your question, I realize you're not asking for the usual "How do I pass programming interviews that have tricky algorithmic whiteboard questions?" but instead something more like the harder question, "How do I become familiar with a wide enough range of technologies to a depth great enough to be prepared for any hard technology-specific interview?" To this I have to echo the previous responses. You don't need the depth on specific technologies that are not on your resume. Eventually you'll get a "good enough" interview on the basis of your apparently-substantial skills and background that will get you in the door.

There is one exception though; you say *nix is not on your resume, you're not expecting or prepared to be interviewed on *nix, but in a lot of places a baseline familiarity with the family of OSes and APIs covered by this wildcard is pretty highly valued as an indicator of breadth and depth of general understanding. It might be worth it to you, with your already strong background elsewhere, to bone up on Unix so you're able to handle the basic set of questions on this subject you can expect at most interviews. It may be that this one hole is a dealbreaker at various places across our industry.
posted by doteatop at 2:55 PM on March 15, 2010

You're doing two things wrong:

1) You're treating the interview process as though it were the SAT or a final exam. As Zed and cgg note, the correct answer isn't necessarily the goal; they're looking for evidence of problem-solving ability. "I don't know" is a better answer than trying to fake it based on cramming the night before. Especially if you follow up the "I don't know" with "but here's how I'd find out."

(Some companies -- possibly including the one you described in detail above -- do seem to treat their interviews as trivia contests; those companies are generally not much worth working for.)

2) You're applying for the wrong jobs.

It's hard to tell from your description what you actually know how to do (which may be part of the problem right there.) It's even harder to tell what you actually want to do.

If you want to transition back into being a day-to-day coder, I'm sorry to say this but you need to stop pretending that "the latest tools and related technologies I have no experience in and the concepts are fairly fuzzy" constitutes "mastery of the technology."

If you have no work experience as a .NET or Java developer, and want to get a Java or .NET dev job, you are going to need to accept a more junior role than you're accustomed to, at least to start out. "10 years industry experience" is completely irrelevant if the job is hacking code, and you have ten years experience at not hacking that particular kind of code.

Either that or focus your efforts more on applying for managerial or administrative-level roles -- i.e. the stuff you actually know how to do. There are fewer of these, sure, so it'll be harder to find lots of interviews. But you don't want lots of interviews. You want one job.

In current market conditions, how can I get the 10-15 "perfect" interviews that experience tells me I need in order to get one job offer?

It's not a numbers game. You don't need "10-15 perfect interviews" - you need exactly one interview with a company that suits you, which has a role you're suited for. Finding that is the hard part. Given that, the interview should be easy.

It sounds like you're doing most of your looking through job boards or recruiters; I suspect you'll have much better luck working through those friends and ex-colleagues. They know who you are and what you can do, so issues like your misleading job titles will be less of a problem.
posted by ook at 3:50 PM on March 15, 2010 [1 favorite]

If you have no work experience as a .NET or Java developer, and want to get a Java or .NET dev job, you are going to need to accept a more junior role than you're accustomed to, at least to start out. "10 years industry experience" is completely irrelevant if the job is hacking code, and you have ten years experience at not hacking that particular kind of code.

This isn't necessarily true. I have twice been hired to write code as a senior dev in a language I had never touched (first C#, now Python).

However, the poster's problem is more severe --- he/she has not been writing code as their "main" job. That is tougher to get around, and I'll admit it's rare I see such a candidate get hired. Whereas simply being proficient in a different language has rarely been an issue at places where I've been involved with hiring (mostly Microsoft and Google). Many companies rightly assume that if you're awesome at language X, you can pick up language Y in a small amount of time (assuming some reasonable comparison --- Assembly to Java might be a big leap. Java to C# is a tiny step. etc.)

So, advice ---

Some companies _will_ expect specific technology expertise. These are either small companies (who dont feel they can spend _any_ time on you getting up to speed) or those with crappy HR/hiring policies (focus too much on buzzwords and not skills). The former you might be able to get around with a stellar interview, the latter are probably a lost cause. But not all companies are like these.

For the rest, what you need is to show you can code well in _some_ language. The only way I can think of to do that is to start coding right now in something fairly popular (maybe Java? depends on the industry). If they then ask you to solve a problem in a different language, ask if you can instead do it in the one you're comfortable with. Many large companies will be fine with this (and some smaller ones).

As an example, I answered all my interview questions for Google in C# -- which I probably don't need to tell you isn't actually used here anywhere.
posted by wildcrdj at 4:34 PM on March 15, 2010

I've run into similar problems... I don't have any good solutions that you aren't already working on. Maybe work on smoother ways of saying "I don't know"? E.g. "I haven't had much opportunity to use Unix, so how do you do that?" People like to talk, so inviting them to do so may make them like you better.

I've been on the other side of the desk, too, and I came to distrust the technical trivia interviews. It's often some too-clever guy who thinks he's found a way of weeding people out; but it doesn't really test programming skill. A good interviewer should either ask you to demonstrate your skills (by writing a short program) or ask in detail about work you've done. In an actual job when you need to know that trivia you Google it.
posted by zompist at 6:10 PM on March 15, 2010

1. Given that I've now not done any hacking in at least a year and a half, how can I bring my technical knowledge up to the point where I have a reasonable chance of achieving a "perfect" interview?


That caught my attention a bit. Well, try 3 years wandering around the globe and doing no work AT ALL and then jumping into programming after a month and a half all out reviewing and studying.

That's what I did and I work at a well known software company.

Just study AND practice like you did in school for the programming area you are interested in. Code up algorithms and pay your dues.

The single most important thing will be motivation. I lacked that for 3 years and now I'm back at it.

2. In current market conditions, how can I get the 10-15 "perfect" interviews that experience tells me I need in order to get one job offer? Due to family commitments I can't relocate.



The best online resource for interviews I found is www.careercup.com. Other than that go back to your textbooks.

Good luck.
posted by simpleton at 6:35 PM on March 15, 2010

Do you have friends who work in industry and do technical interviews at their companies? Practice sometimes makes perfect, though I recognize it's still possible to choke.

It sounds to me like a big problem is that you lack confidence that you can hack the hacking questions - interviewers can smell a lack of confidence and while some of them can see past it, some of them can't or will choose not to because they don't want to work with someone who's constantly looking for validation. The only way you get that confidence is by having some good interviews and feeling like you're in the swing of the process, and it's not very productive to use real interviews for that practice. So call in some favors and get some friends to fake-interview you - maybe ask them to ask the hardest questions they've ever been asked in interviews so they're not violating any NDAs about their company's list of questions. Yes, it's awkward to fake-interview a friend, but sometimes friends do awkward things for each other. Practicing will probably help you.

Sometimes, though, it's just luck. You are in a great mood that day for some unrelated reason and smilingly sail through every question like some glorious new god of code; you happen to get questions on topics that interest you particularly or that you've solved or even asked before (how great is that feeling in a technical interview when you get asked one of "your" questions? It's like finding $20 in your pocket or something); you really hit it off with the interviewer because you like the same kind of jokes or worked at the same company previously or have the same hobby, etc. You can try to make your own luck by studying hard and practicing, so you'll go in relaxed and feeling good about yourself, but ultimately a lot of this is out of your control, and that's something you've just got to accept. Interviewers try to pick the best person technically, but they're only human. Sometimes that just doesn't happen.

In a way, this can be freeing, because you can tell yourself truthfully that just because you didn't get this job doesn't mean you didn't deserve it or you couldn't do it well. I would love to believe that interviews always pick out the best person for the job, but sometimes that just isn't the case and the best person has a cold and decides to power through it, or just failed a test and thinks she is a moron and spends the whole day of interviews thinking "Of course I don't know the answer to this because I'm the kind of moron who fails her calculus final" before mumbling through half-assed solutions, or gets asked only questions about operating systems internals when she has never taken an operating systems class, and then some other person gets the job instead. Circumstances happen. All you can do is prepare as best you can, and think positive, and try to tip the scales in your favor.

Chin up, I know it isn't easy. Best of luck to you.
posted by little light-giver at 8:56 PM on March 15, 2010

Mod note: From the OP:

I just wanted to say thanks to everyone for such thoughtful replies. I paid attention to every word.

This morning I had a really great interview in which I was able either to answer every question or turn it around to what I did know. There weren't any trivia questions at all, so obviously, the non-trivia-style interviews that have gotten me jobs in the past weren't the never-to-be repeated, freak occurrences I feared they were.

Looking back, I think the thing that scared me into treating interviews like final exams was the number of times I got turned down with the explanation: "we really liked him, and we'd have hired him if we didn't urgently need someone who knows this exact technology stack inside-out", and the technology stack would of course be different at every interview.

I don't think I'll get the job because I know for a fact that another candidate has higher qualifications, which fit very specifically into this company's rather exotic area of the market. But I did pretty well. So I just have to accept that trivia questions aren't my forte and keep practising.

posted by jessamyn (staff) at 9:08 AM on April 6, 2010