Linux founder tells Intel to stop inventing 'magic instructions' and'start fixing real problems'

T wrote:

Also, the recent computer science grads I have come across make my
head spin. They know virtually nothing about computers or
programming. Seriously, they barely know what a mouse is. And they
are in debt up to the asses with student loans.

We'd get CSci university interns to help in Software QA. They were
trained to follow instructions, and nothing more (no intuition, no
imagination, no motivation). We had test procedures, but some were just
templates that had to get filled out when new features or changes showed
up in the software. They got the same training (classes and
instructional CDs) the rest of us got. The interns just had no grasp of
how to dig into software to test it, and how to document their testing
despite having an detailed template but which they had to fill in during
and after testing. Way too much handholding. The interns that got the
retro tests (for old functionality) where the procedure was completely
written did okay, because they didn't have anything to do but read
instructions. Yes, they were interns and had to learn, but they were
like 1st-year students instead of near-grads. No initiative, no talent
for testing, and poor writing skills.

I remember someone remarking that college isn't about training their
students for a particular job. It's to train them on how to learn. Not
evidenced by the interns that we got. I think we used interns for 6
months: the contract length. Never again thereafter. A failed
experiment trying to up the count of QA testers to shorten our testing
schedule which always got squeezed by Dev delivering late and Sales
arranging early deployment to customers. We ended up outsourcing some
retro tests (fully written on old functionality) to the Dev and Field
Support groups if some were available. Once we explained our test
scheduled and Sales wanted it shorter, we said either we don't test all
the old stuff and hope it works, or we get helpers to make their
schedule. Dev was hard to get, so we used Sales to pressure them.
Field Support was easy to get unless they were at a job site, plus they
were experienced on how customers used the product, not how Dev thinks
it should work per the Functional and Engineering Spec docs. Eventually
I wrote scripts for all the retro tests that did the setup, checked
dependency on the results of other tests, and logged results or alerted
on failed tests. The scripts became the tests with the doc template
just outlining what the scripts did.

Of course, our bad experience with interns could've been with the ones
we happened to get at that time. We paid our interns minimum wage.
They weren't allowed overtime (great for them that they could quit by
the clock while the rest of us were goal-oriented and left when we got
to a stopping point that provided a good resume point). They only
worked half days since they were still going to school. They had the
option to become employees at the end of their internship. They got
experience and a salary. We felt it unfair to exact manpower from
unpaid workers. They were [supposed to] help us, and we wanted to
reward them. We didn't care FLSA considers interns as not employees
which means interns don't have to get compensated
(https://www.dol.gov/agencies/whd/fac...a-internships). We
were, um, lenient in our report to the college for our assessment of the
interns. We still wanted them to get academic credit.

There were no later experiments using interns to better gauge the
usefulness of that workforce source. Before the contract ended, my
manager asked for reviews on their performance. I told my boss that I'd
write scripts to do the work of the interns. I didn't get overtime, but
I did accrue flex time that I could add to my PTO. I took some long
vacations or extended weekends when QA wasn't in prep or crunch mode.