Interviewing candidates for "bad" projects

Question

I am a senior developer and I do technical interviews for the small software company I work for.

I know there are projects which are terrible to work for (old technologies, complicated clients, bureaucracy, working from client's office rather than company's one, lots of maintenance rather than pure development, etc), but I don't work in those projects (luckily). There's also high turnover in those projects because people usually don't like them, but they apper to be profitable for the company, at least in $$ terms [Note]

Most of the time candidates ask me how I feel working for the company, or about the different projects/technologies we use.

Sometimes when I interview a candidate who has a high chance of entering the company and start working in one of those projects, when they ask me about the project, I find myself in a complicated position because I believe there are more bad things than good to say, and I don't want to lie to them, but I also don't want the company to lose a candidate, specially if it is a good one, and if it is not 100% sure in which projects are they going to work.

Some common problems I've seen:

• Some benefits, like working from home and free-afternoon-per-month (yes, we have one free afternoon per month that can be requested anytime) are usually lost when working from the client's office. HR usually omits that.
• Some clients we work for mantain some APIs we consume, but they aren't well documented, even though many times the teams have complained. Every time the client changes the API contracts, it's a burn for the team.
• Some projects don't use any version control system because the client doesn't allow it.
• Other clients give the devs Virtual machines, which are incredibly slow - devs can experience lag in each keystroke.
• Since there's high turnover in these kind of projects, there isn't an "expert" in the project, and the documentation is really bad, which leads to projects with lots of "surprises"

...and more.

How should I deal with these? Up to which point should I be completely sincere? Should I "make up" some things?

Edit after some Comments

First of all, these problems don't happen to all projects. It happens to few of them. In the other ones we don't face these issues and we don't have a high turnover.

Regarding to the one-afternoon off, since the devs are working on the client's office, the client don't want them to leave - and that's why this benefit is kind of "lost". I know they were complaints, but I don't know if the company have fixed this issue.

The other problems (the kind like about APIs not properly documented, and keystroke lag), happens with clients which are big business, which are bigger than us (remember - we are a small software company).. And also these customers are among our biggest clients.. but these customers' business is not IT related - so they may have have a small IT area, but they still have position power to decide since they are the client, and the client does what the client wants to do. [note 2]

Having said that, I know they have tried to educate these clients - but with no success. I also know that they are looking for new projects, so at least the "bad" projects that are important for the company in profit's terms can be "less importants". But this, I believe, is out of the scope of the question, as [note 1] stated.

[Note] of course the project's software process needs to be urgently improved, but that's out of my scope.

[Note 2] I don't live in USA (you might have noticed because of my basic English level), but I live in a third world country - here lot of things are still done in paper, and without using computers at all. So while having an IT area seems a huge improvement, still there's a lot of progress to do. Educating the client might be too hard, most of the times they look on short them and they don't want to invest in technology too much. Heck, I have interviewed many candidates who were coming from companies which didn't use CVS at all (and that was one of their reasons, among others, to be looking for another job opportunity).

Answer 1

I don't really know that there is such a thing as a "bad" project per se... but sure, I can understand where it would be challenging to talk to potential new hires about a project that you don't find all that fun to do. There are maybe a couple of ways I'd approach it:

• Don't "make up" or lie about stuff. It's okay to be honest about how guys are starting out. If it's a "we like to try people out on this to make sure they're up to snuff but if we like you, we'll have you do another thing" situation, I think that's a perfectly valid thing to say to someone. However, if you tell someone things that aren't true the best case scenario is that they'll think poorly of you instead of the company, and the worst one is, well, you have to interview for the position all over again in a couple of weeks after they quit.

• On the other hand, don't go out of your way to denigrate it either. There are two reasons for this: for one, one person's pain in the butt is another person's opportunity. Who knows, maybe the next person you hire in will be the one who looks at some of that old technology, for example, and persuades your client to move into something newer. Or, you know, maybe not, but there's no point in, like, outright trashing it. The other reason is that when you relate negative information to people they will associate you (and in this case your company by proxy) with negativity. It's just the way the human mind works, and it's a big part of why everyone thinks poorly of the office gossip.

