It really depends on how long you wait before making the students sensitive to these issues.

Wait 6 months or 1 year, and you've given them time to gather sufficient experience for motivating a more mindful way of working.

Wait 3 years or more, and you've just taught them bad habits.

I'm tired of interviewing candidates who were supposedly trained extensively in programming, asking them "how do you approach making quality software?" and hearing the usual "oh, I indent my code and write a lot of comments" as an answer.

I work with a ton of people from Grandes Ecoles and while I think they're generally great coders, certainly as much so as if they'd spent their whole education madly typing as fast as humanly possible, as juniors they're not much better than the "indent and write lots of comments" level.

I've been to a "regular" university and I'm pretty sure I said some variant of "I write lots of comments" w/r/t my code maintenance approach in a very early interview. I could have written any algorithm you gave me -- but I had no idea what maintaining an application with users entailed.

My experience is you can't really "teach" writing maintainable code beyond just having people fix bugs for 6 months in a million-line codebase that's reasonably well written.

It sounds like you are expecting junior hires to be senior, instead of training them. The average elite computer science student spends 3 years learning computer science before they start building professional programs.

It depends on the curriculum. At the last place I studied Computer Science, the department was led largely by Matthias Felleisen and Olin Shivers, and the first book they require reading is How to Design Programs: https://htdp.org/2018-01-06/Book/part_preface.html

You could write 100% functional code that handles every edge case you could think of, and you could still get a B- on an exam for not using the 'Design Recipe.' While frustrating, the students do emerge as 'junior SWEs' with a grasp on how to design organized, efficient, and complex programs themselves.

Meh, I've looked at my code when I was just starting out, and I can still trace my thought process and reasoning behind my code. Sure, there's a lot of mistakes and bad style, but I can tell that even in my first efforts I understood organization and design. Beginners shouldn't be held to the same standards as professional developers, but some guidance in terms of code quality is a good idea.