Take the 2-minute tour ×

We have recently been receiving lots of applicants for our open developer positions from people who I like to refer to as "legacy" programmers. I don't like the term "old" because it seems a little prejudiced (especially to HR!) and it doesn't accurately reflect what I mean.

We are a company that does primarily .NET development using TDD in an Agile environment, we use Git as a source control system, we make heavy use of OSS tools and projects and we contribute to them as well, we have a strong bias towards adhering to strong Object-Oriented principles, SOLID, etc, etc, etc...

Now, the normal list of questions that we ask doesn't really seem to apply to applicants that are fresh out of school, nor does it seem to apply to these "legacy" programmers. Here is how I (loosely) define a "legacy" programmer.

  • Spent a significant amount of their career working almost exclusively with Assembly/Machine Languages.
  • Primary accomplishments include work done with TANDEM systems.
  • Has extensive experience with technologies like FoxPro and ColdFusion

It's not that we somehow think that what we do is "better" than what they do, on the contrary, we respect these types of applicants and we are scared that we may be missing a good candidate. It is just very difficult to get a good read on someone who is essentially speaking a different language than you. To someone like this, it seems a little strange to ask a question like:

What is the difference between an abstract class and an interface?

Because, I would think that they would almost never know the answer or even what I'm talking about. However, I don't want to eliminate someone who could be a very good candidate in their own right and could be able to eventually learn the stuff that we do. But, I also don't want to just ask a bunch of behavioral questions, because I want to know about their technical background as well.

Am I being too naive? Should "legacy" programmers like this already know about things like TDD, source control strategies, and best practices for object-oriented programming?

If not, what questions should we ask to get a good representation about whether or not they are still able to learn them and be able to keep up in our fast-paced environment?

EDIT: I'm not concerned with whether or not applicants that meet these criteria are in general capable or incapable, as I have already stated that I believe that they can be 100% capable. I am more interested in figuring out how to evaluate their talents, as I am having a hard time figuring out how to determine if they are an A+ "legacy" programmer or if they are a D- "legacy" programmer. I've worked with both.

share|improve this question
What do you want them to do? Ask them about that. –  user1249 Jan 10 '12 at 21:50
Before you can determine the questions, clearly identify the possible roles for the person. This will make finding the questions easier and useful. –  Emmad Kareem Jan 10 '12 at 21:51
Make sure you understand what are general terms and what are specific to your language, "abstract class and interface" are Java (and I assume c#?) an experienced OO expert in C++ wouldn't necessarily know them. –  Martin Beckett Jan 11 '12 at 22:45
Martin, I use Ruby and also study the Gang of Four patterns and concepts like abstract class and interface also exist there... –  Michael Durrant Nov 4 '13 at 20:23
add comment

10 Answers

up vote 15 down vote accepted

Well, based on my age, I might be one of "those guys". I certainly get asked "are you comfortable working for someone younger than yourself" at a lot of interviews. While such questions might be "illegal" they're also irrelevant because every boss I've had since my 40s has been several years younger than myself. I don't like managing (and I've tried it), I like programming.


Then you should ask .NET specific questions. You should also ask agile specific questions. Ask the questions that go with your technology and process stacks. If they don't know .NET, then they don't know it.


Totally. Here in Denver, you'll find a lot of quite qualified .NET devs who are old enough to make "catch-up" contributions to our IRAs or 401ks. You'll find a lot more in the DC ecosystem.

Probably the most important questions to ask include things like "how do you keep up with new technology and trends?" I don't think I need to tell you that someone who doesn't keep up with new stuff becomes a dinosaur, and I'm old enough to call some of the dinosaurs "junior".

Edit: added due to change in original question:


Since it is hard to determine talent/skill when you don't know the skill area, I'm going to recommend that you take a look at competency based interviewing. In competency based interviewing, the interviewer is supposed to come up with a list of key job skills and then base some open-ended questions around those skills. Sample questions based on key skills. This will get you away from trivia questions, such as "what is the third parameter of the form.print function?" and more towards "tell me about a time when you..." questions. It is harder work for you the interviewer, but these types of questions tell you more about the person and what they've done. It is also much harder for a "Wally" to fake their way through this sort of interview.

share|improve this answer
+1 for "how do you keep up with new technology and trends?", because it sounds like what the OP most wants is to be able to distinguish vets who have done just that, from vets who have happily made themselves comfortable in their olde worlde field. –  Carson63000 Jan 11 '12 at 0:24
add comment

First off, don't assume your company is more fast-paced than anywhere else. It's been my experience that in smaller companies you get to write code faster and in larger companies you get to fill in forms faster.

For source control... it's not a new concept, I'd be very surprised if they've never used one. It might not be the latest whizz-bang Google endorsed one but hell, they all do the same things at the end of the day.

And for 'paradigm shifts' such as TDD and Agile... any competent developer should be able to fit right in to these working practices. It's not really rocket science. They might not have developed that way before but that's not necessarily a negative thing.