• Work those soft skills! You know how real estate agents will often refer to a small house as "cozy" or a broken-down one as "a fixer-upper"? Well, there are surely positive ways to sell the experience. Okay, so maybe this job isn't something that you want to do, but depending on things... for example, the focus on maintenance rather than development might be sold as a great opportunity for a person new to S-Dev but with, for instance, a background in QA or tech support to hone their skills while working inside an established framework. If you're in a client's office working side by side with them, that can be an excellent situation to learn how to talk to and understand end users and stakeholders (which by the way is a really, really good thing for any programmer to learn). Even dealing with bureaucracy is a skill that can be honed and which can be very, very valuable in some jobs.

• Some of these things are going to be deal-breakers, or at least they should be. Sorry, I had to add this on because the original post was amended. I'll try to keep this as industry non-specific as possible but I do have to say that there is no good excuse for the lack of source/version control, period. Even a tiny house has access to Github. If the client doesn't allow it the client needs to be educated as to why this is necessary. As this applies to your situation, this is a tough one. If I were to apply to your place, one of the things I would definitely ask about is your source control. If you lied to me about that, I might walk out the first day. I'd almost certainly walk if I found no source control and received pushback when I tried to implement some form of it. A more junior dev may not "get" the importance of it and so may not ask. Even then, I don't know, I'm on the fence as to whether or not you should feel required to bring this up on your own.

To be honest, all of those other things are workable issues. I've had to deal with slow and laggy workstations, bureaucracy, acting as my own BA, figuring out what I'm supposed to do as I go along... in fact, all of these things are, I feel, part of the software development experience. Working without version control is not, or at least should not be (and I am sure that other industries have similar "no go" things).

Answer 2

I would answer this question by saying something like this:

"There are some great projects you could work on eventually but you will have to start with some of our older legacy projects. They're tough, not as much new development but you will learn a lot from them and it will be great experience. I can't say how you'd find working on them as we all differ, personally I'm not much of a fan of bug-fixing and working with other people's old code but I'd at least enjoy the opportunity to show how much I could improve the code. You might enjoy it and if not, you'll be given the opportunity to change projects after a while anyway. As for the company in general, they're great, I've really enjoyed working for them."

I have had to say something very similar to applicants before. I don't want to lie to them but you can definitely "soften the blow" as it were.

I do not think you should outright lie for the company but at the same time, if you are happy working there then say so and just focus less on the projects they're likely to work on.

Answer 3

On lying by omission

If I only have limited employment options: I'll feel disgruntled, and eventually leave after your company has made a big time and money investment in me.

If I have multiple employment options: I'll leave very quickly, and probably spread the word to others who ask. Your company rep is bound to go down if HR does shady things (see: HR usually omits that)

On lack of tools to do the work (no version control, slow computers)

Pretty much the same as above. No dev worth their salt is going to stick around if their workplace isn't facilitating their work. That would be like asking a carpenter to hammer nails in using a banana. The only reason to stick around would be if there was no other option.

On projects that have "baggage"

When you mention projects that have lacking documentation, difficult clients, old/outdated technology, these are challenges that every big company will face at one time or other. As an interviewee, I expect you to mention these things upfront because as an employee, I expect the company to have a strategy to tackle these things. The core problem here isn't that you don't know how to tell interviewees about these problems, it's more that your company doesn't seem to have a strategy to eliminate those pain points simply because it is giving you cash flow. That is complacency at best.

---

How do you communicate the reality to interviewees?

My suggestion would be to be honest. If you hire them, they will figure out the truth sooner rather than later. Let them know now, so they can make an informed decision. Those desperate for a job will still say yes, and those that aren't, will say no (which is cheaper than hiring them and then having them leave quickly).

Answer 4

As a person recruited for such projects, this is how I see it:

• Make sure you don't lie or mislead. even by omission. This will make people go away, fast. Probably without doing much good to the company before they go.

• Don't hold people accountable for mistakes you can't prove are theirs, and theirs alone. And make sure they know it. "Some projects don't use any version control system because the client doesn't allow it." - that's just terrible. Can't you even use GIT on your local copy of code? If that's the case, many developers will turn around and run. And that's a proper reaction. Without version control, you don't know if the fault is really theirs, so if their promotion, benefits etc are supposed to depend on the bugs someone else could introduce to the code, it's just unfair to them. So make sure they know it won't happen.

• Don't set hard deadlines on anything in touch with APIs that are undocumented or can change without notice. Again - make sure they know it.

• Negotiate with your clients. Delay for keystroke is a deal breaker. You can't expect dev to be focused on his work if he does not even have technical means to type.

• Tell them up front how long they will stay at bad project. I could agree to spend a month, maybe three, working in such conditions. Maybe. If money was good enough. But I'd like to be sure when it would end.