[consp]

I've been an assistant on 1st to 3rd year bachelors courses in CS in the Netherlands (basic OOP, Software Architecture and Algorithmics like courses) and probably seen many of the types of copying and forgery. I can concur that most students don't really understand but just regurgitate what has been said even at Academic levels. On some Examples of what i've seen which sometimes leads to the types of interns you give:

- 1-on-1 copy paste, change the name: Easily caught by looking, no need for anything else. These will fail.

- mostly copy/past, changing names some locations: Easily caught by letting them explain the workings of their code, they will always fail. I've had one lazy student who could easily explain while copying but was just lazy out of hundereds. These can slip through if the course is understaffed or badly designed.

- Hand written assignments: Mostly parallel working when individual required, I'm not agains cooperation but mostly you could see that one student got the exercise right and the other just copied him/her and usually lacks details which are in the other assignment. It is very noticeable if they copied it due to similar layout and textual form. If the assignment is too simple this is harder to detect, but quite easy in algorithmics courses. These are far harder to detect and prevent, though individual checkups (at random) are a good way to test the true knowledge acquired. Needs lots of staff which is never there since 'budget cuts'.

The biggest problems are the group assignments as noted in other posts. They are hell to get rid of people as failing one usually means failing all even when some didn't perform. The usual trick to get it right is to either fail the entire group and give them an individual assignment to filter out the incompetent or to do the same thing on an individual basis. The problem is that you actually have tangible evidence otherwise it is very difficult, though commit logs is a start. The people who should fail and get through are at least some of the 95% you mention.

The 5/100 ratio is not odd/off in my perspective. You describe the top 5-10% (which are good and you want at your company) vs the next 30-40% which are average and simply make things work but lack initiative or knowledge vs the rest which should look for another job since these applications usually contain at least some amount of incompatible applicants.

Consider that if you pay peanuts, you get monkeys so that also might be the problem.

ps: IT-managers without proper IT knowledge (and yes I mean the basics) are the same thing as a CEO who is unable to speak in public: Nice decorations on the office floor but utterly useless in practice.

[cavanasm]

I've had group assignments where group review had the ability to fail an individual member if they were a non-contributor. Every project I had with that professor had at least one person in my group who was a non-contributor (and was outed by the group in review, resulting in a failing grade).

[komerdoor]

Yes. I can imagine this to be common among all levels, but the interns I am guiding are mostly from HBO (between college and university level) and some MBO (college level). Did not expect it to be the case at university level as well.

I really do not understand why so many people want to get into IT if they are not really interested in it. Job security probably? Not for the money I assume as in the Netherlands the average salaries for even a senior programmer are pretty low. +/- EUR 20,81 an hour before taxes (+/- EUR 12 after taxes).

Sources:

https://www.loonwijzer.nl/home/salaris/salarischeck#/ (search for Application Programmer)

Anecdotal evidence of many programmers around me that I've met in the Netherlands.

[marsRoverDev]

RE the group assignments, my university quite successfully dealt with this by introducing a scaling factor based on peer assessments within the group. This scaling factor was strong enough to allow a group to fail one member if they received poor enough grades. Failing one member tends to boost your own grade as well, as the assumption is that you ended up having to pick up the slack.

I did three group assessments, and out of those three failed two students with the help of my teammates, by co-ordinating our peer assessment. This peer assessment does not become public until grades come out, at which point they can be disputed. But 3 vs 1 usually comes out in favour of the group.

[douche]

> I did three group assessments, and out of those three failed two students with the help of my teammates, by co-ordinating our peer assessment. This peer assessment does not become public until grades come out, at which point they can be disputed. But 3 vs 1 usually comes out in favour of the group.

This is, inadvertently, fantastic training for sociopathic stack-ranked office politics.

[lol768]

> RE the group assignments, my university quite successfully dealt with this by introducing a scaling factor based on peer assessments within the group.

This is something my university has done, but didn't implement quite as well. I think the key here is making it completely anonymous (ideally filled out online individually) because otherwise objectively assessing a group member's performance in front of them is difficult.

With that said, I think I'd still find it hard to outright fail a group member via these means unless they literally put zero effort into the group project - it seems a small thing to threaten their entire degree over.

[Zoneman]

I failed a group member over this. They did put a small amount of effort in, but the problem was that the parts of the project they agreed to take on ended up having to be done or re-done at the last minute. If we had just known he was going to do nothing, we at least could have planned for it. In the end, putting in that small amount of effort actually hurt more than putting in none at all.

[b0rsuk]

It may be a controversial opinion, but if a lazy student can explain a solution or an algorithm, it's not as bad. In the end, he/she understood the problem. Chances are he's a quick learner and will be effective at googling solutions off the net.