A few weeks ago, I met an old friend for breakfast – he’s had his own company for a few years, building a web application, but has been considering going back to work full-time. Excited by the prospect of it, he still felt concerned about being able to pass a technical screen, so I gave him the advice you’ll see below. If you’re looking to return to the tech world – or are changing career paths – these tips will help to get you on the track to success.
The more you know, the more you understand what you don’t know
At first I thought this was typical imposter’s syndrome. My friend has nearly ten years of experience with programming and has been an entrepreneur of one sort or another for more than thirty. For the last five years, he’s been working on his own product, which is a fairly complex J2EE site. But, like a lot of good developers, he thinks that what he does isn’t as impressive as what others are doing. When you work on something for a long time, you become intimately familiar all of its flaws, and then when you see something new that someone else is doing, you only see the positives and begin to compare yourself.
Read @LouFranco’s #JobTips for passing a technical screen in #programming, via @AdeccoUSA: http://adec.co/LouFranco-tw | #JobSeeker
I told him he was definitely qualified for a programming job if he wanted one, but asked what was up with his project. It turns out that in the last year or so, he had been mainly working on the business side of his project, not the programming, which was largely finished. And, even the business side didn’t need his full-time attention. He wanted to find an agency that would allow him to take on some short-term contract work because he missed programming and had the available time.
Even good developers get rusty
Now I understood – he was rusty. This is a major problem in programmer assessment. As an interviewer, I know that it’s incredibly hard to tell the difference between someone who used to program and someone who isn’t qualified (yet). The former will quickly become productive once they are programming every day again, but the latter may or may not develop. There are good reasons to hire either, but many places that are looking for experienced programmers would probably prefer someone rusty that will remember old work rather than have to learn it anew.
Since I know this is a problem, I usually ask direct questions in a phone interview with applicants, including:
- Do you program every day?
- How much of each day?
- How long has it been since you’ve programmed most of a week?
- Do you want a job where most of the time is spent programming?
If it’s clear that they once programmed often, don’t right now, but want to get back into it, then I suggest that we postpone a tech screen until they have spent at least a few days practicing. I want them to do their best, so I allow them that time.
There’s no point in misrepresenting yourself on these questions. If you say you program every day, but don’t, I won’t warn you about preparing. You won’t do well, and I’ll interpret your low score as a lack of aptitude.
When I asked my friend these questions, and found out that he hadn’t been programming, I told him that he’d likely not do well on a hard tech screen that had a programming component. But, since I knew him to be a good programmer, I told him to wait on interviewing until after he had been programming for a couple weeks straight. I also told him to practice answering tech interview questions.
There’s no time like the present
Eager to get started, he wanted me to ask him one of my regular tech screen questions. After warning him that he shouldn’t expect to do well, I proceeded. I didn’t bother with something as easy as the ubiquitous FizzBuzz test, because I already knew he was a good programmer. While the question I chose wasn’t very difficult, it certainly wasn’t easy.
As expected, he worked his way through the problem, but was obviously nervous. I think it was an eye-opener for him.
After that, I asked more expository questions (such as “What’s the difference between an interface and an abstract base class in Java?”) and he did better on those, but his answers were not as deep as I know him to be.
However, even as we were progressing, I saw him becoming more comfortable. We quickly went through a bunch of tech questions I have asked, been asked or heard, and he could give better and more complete answers after I gave him feedback on how to improve.
Keep it going
A week later, he sent me an email. He’d been going over questions and programming for at least a few hours each day. His confidence had returned, and he was feeling much better about tackling job interviews. A little pep talk and practice was all it took.