New hire (closing on 4 months) is inadequate, and I am torn between telling my boss or just keep quiet

Question

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.

Answer 1

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

Since you were factually tasked (by your boss) with giving the new person work, 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". Explain the situation: simply, bluntly, clearly, and dispassionately.

• You must stick strictly to specifics.

• Do not make ANY statements "about" the person overall. Simply state factually the specifics

Absolutely do NOT generalize or assess:

So for example DO NOT say "Steve is incompetent" or "Steve never tests" or "Steve's programming is bad".

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

That's 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

The scientific method was formalized in the 1500's by Sir Francis Bacon; yet even in the 20th century there were top-level scientists that didn't use it properly (for example: a bit of fun reading about N-Rays)

The reason I say this? Because people are often trained on the specifics - but not the strategy/algorithm for how operate. Those N-Ray scientists clearly knew a lot about physics and the mechanics of experimentation... yet it wasn't until Robert Wood came along and actually worked hard on falsifying the hypothesis that the actual scientific method was in full usage. Simply put: the N-Ray scientists were trained on the specifics, but not the deeper strategy/algorithm for how to do their job. Instead of trying to convince others of their hypothesis, they should've been trying to prove their own theory wrong.

And simply put? That's likely the problem your coworker has. They know a lot about the specifics... but nobody has actually trained them in the actual strategic approach to doing their job.

This isn't actually unusual. Looking back at college, it definitely didn't prepare me for a programming job. They didn't teach me how to debug code, or to look for corner-cases for how things might fail, or how to create tests to verify code was working right - or any of that. Sure, I knew all sorts of specifics for computer programming, but the actual strategic approach for actually being a professional developer? Not a chance.

In short: since you're responsible for training them, you might need to consider that this training isn't just "Projects our company does", but also "Here's the strategic approach to being a data scientist". How do go about architecting code. How to imagine corner-case tests. How to validate the end result. Etc, etc, etc.

If it helps, I recent had to do this with one of our junior developers. When some testing came up short in spotting problems and they explained the situation, I realized there was a critical and fundamental gap in how they understood testing to work. Instead of fixing the immediate problem, I set up a quick briefing session to go over the general process for doing tests. I helped them learn the strategy behind testing, not training them on this specific testing incident.