1

My company has basically 3 tiers of data scientists: junior, associate, and senior. I am myself an associate. Juniors should be under the supervision of another employee, associates should be able to take a project on their own, and seniors have additional responsibilities beyond the projects they are working on.

3-4 months ago, we hired a new employee right after they finished their masters in data science from a reputable university (they had experience before the masters though) as an associate. I was tasked with transferring this employee my workload as I picked up a new project (along with helping them any way I could). During these three months, this new employee has shown severe lack of understanding of some basic concepts.

  1. Not debugging their code, if it runs then that's it.
  2. Not checking what the transformations they are doing on the dataset is producing.
  3. No testing of edge cases (check point 1 and 2).

When asked to debug their code or test the edge cases, etc. They have shown they really have no skill in doing so, I recall for most major problems we had with this project it was me who always found the bug/problem, and came up with a solution. One issue for example is not checking the order of the columns before feeding to a trained model, this has happened more than once, and even after the issue being brought to light. Their problem is less of being fresh (bad code for example, which does not apply to them) or how to use a framework, and more of something that I can't put my finger on. It seems they know the machine learning part but nothing of everything else.

I have already tried to gently bring up these issues as a matter of mentoring and guiding them toward better practices. But the fact remains is that I still don't trust their work and I do review the modifications to make sure they contain nothing too obvious.

I am supposed to be helping them, and that doesn't bother me. But I will have to let them do things on their own very soon, but their work will be impacting my work (think of it as one project's result can be used in other projects). I feel they are inadequate as an associate, and would be perfect as a junior position. I am torn between staying silent, talking to them, or bringing this up with our manager.

  • Welcome new user, in general this question (it's the "colleague is rubbish!" question!) is asked many times on here. I can't be bothered finding a duplicate specifically, but you can reads many ideas on it on here! – Fattie Apr 24 at 14:07
  • 2
    Possible duplicate of How should I handle an incompetent coworker? – BSMP Apr 24 at 14:10
  • Why would you debug working code? I understand that it is critical to test code to ensure that it is doing what is expected but to call it debugging is just confusing. You should also remember that how things work in the academic world can be different than the commercial world and adjusting may be harder for some. – Joe W Apr 24 at 17:00
10

I was tasked with transferring this employee my workload...

Since you were factually tasked (by your boss) with giving the new person work, then it would seem, you will have to bluntly and factually explain events on that project to your boss.

  • It's been 4 months, surely your boss has asked for progress reports?

  • Don't forget, "it's not high school". Simply, bluntly, clearly, and dispassionately explain the situation

  • As always stick very strictly only to specifics. Do not make ANY statements "about" the person overall. Simply state factually the issues relating to the specific file or item

So for example do not say "Steve is incompetent" or "Steve never tests".

Do say "Steve has not been able to port speedy.cpp" or "Steve's output module fails with the v2 input module".

That's really all you can do.

It is awkward that you are not the person's boss but you have apparently been tasked with supervising him on a project - that's always a tough situation.

  • They did ask progress reports, but it is based on my own previous work (code I have written), the point I made about fixing problems myself applies to this portion as well. Anyway, thank you for the advice. I will think about this and make a decision soon. – Zer0k Apr 24 at 14:14
  • 3
    Why did you comment that this is surely a duplicate, say you can't take the time to find a duplicate (which should be quick, right? Since there are so many, as you say...), but then proceed to answer the question yourself? – maxathousand Apr 24 at 14:16
  • 1
    @maxathousand The internet is a wonderful place isnt it? ;) I was going to post a similar answer myself so it was, at least minimally, a useful exercise... Fattie gets 10 points from me for saving me the trouble – Smitty Apr 24 at 14:17
  • @maxathousand - why did you bother posting all that? :) on this site it's totally normal to answer a question, even if it's a dupe or you mark it as as a dupe – Fattie Apr 24 at 14:45
  • @Smitty - GMTA dude !!! :) – Fattie Apr 24 at 14:46
1

I am torn between staying silent, talking to them, or bringing this up with our manager.

Do none of the above.

What you were tasked to do is to transfer your workload to this employee and help them if needed, which is exactly what you have been doing. Continue to do this to the best of your ability and let them eventually do the work on their own. You cannot hold them on a leash forever!

but their work will be impacting my work (think of it as one project's result can be used in other projects).

This can be the case with any employee, not just this specific associate, and should be dealt with the same way regardless of who worked on the project you are depending on. If their work does not fit the criteria for the project, you let them know so that they can correct it. If your boss asks why things are being held up you let them know that you are waiting for X to correct Y and provide the documentation supporting this.

I feel they are inadequate as an associate, and would be perfect as a junior position

That is up to their manager to decide, not you.

0

I was tasked with transferring this employee my workload as I picked up a new project

For me it sounds like your responsibility is to make sure new hire is capable of performing some (previously yours) tasks.

Think about it as a software project:

  • you have or create specification: here tasks you need to transfer (A, B, C, D...)
  • you develop: run pair-programming sessions with the new hire, explain, give directions, share links, write documentation etc
  • you write tests: "Hey, new hire X, let's walk through task A so I can see whether my training was sufficient. Show me how you would do B and C"
  • you provide report to the customer, your manager: "Hey, manager, I worked with X on tasks A, B, C. There are still some issues with tasks C and D, I was trying to explain them for two weeks now!" Then your manager (your customer) can decide whether to drop some features ("ok, forget about C, it's your task forever. And D is useless anyways") or invest more, or whatever.
0

For someone that's mid-level, which is essentially what your associate level is, most of this is fine.

Not debugging your own code is a fairly junior behavior, but the rest of it sounds like something someone would do until they know they're not supposed to do that. Stop expecting Senior performance out of a mid-level.

Testing edge cases is definitely not something a mid-level would be doing. Do they even know what the edge cases will be? I hate to be the one to tell you this, but a college degree does not make someone good in the workplace.

This person is a mid-level associate. You should be mentoring them instead of complaining about their work being lower quality than yours. Also, if your quality of work is this much better than theirs, you should either get a promotion to Senior, or job hop to a different company where you can be Senior. It sounds to me that you're already doing Senior stuff since you're essentially giving the new hire code reviews for no legitimate reason. Correcting numbers is someone else's responsibility. This is the only thing you should bring up with your managers.

Aside from that, you have to recognize that Data Scientists are not Software Developers. They're Data Scientists. Your hire, knows Data Science. Stop expecting them to know Software Development fresh out of school. Data Scientists not writing code very well is not an uncommon observation. Give them time to learn.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.