How to convince interviewers you have not forgotten how to do your job after a long break?

Question

I have education and work experience in IT, specifically in web development. I have been programming and writing markup for 15 years. I have worked professionally as a web developer and used those skills in my personal life.

I took a break from the IT industry for the last two years, because I just needed a break. I have recently started trying to get back into the workforce again.

Late last year, the CEO of a local company found me on LinkedIn and urged me to apply. I met with the CEO and the head programmer over the phone. The head programmer made it sound like I didn't stand a chance, because I hadn't used a specific programming language (C#) since college.

While I was a little insulted by this condescending remark, I didn't respond and just let it be. But I really wanted to put him in his place. Programming is like riding a bike or tying your shoes. It's not something you just "forget" to do.

I have worked extensively with a couple of other languages having similar syntax (for example, JavaScript). Any good programmer can rely on countless resources and documentation if they forget a command or a method. If you know one language, picking up another isn't hard.

Fast forward to today, I talked to a recruiter about another open position. He alluded to the idea that his client may not like that I haven't worked professionally with web development in a while. I let that be as well, but I'm still going to try for the position.

How do I deal with employers or recruiters like this? Is it worth rebutting such a "witch hunt"?

Answer 1

How do you effectively rebuttal a "witch hunt" like this?

It's not a "witch hunt".

You have to see it from their perspective.

You have programming experience, you have access to Google and Stack Overflow, and you're really smart, but so are so many other job-hunters. They also have programming experience, access to Google and Stack Overflow, etc. In other words, you have to differentiate yourself from those other job-hunters.

And I'm afraid verbal judo is not what you should focus on right now.

If you want a job using C# (instead of JavaScript), you should build a small project in C#. If you want a job using Java, you should do a project in Java.

And while yes, someone might hire you to use a completely different language than the one you're used to using, that does happen. If you really want to increase your chances of finding a job in a particular area, you have to be willing to prove that you're willing and able to take on a new project and do it in the particular language (that you're not completely familiar in yet).

And there is no better proof of that than a toy project you've been currently working on.

The toy project can then be used as a starting point for a discussion. Having a project to talk about is actually a great way to steer the conversation toward something you know. Without that, the interviewer may just ask stupid generic questions he/she copied from the Internet that are by design difficult to answer.

Answer 2

You are essentially applying to a C# job and you have only used it in college.

You then say you have worked with other languages and know how to program.

I am not a C# person, but a Java person, and the Java ecosystem and best practices are so large that even though the language itself is rather small it is not just something you pick up on your first day. Even with the internet and help and all.

This is probably also the case for C#, and the senior developer knows this, and you don't!

That's a red flag right there, and a big one too.

I would get some more experience with C# and put some sample well-polished projects on e.g. Github for the world to see if I were you.

Answer 3

RE: Riding a bike

Programming is like riding a bike

Riding a bike fast consists of two elements:

• the skills
• the fitness

In your case it seems that you were not able to demonstrate fitness.

Imagine that you are a manager of the local bike club and you're looking for a new rider to join your team. Would you take in a rider that hasn't been training for 2 years?

In many cases bike clubs focused on performance would want a cyclist who is in great shape, at the time of hiring so that they can avoid the cost training the rider up.

Re: Understanding computers

Knowing how to program requires an understanding of how computers work, how they "think". If you know one language, picking up another isn't hard.

Cost of upskilling

It is irrelevant if it is hard or easy. What matters is how long it will take for you to be productive and if you don't know the language/technologies this may takes months.

Solution

I suggest getting into an open source project.

With public commits, you can easily show your contributions (which show your skills) and the 2 year gap becomes irrelevant.

Answer 4

Don't mean to beat up on you but your depiction of programming knowledge is naive.

Syntax is easy. Look up syntax is easy. What is hard to know is what to look up.

When would you use a Task versus a Thread? LINQ has been around a few years but I bet it was not around when you were in college. When would you use EF versus SQLLINQ versus raw TSQL? Have you used message queue?

I code C# full time for the last 10 years and I don't know all the features. 4 years ago I was full time ASP.NET. I am not up to speed on any of the new stuff. It would take me a month to get up to 1/2 speed and 4-6 months to get fully up to speed with the new stuff. Employers are demanding the new stuff because consumers are demanding the new stuff. Consumer may not know what asyc is but they know when the UI freezes.

I suggest you drop the attitude and come up to speed on the latest features.

Answer 5

The main way to convince interviewers you have not forgotten how to do your job after a break is to show them. Create a spare-time project, develop it from start to finish, and provide them with the source and/or links to where it is hosted. "You're worried I've forgotten how to code? Well, here's some code I wrote last week!"

A bigger concern is the apparent assumption that programming is something you have to learn once and never again, the rest is mere detail. In particular, the suggestion that because you know JavaScript it would be trivial for you to pick up C# is a red flag. For a start, the difference between strongly-typed and weakly-typed languages is enormous! Knowing JS, could you write code that compiled in C#? Perhaps you could, especially with the help of an IDE. But would it be idiomatic, make proper use of the (enormous) .NET Framework, efficient in its use of the GC, run in parallel where appropriate, etc.? I have doubts.

To give an example from my experience, when I learned C# having previously worked mainly in C and C++ (all syntactically similar languages), I'd estimate it took me two or three years to reach a similar level of expertise. Does this prospective employer have two or three years to wait? Perhaps they don't.

It's true that understanding employers will know that good developers can learn new languages eventually. It's also true that good employers will train their staff, rather than wait for some other company to do it for them. But, it's also true that the earlier a new employee can become fully productive, the better, as far as the employer is concerned. It is possible that their concerns may not be about your innate coding talent as much as your current skill-set and relevant knowledge. The more out of date those things are, the longer it will take you to get up to speed, and until that happens, you'll be drawing a salary without contributing (much). Looked at in that way, it's perfectly understandable that an employer will have reservations. To overcome those reservations, show them you know what they need you to know. While working on a project for that purpose, you may even come to realize that it's not as easy to transfer from one thing to the other as you seem to think.

Answer 6

Assuming both that your C# experience was near the start of the 15 years you talk about (given you mention that it was in college), and that they were hiring specifically for a C# position, they weren't really suggesting you had "forgotten" the job - more that you had never really done it. C# and the .NET Framework of ~15 years ago is a very different animal from what you have today. So much so that the college experience would be nearly worthless.

Yes, your experience working in other languages would give you a not-insubstantial head start in learning it, but the reality is that you'd be on a pretty steep learning curve for the first few months at least and if a company is hiring for someone experienced in a particular language/tech stack then that's generally because they need someone who can hit the ground running so to speak and be productive straight away, not in x months time.

I talked to a recruiter about another open position here in town. He alluded to the idea that his client may not like that I haven't worked professionally with web development in a while.

If the position was for a full stack or front-end based role then I can see what the recruiter was getting at - in particular the JavaScript frameworks move very fast and this may concern them. In order to counter that fear the best approach is to demonstrate knowledge of how the development landscape has changed in that intervening time.

Explain to recruiters/interviewers that you understand that the industry is fast moving, but that you have been keeping up with the changes in your personal time (assuming you have - if not, take a weekend or two and make it true) and that you feel you'll able to be productive immediately should you start a new position. Ideally if you have the time you could produce some samples of code in the frameworks, etc. that have been released since you left the industry and publish them on GitHub or similar to back up your claims.

Some employers may still balk at the idea, but most reasonable ones should understand.

Answer 7

The problem isn't the long break.

You're comparing a:

• mostly static
• compiled
• strongly typed
• class-based

language (C#) to a

• dynamic
• interpreted
• weakly typed
• prototype-based

language (Javascript).

And you think that they are interchangeable because they have a similar syntax. If I were the interviewer, this would be more than enough information to stop the discussion right away.

Answer 8

You might want to address that point yourself before they do, and take the wheel while explaining how the pause isn't really a drawback. Try to compliment them e.g. "You're a senior dev, you know that it's not about memorizing syntax, but about knowing what one doesn't know"
Also, you might want to demonstrate that you know what's new and what works well with their programming stack. e.g "While I have been in my pause, I've been following the news and trends of language X and framework Y, I can easily build something following the 2018 standards"

Answer 9

You must realize that the head programmer probably has a point. I would not let somebody who describes himself in the way you do (JavaScript background, categorizing languages in the way you do) close a big and critical OOP codebase without you answering some serious questions.

For me it is something very different if you code in a prototype based language or a class based language. I myself am proficient in many languages, however all of these are class based (even if I have no fundamental issue favoring one over the other), I know that my weakness is in using prototype based languages - and if I would apply for a job in these then it is obvious that I would need to convince the technical person interviewing me that I know what is going on.

What you typically should show in such a situation is the attempt to clear up what is missing from your skills, including accepting that you may not be the technically most proficient person for the job, but the most professional with the will to learn and do what is needed.

Answer 10

Programming is a skill, languages are mere tools. The best counter argument would be. "If you had a skilled auto mechanic, would you doubt his skill because he hadn't used an oil filter wrench recently?"

The skill is more important than the tool.

Answer 11

I understand where you are coming from completely. I am a software engineer who started off as a hobbyist and I had a bear of a time convincing recruiters and HR departments to give me my first chance. It sounds like the barriers you are running into after not doing dev work for a while are quite similar. With that in mind, my advice:

I have education and work experience in IT, specifically in web development. I have been programming and writing markup for 15 years. I have worked professionally as a web developer, and utilized those skills in my personal life.

What I'm about to say might sound silly or superficial, but it has been born out in my experience during my past ten years in the workforce. I've found that companies that describe their developers as "IT" and that put items like "writing markup" in their job descriptions tend to be more traditional, less flexible operations. IT also tends to be a cost center within a non-tech organization, whereas development tends to be "where the magic happens" in a tech-focused company. Having been on both sides of that divide (four years in QA/programming in an IT role, the rest in non-IT programming), I'd encourage you to aim for the latter sort of role if possible. In my anecdotal experience, IT cares a lot more about the certifications you have and how good of a candidate you are on paper (e.g. do you have any gaps in employment?) whereas software shops seem to care much more about "can you solve this whiteboard problem/take home programming assignment" which I think would work in your favor. This is somewhat tangential to the rest of the answer but still worth your consideration!

I took a break from the IT industry for the last 2 years because I just needed a break. I have recently started trying to get back into the workforce again.

It helps to have something to show or a story to tell about your break. If the break was, "I was just burned out on programming" I totally get that, but you'll want to have a positive spin to put on it when it comes up in interviews. It'd be nice to just be able to be straightforward in your reasons for this but I think a little personal marketing here would improve your odds. Have you had the chance to work on anything interesting these past two years, or travel, or maybe follow a non-programming passion?

Late last year, the CEO of a local company found me on LinkedIn and urged me to apply. I met with the CEO and the head programmer over the phone. The head programmer made it sound like I didn't stand a chance, because I hadn't used a specific programming language (C#) since college.

If you also took time off from personal software projects, it'd be good to pick that back up now instead of after you return to the workforce. When I was trying to make the jump from hobbyist to professional, side projects provided evidence to bolster hiring managers' confidence that I wouldn't just crash and burn on day one.

Here's an example I created (much later) as I was trying to learn a new language (Rust). It's an amateurish Tetris written in a language I had not mastered. Even given that it is less than professional grade, being able to point to work I've successfully completed in a language that was new to me has helped me make my own case. Demonstrating your C# proficiency in a side project would de-risk the hire from the company's perspective.

While I was a little insulted by this condescending remark, I didn't respond and just let it be. But I really wanted to put him in his place. Programming is like riding a bike or tying your shoes. It's not something you just "forget" to do.

I sympathize with you here. Still, the synchronous request/response apps I was building on top of Django in 2012 bear very little resemblance to the single page apps people are building these days on top of generic Rest APIs. So much logic has moved into the frontend. You still know how to ride the wheeled vehicle you learned to ride, but the kids these days are riding unicycles. You don't need to use the latest and greatest to build useful interfaces, but I have found that hiring reqs have a bias for newer frameworks. You should at least familiarize yourself with them so you can make well-reasoned arguments for when they are or aren't appropriate.

Any good programmer can rely on countless resources and documentation if they forget a command or a method. If you know one language, picking up another isn't hard.

True and false. I've had jobs where I contributed code in Java and C#, but Python is my bread and butter and I can confidently say that though I accomplished the tasks I needed to accomplish in those other languages, I did so without familiarity with language idiom and my code certainly had "an accent" that gave me away as a non-native speaker.

Fast forward to today, I talked to a recruiter about another open position. He alluded to the idea that his client may not like that I haven't worked professionally with web development in a while. I let that be as well, but I'm still going to try for the position.

How do I deal with employers or recruiters like this? Is it worth rebutting such a "witch hunt"?

By being extra good! You're not experiencing a witch hunt; you're experiencing the doubts of people who are unfamiliar with your work and your capabilities. This is heightened because performing well in your current role is taken as strong evidence of competency (as I found when trying to get a job as a hobbyist without that track record). It's amazing how much this sort of proof matters; in 2011 I couldn't pay someone to let me program for them but after a year of experience with the job title programmer (during which I was not a very good programmer even), I started getting recruiters reaching out weekly or even daily.

You've got to give interviewers a warm and fuzzy feeling about your ability to accomplish the task they need completed. You can do this by refreshing your skills, sharpening your interview technique, and showing them work you've recently done. If you've not done work recently, now's as good a time as any to jump into a side project that will dust off your programming skills AND give you a finished project you can discuss with interviewers.

Answer 12

My best advice here is show, don't tell.

If they speak as though you've forgotten what to do, answer with applied knowledge. Show that you have experience.

In your spare time, write an app or two, put some of your work live online and include it in covering letters etc. So they can see your work. Better still, leave the code open to viewing on GitHub or a similar service.

---

Also, a brief note from my own personal experience. Recruiters will use a scatter-shot approach, to match as many potential candidates as they can up to the positions they're trying to fill. This was very frustrating for me when I was looking for an entry-level position, and being sent 300 miles to interview for a position whose salary is higher than I am now, 8 years later, earning.

I eventually found work when one of these recruiters very directly decided to break contact because I wasn't getting any of the inappropriate jobs he was putting me forward for.

I googled jobs with Rails (my main medium), and sent speculative emails, as well as answering job ads. I found the job myself having been very honest about my position from the start, as opposed to working through a professional recruiter.

Long story short: If the path of recruitment agents isn't working for you, try another way.

Answer 13

In my experience as both interviewer and interviewee you had a bit of bad luck. Many companies don't care if their new employee knows the language or framework du jour that they happen to be using at their current project.

After all IT is a fast changing field, what's the latest and coolest today will be old, crusty legacy code by tomorrow. What I want when interviewing someone is to figure out if they have good CS fundamentals and can easily pick up new things, let it be languages, frameworks or programming styles.

That, motivation and interest in programming (any cool projects on github? working on a open source project on the side? what do you think of the latest developments in your favorite language?..) are way more important than whether you know C#.

That pretty much implies what kind of answer I'd give an interviewer in that situation: No I don't know C# right now, but I'm motivated to pick it up and I have a lot more valid skills that I can bring to the company than knowing some specific syntax.

Answer 14

First, don't assume that an "aggressive" question from an interviewer means they have a negative view of you. They might just be trying to see how you respond to a bit of pressure.

Secondly, there are people in this industry who really believe that you need to have 10 years experience of all the technologies you will be using on a new project, and completely fail to understand that good programmers are learning new tricks all the time and that what they really want is someone who is good at learning new skills. Use the interview as an opportunity to tell them that they are wrong: tell them how many new languages and technologies you have mastered in your career. If that works, you're dealing with an employer who will be good to work for; if it doesn't, you're best out of it.

Answer 15

Some excellent answers here suggesting the OP to make a toy project. I would suggest him to go a step further and try to get some work as a freelance web developer. There are plenty of web development tasks on freelancer website. Once he does a few projects there, he can link his freelance profile to linkedin.

Answer 16

Two things:

A recruiter's opinion isn't very useful, they are not the hiring manager, and don't have a say in the final decision. Your recruiter's comment was unprofessional, but common place as they're just people like anybody else. They are also banking on you getting a job in exchange for your time, so that may just be a way of them not wanting to work with you. Either way, move on, there's a lot of recruiters out there and as I said they're in it for the money not to help you.

In your situation I recommend direct apply, possibly with a cover letter stating some of your qualifications, but here's what you'll be up against:

If I can hire two programmers and both can solve the problem, where one has recent experience and the other doesn't, which one do you think will solve it faster (on budget)?