We have recently hired a new mid-level QA person, and the in the first few weeks, he did fine and seemed to catch up decently in training/learning of the product.

When we finally assigned him "real" tasks, he did not seem to be able to do it himself. It has been the third month, and yet, he still needed people to tell him what to do in order to finish his assigned tasks or to sit through with him in a product-beta testing session and to tell him exactly if there is a bug despite the fact that we have presented him with docs detailing the expected behavior.

"he's new and needs more time"?, fine, I can live with that.

But things has gotten so frustrating to the point I honestly believe it's adding negative velocity.

The first "major" mistake that got me to pay attention was when he resolved a merge conflict in the strangest way I had ever seen in my entire life.

He was working on some tests in a fairly outdated revision of a branch. And for whatever reason, he modified some source files (ie., product code, not test), which itself was already a no-no. Inevitably, when he tried to merge his change back, it got a conflict. And what he did was, to check out a fresh version of the branch, then to COPY AND PASTE all the files in his directory into the new checkout and then committed the change WITHOUT telling anybody.

(Now I can tell you how this is so wrong at so many levels, but you probably get the idea)

Another similar incident is when an test suite wasn't passing on a specific machine for a branch, which turned out to have an older version of java that the branch no longer supported. And when the dev who owned that part of the product had specifically instructed him to upgrade to the required jdk. But he, instead, reverted the change the deprecated the version to get his test suite passing, and obviously we did not notice that until very recently.

When we (another dev and I) confronted him about these, instead of acknowledging the mistakes, he claimed he "did not do it on purpose.", while pulling his manager into the conversation to defend him. (At our organization, devs and qa teams report to different managers)

QUESTIONs (sorry for the long rapport)

Should I bring this up again to my manager, given his manager was already informed? (I'm concerned it'd feel like "going behind his back" to retell the story to someone else) But if I don't, it just frightens me to think of any future damage that could take place.

What is the most polite way of asking him directly "What else have you done? Please tell us now rather than later!" (I'm younger than him, which is why I've had some reservations)

  • 5
    Initially I was sympathetic but if QA can change source code then that is dev department problem.
    – paparazzo
    Feb 16, 2015 at 21:31
  • 1
    Why is it our dev dept proplem? We don't forbid them from accessing dev code ... doesn't mean they should change it ..
    – JasonK
    Feb 16, 2015 at 22:27
  • 4
    Really QC can change source code and that is not a dev control problem?
    – paparazzo
    Feb 16, 2015 at 23:14
  • 2
    QA/QC should have read and check out permissions, but not check-in permissions. If they want to debug to find a problem, fine, but then give it to a dev to check-in.
    – mkennedy
    Feb 17, 2015 at 17:55
  • 2
    QA/QC is sometimes responsible for writing automated tests, so allowing QA/QC to check in code isn't necessarily a dev dept problem. However, allowing people to check in changes and not have someone from the development department know exactly what and why things were checked in (preferably no later than the next day) is a development department problem. Also, it seems like peer reviews aren't part of the process. If formal reviews aren't held, at a minimum there should be an informal review by at least one person for everyone's changes.
    – Dunk
    Feb 18, 2015 at 21:28

2 Answers 2


There's no straight answer to any question like this, but I'd bear the following in mind before running to his manager

  1. Any new hire adds "negative velocity" for a while. Even the best hire will take several months to get up to speed. Just because he's not useful yet, doesn't mean he won't be, or that you should expect him to be at your level yet.

  2. Training is almost never a bad idea, and doesn't have to be formal. If he isn't doing things the way you (personally or as a company) want, train him. Don't tell him off, just suggest an hour or two to explain how you do things.

  3. On which line: blame is a bad idea. for one thing, he may not know he's doing anything wrong, and for another it is the beginning of a bad relationship. Don't approach it as "You did xyz wrong", but as "We have very specific procedures for xyz which you may not have come accross, could I take a few minutes to run through them with you?"

  4. Speaking of which, you do have written procedures, don't you? If not, write them, get them approved and make sure everyone knows where they are! If things are being passed on by word of mouth, it's far too easy for someone to accidentally or deliberately miss things. If they're written down, nobody has any excuses, and if this turns out to be a lazy dev rather than a couple of mistakes, your complaints will carry much more weight. Suddenly it's not a difference of opinion between employees, it's one employee breaking approved procedures without authorization.

  5. Assume good faith. People misunderstand things all the time. Without our domain/product knowledge*, even the most technically adept new hire is always going to miss one or two things which seem important/basic to us, but which their brain (trying to learn everything) filtered out as unrelated/optional detail. Never assume malice where incompetence would do.