Finally, 'best practices' seem to evolve every few years. Again, these aren't really rocket science and it's normal that a new hire adapts to his employer's way of working, even if it's done through gritted teeth.

Ask general questions really. I think that you could judge the quality of the applicant by the questions they ask you!

share|improve this answer
+1 for "I think that you could judge the quality of the applicant by the questions they ask you!" –  Doc Brown Jan 10 '12 at 22:03
+1 as I often learn the most about an applicant by what they ask, the problem is still there though, as we are essentially speaking different languages regardless of who is doing the asking. Regarding source control, I doubt that they are going to know the differences in branching/merging strategies between a DVCS and a CVCS since DVCS's have only been widely adopted in the past 5-10 years. And these are the kinds of questions that we ask, that was my point when I said "source control strategies" and not "source control in general" –  Marcus Swope Jan 10 '12 at 22:14
+1 for "'best practices' seem to evolve every few years" - They've probably already been through 3 or four flavors of "best" by now. –  robrambusch Jan 10 '12 at 22:30
add comment

If you presume just because someone has deep knowledge of legacy technology, he does not know what a source control system is, you are making nothing but age discrimination - shame on you.

Of course, if someone does not know the difference between an interface and an abstract class, he may not be suitable as a team member for you, but that has nothing to do with age or "legacy" experience, you can meet such kind of "wannabe programmers" at every age level.

share|improve this answer
Wow, I read and reread my question over and over trying to eliminate everything that could possibly be construed as discrimination and still someone is offended. Figures. BTW, go listen to the most recent episode of This Developer's Life where they interview a 35 year old guy who has only worked in FORTRAN since graduation. It has NOTHING to do with age and EVERYTHING to do with experience. Sorry that that wasn't clear enough... –  Marcus Swope Jan 10 '12 at 21:45
If someone has absolutely no experience about the field you are working in, there seem to be not many reasons why you should hire him. On the other hand, ask yourself, do you only need specialists in your team, or do you also need generalists / allrounders, which are "smart and get things done"? Sometimes you will find someone like this among those "legacy" people you were talking of. –  Doc Brown Jan 10 '12 at 21:59
I didn't have any experience when I was hired at my first job, and we hire people all the time that are fresh out of school and have zero experience. With those people we see potential, I also see potential in the "legacy" programmers that I am speaking of. I'm just having a hard time seeing where there was any kind of "age discrimination" in my question? –  Marcus Swope Jan 10 '12 at 22:07
@Marcus: What you wrote might be interpreted in this way: "someone knows FoxPro and TANDEM systems, so it does not make any sense to ask for the difference between an abstract class and an interface, he won't know either". And even when you replace "old" by "legacy" in words, one may assume either that you in fact had "old" in mind. By the way, you got +1 from me for your question, too. –  Doc Brown Jan 10 '12 at 22:17
@Marcus Swope -Saying that you didn't want to say "old" could be taken to mean that you did mean old and were looking for a polite way to say it. Personally I think if you wanted to discriminate against older applicants you wouldn't be asking this question. And it's a good question, though "legacy programmer" sounds like the company founder's incompetent nephew. –  psr Jan 10 '12 at 22:19
show 1 more comment

As sort of a "legacy" programmer myself, I'm assuming that you're interviewing people who're largely self-taught rather than those who've been through recent formal CS classes. I'd also assume that they know the newer language you're wanting them to work with, like C#, at the level you require as well as having knowledge of older stuff like FoxPro, VB6 or mainframe programming that you might need as well.

If they're like me, they probably won't be able to spout off textbook answers to CS questions. It's unlikely for them to be oriented toward the academic side of programming but more on the pragmatic side. So, if you direct your questions and discussion toward hands-on ideas rather than theory you should get a better feel for where they're at technically. I know I hate interviews that come off like a CS dissertation committee meeting.

You would expect some knowledge of source control and support of its use, although it may be SourceSafe rather than all the bells and whistles of TFS or git.

While they may not know all the current buzz words (Agile, TDD, SOLID, etc) they should be able to understand the concepts and discuss them with you. They should show a willingness to learn new things though so they probably should have at least a passing knowledge of some new concepts.

share|improve this answer
+1 for the insight! I hadn't really thought about that angle of most of them being largely self-taught. –  Marcus Swope Jan 10 '12 at 22:29
add comment

They should, at least have some basic concepts based on curiosity. Maybe not all this concepts, but at least some of them.

Otherwise there would be a deep contradiction between not being aware of OOP, Source control and being active in programming in the last 20+ years. And that would indicate to me someone that would have a hard time to keep up with a technologically fast-paced environment like the one you are describing.

You could chain your questions and ease them if you don't get an answer, to scope the actual knowledge of the person :

What is the difference between an abstract class and an interface?


What is inheritance?


What is a class?

Or go with more open-ended questions :

What do you know of OOP?

Can you give some basic principles of it, and examples?

Did you do some experimental project with it? Can you show the code of this experience?

I personally prefer the latter. It makes you look less like a policeman and that should give the interviewee more chance to talk extensively.

Another point is that technology are recycled, and you can easily link principles found in an old technology in a new one. Based on your example of Foxpro, there are comparisons between Procedural Programming and other forms of programming that could lead to questions that could be useful to have an opinion about the capacity of someone to grasp new concepts based on his previous experiences.

That's worth the effort you are putting in preparing those interviews anyway. An efficient "legacy" programmer is a great asset in any development team.

share|improve this answer
+1 for "It makes you look less like a policeman" –  Doc Brown Jan 10 '12 at 21:44
add comment

As others have mentioned, you first need to tease out exactly how much they understand your technology stack and SDLC. This gives you an understanding of how much they will need to ramp up on when you hire them.

Next, you need to find a method of understanding how quickly (and how willing!) they will adapt to your team. This is really the key when possibly hiring someone who doesn't directly meet your current knowledge requirements.

As you will note, the above has nothing to do with age or them being "legacy" programmers. The above is equally valid for Assembler programmers moving to a Java shop as it is for Ruby programmers moving to a .NET shop.

Finally, you should consider what the candidate can bring in way of experience that your current team doesn't have, but can benefit from. Talk to them and understand what they have learnt over the length of their career. From this you can work out the 'Value-Add' you can see from them joining your team.

share|improve this answer
add comment

You could always ask them to code something in any language they are comfortable in. Since that's what they are going to do for you it might be helpful in there among all the "abstract class vs interface" questions. You or someone at your company should be able to read it or figure it out well enough to see if it's any good. If I may throw in a reference to St. Joel here: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

share|improve this answer
add comment

I would ask them about their accomplishments. Ask them what was the hardest problem they had to solve and how they did it. Ask them what things they are proudest of in their career. Ask them what they can bring to the table that a person just graduating cannot. Ask them why you should hire them.

Ask them how they go about troubleshooting a support request or a bug. Ask them about their business domain (anyone with ten+ years of programming that doesn't know something about their business domain is not someone I want to hire) - what are the typical problems or types of business rules they deal with.

If you ask them enough questions about what they actually did (make them describe details not just "I implemented XYZ module") at those jobs you will know if they are the kind of developer who just gets asked to do the easy stuff or is given the hard problems. People who have a track record of solving hard problems are invaluable even if they have to learn some new coding techniques. Ask them what new techniques they had to learn to solve these problems (you don't really care what new techniques as long as they show they had to learn some).

Ask them to do some problem solving questions without worrying about the laguage they use. Then talk about their solution and how it might be solved differently in an OOP language (if they didn't use one) or the specific stack you use and see if they can identify what benefits they might gain from their procedural solution to the OOP one you propose (this will help you see if they are open-minded or stuck on their way is the best).

Do some soul searching, what would make you want to hire this guy over someone with experience in the current stack you use? For instance, I do database development in SQL Server and I would be likely to prefer an Oracle developer who had been doing database design for large complex business systems over someone with SQL Server experience who has only written crud or Web applications for tiny databases because that person whould have more of a feel for the problems we have with a complex medium-size system. Once you have really thought about what those people could bring to the table that would trump actual experience in the stack you use, then you have a good idea of what type of experience you are seeking from the "legacy" programmer, which will lead to the questions to ask.

share|improve this answer
add comment

You can ask basic object oriented design questions of them to see if they have knowledge of OO development. OO isn't new, anyone who has experience in programming that doesn't take the time to update their knowledge base probably isn't a desirable employee. I would avoid questions like the one you listed, because the answer you are looking for depends more on knowledge of .NET than general OO practices.

focus on things like

  • What is the benefit of polymorphism?
  • describe an example where inheritance is beneficial.
  • what are the differences between public/private/protected, or the purpose of encapsulation?
  • ask to design classes based on a given scenario, or critique a class diagram
share|improve this answer
add comment

I think one of (if not the) main point is to stick to concepts rather than vocabulary. Use of different technologies, development stacks, etc., will often lead to using different terminology. In such a case, asking about the difference (or similarity, etc.) between term A and term B isn't likely to accomplish much. Instead, ask them about how they'd solve a couple of problems that might be reasonably solved used the concepts embodied by terms A and B.

From that you might run into any of (at least) four things:

  1. They know and use the terms with which you're familiar
  2. They use different terms, but still describe the same concepts
  3. They take enough different approach to render those concepts irrelevant
  4. They don't understand what you're asking, solve the wrong problem, etc.

Most people will prefer 1, and consider 2 a second best. I'd suggest that 3 is often the most interesting. It's the most likely to indicate somebody whose contribution will go beyond just another warm body cranking out lines of code, and instead be somebody who can shake things up by challenging your assumptions about how things should/must be done. Obviously number 4 requires analysis -- it may indicate incompetence, but could also indicate that you've asked the question poorly.

share|improve this answer
add comment

Your Answer


