> the 2 hires ended up in disaster with both quitting within 6 months. I am trying to be introspective and understand what our group did wrong

Leaving aside perceived quality of work, can you give more details about what happened, and how your employer interacted with the new hires? It will be difficult for anyone on HN to give accurate input that is not just speculation without more information.

E.g.

* did they actually quit or were they fired?

* did they give any explicit reasons for quitting?

* did they voice any concerns about not being happy in the role to colleagues/management in the months before quitting?

* was there conflict between the new hires & colleagues/supervisors?

* did they get job offers for more attractive jobs?

* did management share your concerns about quality of work being produced by the new hires?

* were the new hires on some kind of performance plan or otherwise notified by management that they were underperforming?

* what hiring process does your org use? Are candidates required to write code during an on site interview?

I feel your pain. I'm working with a physics PhD who's now doing software development and he's the same. Sloppy desk, sloppy code, sloppy abstractions. He also has the habit of talking over me and is not at all interested in my input, always plowing on in the wrong direction.

Unfortunately, I work in an academic setting and that seems to give someone with a qualification in an unrelated subject more authority. I feel a little powerless to influence the way we do things.

I've made peace with the fact that this guy is never going to change, but will eventually move on to something else.

> Many PhD students are not ready to work in the "real world"

There are exceptions, but this is largely true.

I would go a step further and suggest FAANG are easier environments for ML PhDs because they go into research groups like FAIR and Google Brain, where legitimate software engineering (and general professional practices) aren't required. In other companies -- i.e. ML startups -- those training wheels need to come off, quickly.

I’d always test for the role and not rely on a PhD implying they can do the job. Unfortunately that means a coding test, but it can be short.

What did you do to test they had the experience you expected? What is your hiring process? How did you make your expectations of them clear?

> In both cases, the new hires had sloppy desks, wrote sloppy code, and presented horrible slides with lots of mistakes (units missing, illegible axes, etc). Our undergrad inters faired a lot better than these two.

I don't think it's worth it to overgeneralise. You shouldn't generalise about senior developers with a decades of experience either because you don't know what they spent their time focusing on.

From personal perspective as well, it can be really demeaning when people try to attribute any oversight or lack of experience you have to you having done a PhD. Each PhD is radically different. Some do very concrete research, others do very abstract, others present a lot, others very little, some code a lot, some don't etc.

This is a failure in your hiring process as well. How are you vetting your candidates? Are there gaps in your process that are allowing people who are a bad fit through?

Where I work, we had a PhD leave within 6 months. She was not able to deal with the lack of structure. Frankly, neither can I, but my motivations are a little different from hers. The team leadership could have done better in focusing on specific deliverables and letting her gain confidence through small victories before leading her down an open ended death march with few tangible criteria for success.

I wouldn't expect people who are genuinely bad to work with in an academic research lab to be good to work with in an industry research lab.

On the other hand, I wouldn't expect PhD students (or any new hires) to be perfect out of the gate. Assuming the content (algorithms, approach, analysis) was correct and the main problems were with code style and presentation, perhaps they needed to be instructed regarding proper code and presentation style and directed to follow that instruction.

Messy desks are probably not the root cause of poor code or presentation.

PhDs are often singularly focused (although that can change over time) and it seems likely that your priorities were not their priorities. They probably do very well in larger companies because they can a) find a niche that fits their interests and b) there are more non-PhDs to pick up the slack.

This is very known issue across the globe with broiler PhD's. They will never be ready to get down to real job.

This isn't a PhD hire problem, this is a hiring someone out of school / college and not giving them enough structure to succeed problem. It's just you have higher expectations because they did great at undergrad / masters.