So to directly answer your question, I'd go to his manager again... after explaining your procedures and only if he doesn't change what he's doing. Give the guy a chance.

I'd mention it to your manager if you think there's a risk that the test procedure has been circumvented, or that there's a risk (commercial or health/safety etc) to somebody or the company. If you think he may have just messed up the version control, I wouldn't make a fuss unnecessarily: it shouldn't do any permanent harm as long as testing is followed properly, and should be easily found/traceable... but if there's any potential risk to the company or to any person, always mention it. Particularly if you work in healthcare or similar.

And no, do not ask him "What else he's done" - you're not his manager, you're not in any position of authority, it's confrontational and it's not your place to do so. This is a decision for your manager to make, your decision is whether there's any risk he could have caused which your manager needs to know about.

  • 1
    3 months is a reasonable amount of time for someone to be up to speed. If he's still struggling, then it may be time fire more serious measures.
    – Eric
    Feb 16, 2015 at 13:17
  • 1
    That depends on seniority in the role, I wouldn't expect a new graduate to be flying at 3 months. A senior consultant, sure... But there's no fixed line
    – Jon Story
    Feb 16, 2015 at 13:31
  • The post is about a mid-level person. I would expect even a new graduate to be comfortable with the standard practices after 3 months.
    – Eric
    Feb 16, 2015 at 16:31
  • 3
    @Eric, 3 months is "enough time" in an environment where there is the right amount of communication, training and opportunity to practice safely. The things that Jon has outlined are really valid points that should be tried/addressed before even starting to consider dismissal.
    – teego1967
    Feb 16, 2015 at 19:38
  • Jon, thanks for your thoughtful answer. I'd just like to add a few comments. I don't think the issues have much to do with his understanding of our product or "the way we do things here", for tha matter. As you can see, the mistakes he made indicated something much more fundamental, that is, basic software-engineering pratices (version-control, code review, etc). Although I'm not sure what could be the cause for his other mistake, in which he intentionally or not, did the opposite of what he had been instructed to.
    – JasonK
    Feb 16, 2015 at 19:53

Well the answer may well be :

"he's new and needs more time"

Given we're in month three, he should be getting to grips so it is a concern, especially given he's done something really out of character for someone in his role (trying to avoid an answer too specific, we like answers that can be applied to multiple industries).

You've been to the manager, OK. I would go to the manager again and explain the issue and your continuing concerns, but I would suggest that I would have a word with the guy about his actions, and how to remedy.

It doesn't matter if the guy is older than you, you have more experience within your company (and I'm assuming you are on a similar level).

So, go the the newish hire, explain what you have observed, and that this has caused a concern (his actions will have likely undermined work you and colleagues have been doing, so you can support this). I'd probably avoid mentioning you've escalated it unless he is unreceptive.

Talk to him about WHY he has done what he did, if it's down to lack of knowledge then SHOW him how to do it right, and feed back to the manager he still needs more knowledge transfer. If he thinks his actions are acceptable, still show him how it's done at your company, then feedback concerns to the manager (companies have trial periods, often up to 6 months/ year for just such a reason). Offer to be there to help if he gets stuck, the imposition will be less than unpicking further mistakes, and you can gauge if this is just a one-off, or a bigger problem. If you gain his trust the time will likely come to discuss any other "issues", but be sensitive.

If he learns, great, he'll be more productive (and hey, you'll look good to the boss as well), if not, you can raise concerns safe in the knowledge that you have tried to be fair, but it just isn't working out.

  • You might have misread my question. His manager DID know of the issues. MY manager (which is different from his), on the other hand, is not.
    – JasonK
    Feb 16, 2015 at 19:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .