When mentoring individuals, teach clean coding and simple/effective thinking or let them do it their way? I have a background of 20+ years professional coding, but my heart is really in teaching. About three years ago, I started tutoring ages grade 6 through adult in coding topics.

introduction to coding in Python or Java
AP CS A help
for independent students, long-term projects like an role-playing game
competitions (CodeWars, US Computing Olypiad)

I like my code to be simple and comprehensible, with the feeling of confidence that it works... a simple thought process by which I can understand (and anyone can understand) what my code does.
So I teach that. I teach breaking things into encapsulated sections, I teach testing and debugging techniques.
I also teach how to make use of your brain better and work smart, not hard.
Several of my students have been with me for three years, and they've all grown a lot, and they're a pleasure to work with because they picked up this clean thought style.
But... is this the only approach to teaching? Is it the best approach?
Keep in mind that most of my students aren't going to be professional coders. Keep in mind that I'm a bit obsessive and probably could stand to lighten up a little and let my students work in whatever way they would like.
Recently a student came to me, interested in doing US Computing Olympiad problems. The thing is, he had barely learned anything about coding. He had a little Java knowledge, but was weak on creating classes and really didn't even understand how to use functions. I suggested that we work on fundamentals and he balked - from his point of view, you didn't need functions to solve these problems, and he had searched the web for other solutions and none of them used functions. (All the code is in main())
At first I figured he was in for a disappointment when he realized these problems were over his head. Well, shiver me timbers, he has solved about 10 problems so far using this technique. I can't even figure out what his code is doing or why it should work.
He doesn't do testing even! He just submits his code and keeps tweaking it until it passes the online judge test cases.
So I finally said that consider it a limitation on my part, I'm only really able to work in my normal method and that if he really doesn't want to do things my way, he has to find a tutor who can work with him like this.
Finally there came a reason why he's interested in me and my methods - he did see that it would be useful to test and debug, and he did find a few USACO solution online that used functions and classes, so now he has a mild interest in learning that from me.
I guess what I'm asking then, is when you are mentoring someone, how do you negotiate this balance between &quot;teaching them clean work&quot; and &quot;let them work in the method most natural to them&quot;?
As someone who has now taught CS for many years, let me first reassure you that teaching clear, clean coding is entirely worthwhile. I think this is especially true for those who will not go off into software professionally, because editing, and being able to express ideas in a clean, clear manner is a skill that serves people well in any field.  (I've written a bit about my approach to teaching good coding style before on this site.
Now, USACO is something a bit different. These competitive programming situations are designed for coding speed, program speed, and correct output.  You get no points for maintainable code, clear thinking, or reasonable variable names.  These contests can be great learning experience as long as the student understands that they are getting intense (and good!) practice on only one small piece of a larger puzzle.  I would definitely try to contextualize this for the student, though I caution you that you may never win over this particular student. He may have already become somewhat set in his thinking.
Here's something silly you can do to attempt to demonstrate the value of clean code to the student: take some nice, clean code for a USACO-style problem and introduce an obvious edge-case bug that crashes the program (an array out of bounds or somesuch).  Refactor it to give it USACO-style names, like m and pf. Shove everything into main.  Make sure that there are no strings to make obvious what the program is supposed to do.  Reverse loop styles to make them less appropriate (i.e. switch for and while).  Screw up the indentation. Generally make a mess of it.  Have fun!
Print out your spaghetti onto physical paper and ask the kid to find the bug. You can even tell him the type of bug. Tell him he had 10 minutes.  At the end, ask him what the whole thing does.
Then give him the original version, with clean names, good use of functions, comments to explain what the functions do, and generally clean design. Ask him to find the bug again, and ask him what the code does.
Now tell him that he's just been hired to maintain hundreds of thousands of lines of buggy code that someone else made.  If the code all looked like the first example, how long would he give it before he quit that job?