Qfyilyi

In my experience, the attitude of engineers is not usually the reason legacy code doesn't see improvement. If you are able to foster an environment where maintenance, refactoring, and improvement of existing code is valued and encouraged then you will get the results you are looking for.

Typically I see pressure from the business to deliver features, or criticism from management (Roger spent all this time in codebase X and there's no functional difference! Why did we spend all this time/money?).

Most engineers I've worked with hate to be stymied by legacy infrastructure and will happily refactor or replace it given the right environment. Try the following steps:

• Encourage refactoring as you go


• Regularly discuss the value of maintenance


• Acknowledge the success of maintenance projects, both to engineers and management


• 
  fight for your team's maintenance time, even if you have to bake it into estimates for new features

Once you've created an environment that values continual improvement, you can list that as a perk in the job description. "Our company values testing, refactoring, CI/CD, and continual improvement. We don't let code rot, and we won't let you rot either."

So, I'd say a few things will help you with this:

• Be willing to employ more experienced (and thus more expensive) developers, as these will often have got over the 'ooh shiny new tech' stage of their careers


• Create a package of benefits aimed more at this group (think more pensions, remunerations, working atmosphere, and less table tennis, fussball, and X-boxes)


• Given that you want to get people to do a fair bit of work on legacy code, improvements, business-as-usual, etc., try to introduce opportunities to do a bit of more cutting edge work for a small portion of the time. Allowing people to spend time on personal projects is a good way to do this. Remember that if you need your devs to use current or older tech, they will fall behind with tech that will advance their careers in their next job - so let them keep up too.

Having a - no offence - duller project you need devs for, is one of the bigger challenges in IT recruitment, because you can't highlight all the buzzwords you need to, so most of the way you can get good staff is by having other things to appeal to them.

I think the other answers are good but I would add extra emphasize that a good job description/advert will allow people to self screen. You should then be able to use your interview questions to judge who has actually read it properly and clearly understands it.

I think you are approaching this from the wrong perspective. It's not a problem of recruiting, it's a problem of leadership. Virtually every programming job is a mix of writing new and maintaining older code.

How they are led and motivated will be the key to getting the vast majority of developers to perform well.

Does their manager communicate the companies priorities clearly to them? Most devs are motivated and happy do whatever is most important to the companies success.

Do you makes sure they are rewarded for their contributions and made to feel the company cares about them and their efforts?

Do the company priorities make sense? Jerking devs around from one project to another, or burying them in endless bug fixing work over trivial problems is a great way to dis-motivate your devs. Does your organization regularly make schedules and problems "urgent" and require devs to constantly work over-time to solve them?

Does their manager and the company foster a team oriented atmosphere? When it's crunch time do their manager and upper execs there to help out, or do they just expect the lower ranking devs to work "death marches" to solve whatever their "urgent" problem of the day is?

Your job as a recruiter is to communicate reasonable expectations of the work environment. If it's mostly maintenance work, your applicants will filter themselves out nicely if they don't want to do it.

In my interviews, sure, I ask technical questions, especially to figure out unclear bits of the CV, or to dig deep into topics they say they're experts in.

Aside from that, I spend as much time as possible to simply talk with them about our field. I'm open and honest about what the goal of the current discussion is (i.e., in an early phone call, I would say "this call is just so we can get to learn to know each other, this is not a test" etc.; or in an on-site interview I might say "part of this interview is to find out the exact team in my company where you can start working, matching your interests as well as possible", and I mean it).

This is not made to let them lower their guard, or trick them, but just to get an honest discussion going. Frankly, this gives me the most useful information about the person. And as part of it, if I know that I need someone to work on older software (which, in fact, I sometimes do), then I will describe plainly and clearly what I need. I usually can tell from their reaction whether they like that kind of work, even if they don't but still say "yes".

What questions or polite (not overly time consuming) tests would you ask to find someone who is interested and willing to maintain and improve code?

My question would be: "Are you interested and willing to maintain and improve code?" Plain and simple. Honest and direct. Everything else would waste their and my time. If their reaction shows me that the answer is "no", I go on from there. If it's "yes", I'll do the usual (dig deeper, let them explain their understanding of this, etc.).

Their reaction goes into my overall evaluation afterwards. I.e., if they don't want the maintain work, but have plenty of other skills that we need, and if I'm sure that the current team structure can handle someone like that, then all is well. Or if they do want this, but somehow could not convince me that they really meant (or understood) it, and did not bring much else to the table, then we'll part ways.

I am going to add one new dimension to the answers already given. In a nutshell my advice on this question is: Look seriously at older workers for this particular role.

The IT industry has long been affected by the issue of ageism, preferring the fast young minds of youth over the slightly slower minds of older workers. That said, those slightly slower minds have a wealth of experience and discipline that many younger workers often lack, and maintenance coding requires just such discipline.

Hiring new coders seldom requires much experience because you will be teaching them all the idiosyncrasies of your company's codebase and work methods. A "kid" fresh out of college might know the latest and greatest ways to (as you put it) chase the new and shiney but you cannot teach the instinct for finding bugs or the mindset required for plodding through miles of unfamiliar code. Experience is what provides those attributes and experience requires time thus years thus age.

Take 2 minutes and click the following two Google queries. Then for each of these two queries skim the content of any 3 hits (6 articles total):

• Query #1 : myths about hiring older workers
  


• Query #2 : myths about hiring older programmers
  

Also we all know that once a programmer has mastered one particular language they seldom have trouble learning new ones. Look to see if their work history shows they adapt well to new environments. Look at how many languages these older workers have, not if they know the cutting edge ones or even possibly the exact one you need. If their experience is close they will learn and thrive on that learning. You are hiring them for legacy work, exactly the opposite of cutting edge.

So do your due diligence. Never use age alone as a reason to hire or not hire, but in a case like this consider that age and experience are real assets and any preconceptions you may have about hiring someone perhaps age 50 or more should be carefully examined because you might just be missing out on exactly the skills and attitudes you asked about in your OP.

Oh and one last thing. Do not be surprised if you get some evasive push-back from your HR department. For complicated (but erroneous) reasons based in those aforementioned myths, HR departments are often prone to try and filter out older applicants in IT departments. So be aware that you may need to educate your own manager and HR department that you reject these myths, provide them some of the studies you will easily find online from those links above, and insist that they are not to reject the so called "over qualified" job seekers but rather to send them through to the interviews.

In my opinion it is not the point how people feel about refactoring vs recreating code. The question is why or when, a question of reasons for a decision in particular cases. I want to explain why:

Writing new code including a setup of a new concept is often experienced as a thankless job since the economy usually puts pressure on developers to work efficient in the purpose of generating volume of sales in shortest time.

Not infrequently I got an interesting project to be extended. After several hours of code review I was horrified about the misconcepted code base. It was not really concepted in an extensible way and had several security vulnerabilities. Building additional code dependent on that base had lead into a hardly predictable behaviour.

I experienced many situations when I had to suggest to do a complete rework based on a new concept while including existing algorithms of the old project. And that did not cause much enthusiasm on my mind facing a huge task.

My conviction is that most developers love to do an easy job based on a well structured framework - so far it exists. I do. Why to rack one's brain when there is a much more comfortable way to do it?

Thus when looking for new team members we should ask candidates for scenarios in which they would prefer to rewrite an existing code base prior to refactoring/extending and for detailed explainations for their reasons. We want to know if the candidate is able to take reliable decisions conforming with our company policy.