Is it common to lie in job ads regarding the technologies in use?

Question

Wanted: Experienced Delphi programmer to maintain ginormous legacy application and assist in migration to C#

Later on, as the new hire settles into his role... "Oh, that C# migration? Yeah, we'd love to do that. But management is dead-set against it. Good thing you love Pascal, eh?"

I've noticed quite a lot of this where I live (Scotland) and I'm not sure how common this is across IT: a company is using a legacy technology and they know that most developers will avoid them to keep mainstream technology on their resumes. So, they will put out a advertisement saying they are looking to move their product to some hip new tech (C#, Ruby, FORTRAN 99) and require someone who has exposure to both - but the migration is just a carrot on a stick, perpetually hung in front of the hungry developer as he spends each day maintaining the legacy app.

I've experienced this myself, and heard far too many similar stories to the point where it seems like common practice. I've learned over time that every company has legacy problems of some sort, but I fail to see why they can't be honest about it. It should be common sense to any developer that the technology in place is there to support the business and not the other way round. Unless the technology is hurting the business in someway, I hardly see any just cause for reworking the software stack to adhere to whatever is currently vogue in the industry.

Would you say that this is commonplace? If so, how can I detect these kinds of leading advertisements beforehand?

Answer 1

Yes it is a bad idea. If you attract somebody who is strong in that skill set, presumably they have other options, they will more than likely leave. If you attract somebody who is not strong, presumably they don't have other options and misled you as well, they will stay but not be the candidate you were hoping for. Either way you are worse off than you were before.

The secondary kicker is that kind of place gets a reputation for that sort of practice and becomes avoided by potential good candidates.

I've seen this many times.

Answer 2

Being deliberately deceptive is certainly a nasty way to operate and will result in high-turnover.

However, even if everyone is totally "honest", how often does a job description truly reflect reality? Most jobs change over time. At best, the job description is a snapshot of what employer "thinks" the job means at the time of hiring. Perhaps in some cases there is a true desire to migrate technology but it just isn't possible for various unforeseen reasons?

Answer 3

Never attribute to malice what can explained through incompetence

I've seen this a few times, but I'm a bit more sympathetic: I blame incompetence rather than malice here. It's not even usually an individual within the organization, but the organization itself and the natural pressures and incentives at work.

What happens is that an organization, team, or manager decides they need to do the migration. Management buys in... they want this, too, and of course they want to use their existing programmers. Unfortunately, being new to the technology the existing programmers lack the skills for a good migration. To make it happen, management needs to bridge that skills gap, and they have four options: training, consultant, contractor, and permanent hire.

Of those, consultant is out, because keeping them around long enough to accomplish the knowledge transfer needed is prohibitively expensive. Training probably will happen, but it's not enough by itself; it would be like filling the team with new college grads and expecting expert-level work. A permanent hire sounds like a good solution at first, but there are two common mistakes here that doom you to the specifics of the original complaint:

The first is that this is, as stated, a permanent position. That means the new technology is at least one salary more expensive than the old technology right from the get go. That's not gonna make management happy long-term.

The second is that you are asking the new hire to come on board as an authority in an area (the new technology), but they come in with no knowledge of your legacy application, infrastructure, and problem domain, and no real authority in terms of seniority or title. You're asking the impossible.

Instead, this kind of project is the perfect job for a contractor. What you want is a contract position lasting several months, where the first several weeks or months are spent studying the existing application, in design for the new system, and in project planning. No "production" is expected from that early work, expect perhaps a diagram of the existing system (to prove understanding of how things work), a project plan with a timeline for the migration, and design document of the new architecture... but no actual code yet. Even later, this person may end up doing more code reviewing than writing, to help your existing team learn the idioms, quirks, and tricks specific to the new platform.

Unfortunately, finding a good contractor is extremely difficult. They are out there, but the field also tends to be littered with programmers who couldn't cut it at as full-time employees. Management knows this. They also know they can address the extra salary problem by not replacing the next dev who leaves the team (you can already see where this goes now). The result is a often a new permanent hire, and the effects described two paragraphs above and in the original question start to really kick in.

Answer 4

Of course this is a bad idea. Not only does the company bring in candidates under false pretense, but they will quickly gain the ire of many interviewees. This practice does nothing but harm to the organization's reputation, and wastes interviewees' valuable time.

I would personally find ways to make it public:

• identify the company/organization
• how the (false) pretense was presented
• what the organization was actually after

Answer 5

I hate to break it to you, but things change. The priority back in June when a job ad was written - moving from technology A to B - very well may not be the priority in September. Or that was the presumed plan by one technical manager, who left, and its no longer the plan with the new manager. Thats just the way the world works. I wouldnt start attributing the change in job description to deception unless you have some additional supporting reasons to make that conclusion. Doing so says more about you than the company.

Is it common for the job and description to differ? Sure. Job descriptions rarely portray the actual day to day position 100% correctly. At least I've never had a job that matched the job opening perfectly. Its just a matter of the opening often being filtered through a number of people, with different understandings of whats going on. Again, not malice, just bureaucracy.

How do you handle it? Tell the people who want to hire you that you'll be out the door if the migration doesnt start within X amount of time. If they dont hire you, you'll know they werent serious about it.

Answer 6

This sounds like a very bad idea. If I took such a job, I would ask during the interview about the details of the migration. If anything failed to materialize about doing that actual migration within 6 months (sometimes these things take time), I'd probably start looking for a new job.

Fortunately, I haven't encountered this myself, and haven't heard any stories from others who did, until now.

Answer 7

If by bad idea you mean, is it against their own self interest, then it's probably not a bad idea. It's unethical and exploitative (and the people on the site would be the ones on the exploited side of the relationship, were it to happen to them) but it's probably not actually a bad idea (in terms of the employer's self interest).

