Interviewing candidates for “bad” projects

manpreet Best Answer 2 years ago

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).

manpreet 2 years ago

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.