Student not understanding explanation the 1st, 2nd... and 8th time I am working for a company, and a target for this year is to increase the level of CS knowledge among the staff.
The company does mostly engineering stuff so the people come from an engineering background, they might have some knowledge of programming, such as what is a variable, control flow, etc. but classes are virgin territory. That is kind of the average level there.
Me and a few others with knowledge (formal CS background, working in the AI team of the company) were assigned to increase the level of knowledge in the office. Basically each mentor was assigned a handful of mentees and the mentor decided what to teach and what exercises to give etc. to improve the algorithmic thinking and C++ competency.
I paired up with a colleague and we pooled our mentees. For some people it worked great. People went from variable names like a, b, ok, x and thousands of lines of copy-pasted code in main() to actually nice variable names, class hierarchies with abstract classes/interfaces, clean code to the point where (almost) no comments were needed, etc.
I tend to think that we are doing something right, especially since my colleague and I also teach at our university (which is among the top3 in the country), create training materials, held multiple training sessions on different subjects, regularly mentor interns with great success and also did volunteer work tutoring middle school children in introductory programming, with parents at the end asking us to continue the tutoring for money. So we are not exactly new to teaching, and our experiences seem to indicate that we are not bad at it either.
However I have a student that doesn't seem to grasp some concepts at all even after multiple (&gt;5) explanations using different methods and analogies. Will also forget basic techniques in the span of hours.
For example he needs a copy of a vector&lt;int&gt; (C++). He will do the old song and dance:
vector&lt;int&gt; copy;
for (int i = 0; i &lt; my_vec.size(); i++)
    copy.push_back(my_vec[i]);

We told him several times and explained why it was better, faster, prettier to just do:
vector&lt;int&gt; copy = my_vec;

He always forgot to do this for his homework until we made his homework to clean up his code and implement a single utility function.
He cleaned up the code, then in that utility function went right back to the for method. And when we pointed this out it took a couple of minutes and helping questions for him to realize what he did wrong.
Another example is that as a first project the mentees have to implement a basic Hill Climbing algorithm.  This project has been given in June. We have people who will begin implementing Genetic Algorithms this week and it won't even be hard for them. People who have started from variable names like a, b, ok, x and thousands of lines of copy-pasted code in main().
Without precise instructions he's barely able to create functions like with 1-2 rounds of review &quot;you get a vector of vectors as an argument. compute f on each of the vectors and return the index of the first vector where the value of f is above some threshold x&quot;.
The hill climbing algorithm was explained exactly 7 times to him in different ways, with both me and my colleague actually spending time to come up with new analogies. Every time this mentee will enthusiastically say that this time he understood better than all the other times and then do something like just compute the best neighbor of the starting point and return that neighbor, and then name the function firstImprovement.
The problem is that this person does not appear disinterested. When we explain things he nods and looks like he is concentrating and that makes us try again and again because it looks like he's trying too, but the issues above have been a thing for months. On a problem as simple as Hill Climbing.
Has anyone ever had such experiences? Any advice? Or any other site where this question would be appropriate?
Maybe you are stressing things of minor importance. You gave us two examples.
vector&lt;int&gt; copy;
for (int i = 0; i &lt; my_vec.size(); i++)
    copy.push_back(my_vec[i]);

sure is lengthy, and probably also a bit slower than the C++ expert version of
vector&lt;int&gt; copy = my_vec;

But it does its job and is readable (while e.g. to me as a Java guy, I'd struggle to remember that the assignment operator here does a copy of the data structure). And, regarding performance, we all know that in at least 90% of all cases, it doesn't matter. And if it matters, I'd search for a solution where the vector doesn't have to be copied at all.
Regarding Hill Climbing: During 40 years of software development, I rarely ever needed hill climbing, and I've been working in algorithm-sensitive areas. So, unless your students' jobs need things like hill climbing regularly, think of exercises better matching their everyday needs.
To summarize it: You're not preparing that guy for a PhD in computer science (which most probably isn't needed for his job and out of scope for him as well), but giving him some tools to improve the software engineering aspects of his work.
With this guy, I'd switch from a fixed curriculum to practical reviews of production code, concentrating on readability, robustness and structure, looking at code written by different developers. If he struggles there as well, then have a nice, deep talk with him.
EDIT, as requested by OP
Regarding the &quot;nice, deep talk&quot;: If that guy really struggles hard with basic concepts of software engineering, then he'll probably never catch up with the others. That mindset of specifically-structured thinking is not given to everybody. So, he should understand that his talents might be somewhere else.
He can choose whether he wants to pursue his career as a software engineer, with the risk of always staying behind all the others. Or he can find a different role in the team where his talents shine. It might be he is good at understanding the customers' way of thinking, or at hardware development and interfacing, or UI design, or management, or quality assurance, or whatever. Software development teams need so many roles besides coding, there might well be tasks where he can shine.
That's what I'd talk about with him. You should try to make this a positive experience for him. Maybe you already observed some of his talents, so you can suggest some migration path. For that talk, interpersonal skills are most important.