This assumes that the management is correct in deciding to keep (in the words of FrustratedWithFormsDesigner ) an ancient, heavily patched, poorly documented, festering pile of code rather than replace it. But if they did replace it, the truth is there is a good chance that the management is responsible for the originally software being a heavily patched, poorly documented, festering pile of code, and they may well end up with a shiny new festering boondoggle.

So why not pay the least possible for software you're only going to screw up anyway? It makes sense in it's way - if you're a dysfunctional company then why not know you're a dysfunctional company and plan accordingly? Assuming lying to people and damaging their careers isn't a concern to you.

Answer 8

Just like you wouldn't keep an employee who lied about credentials, employees won't stay at a company which lies or bends the truth unless they're totally desperate. I have encountered this: There is a local company here notorious for stating they are looking for .Net developers when 95% of their application is a horrendous cesspit of Classic ASP/VBScript garbage, and making the defense that only senior people get to do the .Net work. They do this because they know they would get nobody except desperate people in need of any job or the absolute dregs of our profession to ever work for them if it was immediately known they have been using obsolete technology with little plan to move.

TL;DR version: Of course it's a bad idea. A company is welcome to do it but shouldn't be shocked if/when people come in and leave immediately when the truth is known.

Answer 9

How common lying is probably varies from place to place, but in my own experience exaggeration is very common, and lying is not that rare either. A few years ago I was promised some capable developers in my team but the small company where I worked as the lead developer ended up hiring the cheapest labor available to save costs; further back when I worked for a software giant, they employed me as a developer but the actual job was testing.

Some managers / business owners do not understand that not meeting promises and letting developers do what they love sabotage morale, which in turn may significantly adversely affect work quality, because software development is creative work and requires a good mood.

OK, enough ranting. I'd like to share my two cents in helping detect whether the technology migration from advertisements are genuine.

To reduce the chance of being fooled by a potential employer, I myself now use the following tactics wherever possible during job hunting.

(1) Ask for a trial day (or a couple of days) before signing up. Explain to the employer that hiring the wrong person can unnecessarily cost a fortune (if a developer formally starts and then quits after finding out the facts, the employer would have to re-advertise, pay another headhunting fee if they use an agent, go through the interview process again, and not to mention the lost opportunities and revenue). Some employers will agree, because they would like to see how good the developer is at real work anyway. During the trial a developer would have the perfect opportunity to see some code, how decisions are made, and product backlog / road map (could be strong indication of migration timeframe and strategies), if the employer allows.

(2) If trial day is impossible, ask to meet the senior developers. During the conversation, try one's best to ask in-depth questions involving the advertised technologies. If the seniors are knowledgeable in that area, or better yet, talk about some recent experience on applying the knowledge, the company is likely to be on the right track towards the advertised technologies. If the seniors do not know much about the technologies (they just thought it is cool to migrate to the new technologies but have not done much research yet, they will probably be busy maintaining the legacy and forget about the migration in a few months), or sneer when talking about the migration in question (their developers may be wanting the new technologies for various reasons, but probably have had difficulties convincing the company to actually start it), the migration is not likely to happen soon.

(3) If the state allows public access to previous legal decisions, search for employment relationship decisions involving the company. Most companies have clean records, but if the potential employer has lost in more than a couple of employment cases, their history of integrity and honesty should be questioned, so should the genuinity of the advertisements.

(4) If all else fail and one absolutely wants to work for the potential employer knowing the risks of not having the promises met, at least apply game theory during negotiation. Make it clear to the employer that being interested in learning and applying the advertised technologies is the biggest factor in deciding to take the job, the candidate is firm to quit the job if the promises are broken, and insist to have the migration work as part of employee performance review. The potential employer will think twice before deciding to lie, knowing that the candidate is not someone who will patiently wait for three years before the actual migration.

I know as a developer we should not focus too much on certain technologies. Instead we should learn more about a company's product, business and process, using the technologies just as a tool. However, I do believe developers should have access to true information and be able to choose the type of work (overall labor market is a free market in most regions). A company that cannot keep promises (with reasonable circumstances), or is unwilling to invest (given that it has the capacity, and benefits can be clearly seen), or wants to mislead potential employees (instead of treating them like a future partner / comrade), will unlikely to flourish and thus working there can be a waste of time if one wants to be successful.

Answer 10

It is sadly all to commonplace. When a company does not have standards set and enforced it tends to run into problems retaining high quality developers. In addition when they fall behind in the technology curve it becomes harder to attract developers to support there mission critical applications. As they lose their developers their ability to adapt to business requirements falls. The idea is you slap a bandaid on the wound and stop the bleeding. When the wound festers up you get another bandaid. Eventually a new bandaid will not be enough to deal with the problem. At this point a new solution will be enacted quickly and probably with out consideration to actually supporting it. So the cycle will begin again.

If HR is honest about the position it never attracts anyone. Chances are there is someone in the organization that hopes to make it better. Maybe they will get lucky enough to find someone that can both keep it up and running and make a new system that will actually improve the situation. Usually the new solution will come from a canned product sold by some contractor and will just change the problem instead of fixing it though.

The best way I have found to identify these postitions is to ask some specific questions that are easily answerable by a company with standards in place and a working process but will give you answers that do not acually mean anything if they dont. If it is a migration in the future ask about the timeline for it. Ask about the potential problems they forsee with the migration. If they have not identified any problems then they have not taken a real look at migrating and may not. You can also ask about the migration path. If they are actually planning this they should be able to talk about it in concepts. You may not understand any of it but if they can talk about it then there is a better chance of it being real. If the refuse to talk about it or give vague general answers this is a big red flag and you should try and probe more.

Answer 11

The simple solution to this is to require to have your working technology and a description of your future job being written into your contract.

Answer 12

Yes it's pretty common. Migrations to new technology will be sold as being hours away instead of months or years being the most common. No, actually using an agile development style is probably the biggest lie, migrating to the greatest and latest (or at least current) is next.

It's your job as the candidate to weed out these issues, so feel confident to ask for time frames to migration, whether there's a project plan, estimated completion, resources, etc.

Answer 13

Bait and Switch is the oldest trick in the book. Whenever a migration plan from legacy technology is mentioned in an interview, it makes sense to dig in for details ("How long has this plan been in place? What has prevented you from moving forward on it? How much progress has been made so far?"). Be sure to ask people at the working level, not just managers.

PS> I've been down this road too, unfortunately. I quit after realizing the legacy stuff was never going away; the VP had built his career on it and was frightened by anything newer.

Answer 14

This is a bad thing to do deliberately. In relationships (business, professional or even personal) dishonesty means amassing social dept (the counterpart for technical dept in social structures).
Sooner or later you will have to pay for this. Plus it will always bother you, taking away your focus from the things that are really important. It is a waste of time and energy.

Now about the concrete situation you're talking of: this can often happen unintentionally, especially, when there's a communication problem of some kind between the people involved in the hiring and the people actually running the whole project.

It can well be, that the hiring committee thinks, that C# migration is a good idea. It may even be, that management clearly acknowledges the advantages of the migration. But when it's really about scheduling it, they simply put it off indefinitely, because they don't think that the advantages are actually worth the effort.

For example I had once been in a situation, where I got hired as an AS3+PHP programmer to write the networking layer of a multiplayer game. As it turned out, our publisher (who create games themselves) insisted on creating the server software in-house. It actually took about the first 8 weeks of my employment to come to a point where this became clear, because the communication between the studio that hired me and the publisher was not very good concerning this matter.

So I wound up writing an abstraction layer over a web services created by 3 different successive programmers. That was not nice. The nice part was, that I shifted towards optimizing the 3d engine we're using in the frontend and write a lot of nice internal framework code, dealing with all sorts of things I was never intended to touch when joining the team.

In the end, this can always happen to anyone. But as an employer, you should clearly communicate, which of your plans are actually being realized in the foreseeable future, and which of them are just options you're currently considering. And as an employee, you should use the interview to figure this out, simply by asking concrete questions about schedules, milestones, teams etc.

Answer 15

My recommendation is to only do what is in alignment with your career path. I recently started consulting for a small software firm on the premise that they wanted to migrate to using Entity Framework, and eventually move from classic ASP to ASP.NET. After writing a nice Entity layer for them along with rewriting one of their applications using it, talk started to come about how they want me to possibly write a mobile iPad application and do some Apple development. Unfortunately if that is their next idea for me, I will leave because that is not aligned with my career path in using Microsoft technologies.

Like others have said based on their experiences as well, this small firm is one that has no real practices in place and is really far behind on the technology curve. I am strong in my skillset because I have made good career choices to stay within that skillset. If I jump around from technology to technology it is not attractive to serious employers on my resume and I won't get taken seriously for a position that requires strength in my primary skillset, and honestly I have career goals that matter to me.

Don't let yourself fall into a position where you stop using your primary skillset and strengths, and don't let yourself fall into a position where your skillset starts moving in the wrong direction, or worse, backwards. If you are in a position where it all comes down to money, stay but definitely be looking for an out and take it as soon as its available. The worst thing you can do is fall into an unhappy career.