Out of the 100 IT interns every year there are usually about 5 that know more than only the basics. This has been a consistent pattern I've seen over the last 4 years. It does not matter what level education they are having. Many times I even had to explain what functions, conditions etc. are while they somehow still managed to get average grades for classes that require this knowledge.

I really do not understand how so many people manage to fool almost everyone for so long. It usually ends up being the case that I (because I get hired to guide them) or the about 5 good interns that are there do most of the work for them. Of course some of them still manage to setup a Wordpress website or write some simple HTML. Just enough to impress the company owners.

Another consistent pattern (as mentioned before) is that very often their end-goal is to become an IT-manager. These are usually the better talkers.

Of course this is all anecdotal, but I've asked many other people that guide IT interns and they noticed the same thing. Probably something that can be researched.

Now I may seem like the one that thinks very highly of himself (by reading my own text I can understand why it may look like this) and this is exactly what makes this difficult to explain to the company owners when I notified them about this. They just do not believe the 5 to 100 ratio and think I've some difficulty accepting people.

- 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.

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.

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.

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.

To me, it's quite simple. Lack of teaching the fundamentals of programming. CS programs want to teach object orientation in first year CS. How can you understand object orientation and complex data structures until you've learned what a pointer or structure is (C code, yeah)? How can you understand a pointer unless you have a basic understanding of the machine, and in particular, how simple variables are stored in memory.

This is the boring stuff for professors and administrators of a CS program, but an absolute if you want to produce quality CS graduates.

Otherwise good students get lost in their first year of CS, which is the real shame here, given the shortage of CS talent. I advocate for better teaching of fundamentals, preceding more complex topics in computer science. Without it, we will continue to see CS grads fall down in the work force.

Speaking as someone who has spent considerable time in front of first-year college CS classes, attended SIGCSE conferences, and applied this in practice: trivially. Your "pointers-first" bias has long, long been debunked. Brown, Stanford, VT, and other CS departments have had fantastic programs teaching via OO-first methods for going on twenty years now. Studies of students taught this way have determined that they learn stronger design skills earlier, and have a greater focus on the problem to be solved rather than the machine being built. (At first: this is emphasis only on which skills are taught first.) Anecdotally, giving students a framework in which to understand why they're doing what they're doing early is hugely important. Then, a few semesters in, they do the deep dive into the minutiae that C, assembly, etc. afford.

This, in turn, is really no different than the era of pre-C++ CS instruction. Prior to C++'s big wave of popularity in the 90's, C was largely considered to have too many sharp edges for first-year CS instruction. Languages like Pascal, Modula-2, and even some Lisps were preferred to get basic algorithmic and data structures concepts across, with C generally relegated to the third semester or so. I'd call the common theme here "algorithmics and abstraction first" pedagogy.

C++'s burgeoning industry appeal eventually became a siren-song for many CS departments, who dropped the "not C first" pedagogical approaches and threw students into C++ right from the start. The result was generally disastrous. C++ is a terrible teaching language, with all of the sharp edges of C, with more in the OO/templates part. For contrast, Brown's program of that era used OO Pascal with a custom-built graphics library designed to be accessible to first-years, yet useful through senior project work.

Design skills can be only learned through experience. Understanding what abstraction to apply is something you would learn after many "failed surgeries". You can only learn this on the job and by reading a lot of code.

Writing efficient software is impossible without understanding machine. Without knowing how things are represented in memory or how compilers/OS works you will never write good software. You will end people that do not understand how event loop in node.js work or write thread safe Java.

Just ask few practical question about Promises, Heap, GC, Threads and you will see blank faces from the same people that just white-boarded DFS.

Anyway, he would get up in front of the staff meetings and say, the school is graduating students who do not know how to code. The school didn't care; they got paid. Every class of any import had team projects because "that's what the real world is like". And every team would have the one person just skating by. The only exceptions in my entire undergrad education was in the graduate level course I took with a friend, which thankfully had two-person teams. And the one elective I took with the aforementioned lecturer, who actively kept tabs on who was doing real work through surveys and looking at the source repositories.

Theory (discrete math, algorithms, formal languages) was 3 courses out of an 18-course program. HN keeps talking like it's the only thing you do in a CS major, which is bizarre.

The most obvious way you apply what you learnt in those classes is by writing programs that implement those ideas (And it's also the easiest way to evaluate whether you actually learnt the concepts). But you can just as easily apply that knowledge by designing systems for somebody else to implement — somebody who presumably lacks the knowledge required to architect the system. Hammering out code is easy, and you don't need a university degree to do it. It's the rest of it that takes some study.

In my case, the topics were similar to the list you give (although there were a significant number of optional classes which I filled with math, skewing it a lot), but the subjects were definitely more theory-focused than practical. Sure, there were practical classes for each subject, weekly projects, semester projects and so on, but they were secondary to the theory in both quantity and difficulty. As an example, you might deep dive into a number of networking protocols, but in the same period only implement a toy TCP/IP during a prac.

Always surprised to hear about this variance, given the general consensus that there aren't differences in quality between schools.

https://en.wikipedia.org/wiki/Goodhart%27s_law

Does that mean there isn't space for a module on software engineering theory (design patterns, development methodologies, OOP principles, testing, version control...)? I really don't see why that has to be the case. Some of the worst code I've seen has been written by academics - undocumented, undescriptive nonstandard single letter variable names everywhere, huge monolithic functions named "compute" that span hundreds of lines and several levels of indentation.

See how it doesn't make sense?

Using git helps a lot!

Fakers, cheaters, bullshiters are everywhere unfortunately, spot them early and avoid them where possible, preempt their attempts to land grab credit

We are. Source: I am a master-level bullshitter. Professional lobbyists and politicians ask me to make introductions, use my network, etc. Here's the weird thing, though: I'm a software developer. A pretty good one. Not the best, but top 20%.

I know tons of Natural Bullshitters like myself, but I've never met another one that was a software engineer. Dabblers, occasionally, but no Naturals.

The thing is, it takes a bullshitter to spot a bullshitter. So being a good bullshitter is the skill that has offered the most utility to the various jobs I've had in tech: calling out frauds, inflating the profiles of the people on my teams doing actual work, undermining lesser bullshitters that try to take credit from them... come to think of it, there's never been a technical team I was on where I was not the most popular member of the team (among my peers, at least).

So if you can find a Daywalker, try adding them to your team...

I wouldn't call myself a professional bullshitter, and I wouldn't still have a business after ten years if I didn't have substantive knowledge of what I do.

However, my cultural and family background is in the humanities. I spent most of my adolescence and teenage years on my programming hobby, like many people here I think, but the route to a tech career was a rather incidental one. My parents are philosophy professors, and I entered university with a political science major (switched to philosophy), before dropping out two and a half years later to pursue what was by then an ascendant tech career.

The discord between my background and the psychology of typical software engineers and business guys has led to amusing, sometimes infuriating cultural clashes over the years.

Nevertheless, I've got the comment more than a handful of times over the years that I really should have been a writer or do something involving lots of speaking. You can probably tell from this comment alone that I'm not a person of few words. As I get older, this has seen me enlisted to assist with marketing copy, résumé polishing, LinkedIn profile formulation, and a variety of other tasks that require putting a spin on things and drawing on one's facility of rhetoric. Some have said I'm a lawyer on the inside, combining the logical, left-brained, procedural qualities of a programmer with a knack for wordsmithing eloquent pleadings.

It's a weird space to dwell in. The real nerds think I'm a bullshitter half the time. The real bullshitters think I'm a nerd who lacks the social jujitsu to really hobnob with Visionaries like themselves. Beats me.

Mostly the latter, though it's us (practitioners) not the industry (employers). We're a visible, highly paid field of work without professional body either settingnquality standards for schools or certifyiing minimum competency of individual practitioners.

What should be regulated that makes sense in both Javascript and C? How should front-ends be treated compared to Assembly code? What best practices go where, and who decides this?

A ton of people have tried to certification programs and they generally fail to get real traction because every project is different from last year's project. I think this is because the field is advancing very quickly. Regulation needs a slower pace to keep up.

One thing with science on the side of truth is that the simplest questions (such as "what's the difference between a boolean and an integer?") can have extremely complicated and deep answers that lead to crazy discussions about formal definitions or implementations on different platforms and etc. And these are the kinds of things you can only learn by actually learning them, and trying to bullshit their way through an answer will quickly paint the faker in a bad place.

Give a very simple programmatic task, a paper (or a blackboard) and a pencil. As you watch the interviewee elaborate his solution, and as you discuss it with them, you'll immediately see if programs are a deeply foreign object to their mind, or something they're fluent with.

The point is not syntax, forgotten semicolons, or even knowledge of libraries. Don't bother with design patterns either, the kind of tasks we're talking about is too simplistic for them to be meaningful: just watch whether translating a task into program snippets comes naturally to them. If they can do that, they can learn, and probably have learnt a great bit already.

What works well is some form of "tell me about a time when ...". The candidate gets to tell a story of their choosing, but the discussion is long enough that they can't keep track of their lies...

Isn't this in every industry? You don't apply for the job you are most qualified for, you shoot for the next level job, the job that pays better, looks better, but stretches your expertise.

  Isn't this in every industry?

Needless to say, this means you can't drop out of university to found an architecture startup! And these organisations often have the side effect of influencing wages (and industry reforms) due to their control on the supply of workers.

People on programmer forums don't seem to like the idea of this sort of thing much. Better for my ego to believe I'm a unique genius due to my own efforts and inherent superiority; than to believe I'm a replaceable cog stamped out by a university production line!

Part of the problem is that programming is far too diverse a field. The only common denominator that could be reasonably certified by a gatekeeper/professional guild would consist of theoretical grounding in software engineering and computing concepts that typically comes with a CS degree. Yet, as all programmers are aware, people who have managed to jump through that hoop do not necessarily programming skills possess and do not necessarily good programmers make, while there are plenty of self-educated types who have managed in lieu of the formalities.

That's not to say that the field might not benefit from some professionalisation, just that there is an argument to be made that it is qualitatively different from civil engineering, medicine, aviation, architecture, accountancy and the like, if for no other reason than that the technology and skill requirements shift at a bewildering clip in rolling releases across 3-5 year time frames. That sort of thing is anathema to the slow, bureaucratic pace of guilding or regulation.

For instance, calculus, linear algebra, differential equations, numerical analysis, and so forth, are only a small part of what makes a good actuary. But they have a formal exam that you need to pass in these areas in order to be an actuary. They don't quiz new candidates with 10+ years experience on integration by parts during a job interview.

Because we lack even a basic exam in software development, we have to do data structures and algorithms over and over in interviews. I'd be more than OK with setting up a basic exam for what we can cover. I'd much rather take these exams with some assurances that it will be graded consistently and fairly, cover the proper material, and will lead to a lasting credential respected in industry. I wouldn't mind this even if it involved substantial effort and studying on my part, because I'd know what I was studying for and why.

Hey, maybe it means my next software job interview won't have to involve weeks of studying followed by 5+ hours solving tree traversal problems at a whiteboard.

I still think there'd be far too much contention over just what is to be included in the corpus of essential knowledge. Everyone seems to agree that data structures, algorithms and systems fundamentals seem appealing, but just which ones depends greatly on whether you're doing embedded PLCs for fuel injectors or whether you're doing React.

I've been programming since I was 9, for most of that time in C. Yet I'd be very hard-pressed to tell you how exactly CPU instructions work, and have never touched anything "closer to the metal" than C. Should this disqualify me from the profession?

After all, law now generally requires a $150k+ degree and three years of your life. Plenty of people, including Obama, believe that it should be at least shortened. But once entrenched, it's very tempting for gatekeepers to install expensive and lengthy credentialing procedures.

So overall, I think there's a good way to do this, and I do think that software development could be a better profession with some credentialing, provided it was done sparingly and properly (a huge "if", I must admit). I'd like to see this happen along the lines of the actuarial field, with exams rather than required degrees, largely because I think people should be free to acquire the knowledge at a pace that suits them. If you want to major in math, or physics, or something else, and "read for" the exams (to quote an old law practice), you should be allowed to. If we had something like this, it might benefit our field immensely. It would be a huge improvement over the capricious, opaque, and arbitrary informal exam taking we do over and over every time we interview.

But... I can't possibly pretend I don't understand your concerns. I personally was a math major and I got a MS in Industrial Engineering. I never did major in CS, I certainly didn't study "Software Engineering." I am also willing to openly question the value of test-driven development. There are plenty of people who think one or the other or both should disqualify me from the profession, and the idea of empowering them with the force of law (ie., the power to fine or imprison me for developing without the background and methodology they've decided is acceptable) is pretty chilling. That would be much worse than what we have right now.

No - it shouldn't. I feel that you should want to know this level and more about the internals (and history) of computers. I'm biased in that has been a driver for me personally...

...but to give you a hint:

A CPU (in the most basic sense) is nothing more than a very fast and very complex player piano, regulated by a clock. At each "tick" of that clock a row of "holes" (bits) representing a variety of information (address, data, instruction) is presented to the CPU. These bits are actually voltage levels. The CPU uses these voltage levels to change the state of logic gates in the system (which are wired for a variety of different tasks - but you only need one particular kind of gate to make any others - a NAND or NOR), which determine what happens, what to do next, etc.

I won't go further - and let me be clear that what I wrote above is nowhere near complete, and only describes the most basic level of an "ideal" CPU (or ALU or whatever) - because in the real world, you have things like voltage transients, timing issues (signals not arriving at the same times - hence things like wait states and such), noise, plus things like triggering on rising or falling edges of clock signals, multiple clocks staggered in time (for multiple triggerings per "cycle"), and a whole host of other things.

Yeah - it's pretty complex. But at the heart of it, it is pretty simple - a player piano, more or less, with a music reel spinning at mind-boggling speeds. If you need or want more information, there are (like everything else) plenty of resources on the internet about how all this stuff works. Check out some of the sites on people who have built computers from relays or logic gates; they typically have a lot of good information about the lower level stuff. Also look into some of the old books on building computers, and how they work (I'm talking the practical computing books from the 1950s and 1960s - difficult to find at times, check on used books online, in stores, plus on google books and archive.org; also, old back issues of Byte Magazine from the 70s and 80s are a good resource).

Other than your own projection going on in the first part, I'm not sure what you're actually saying. The fact there are not gatekeepers makes us more replaceable - some guy can take a bootcamp, work on some projects, and bam, he's competition. Programmers are acutely aware of this, and are constantly leveling up as a consequence. (And on that note, if there were gatekeepers, we'd probably be a lot more stagnant as an industry).

Also, I mean, common sense, it's constantly changing what tech and abilities companies require, so how is a gatekeeper system even going to work. I've gone from Rails to JS to TensorFlow, professionally, all in the last 3 years.

There are many different job-roles out there and it is hard to find out what these roles even are. It takes time for people, especially freshly graduated students and career changers, to find their niche. At some point almost everyone gets themselves into situations where they're not competent and then realize they need to either make a switch or get focused.

Rather than viewing such career-exploration failures as "fraud", as some are apt to do here, it is better for employers to take a more active role in developing talent and recognize that early career folks are going to be hit-or-miss.

Still... the exams are harder than you'd need to simply weed out the fakers and cheaters. I can do various linked list and tree operations, set permutations, and so forth, and it's not like I've memorized it. I can apply these things. But the questions I've been asked in interviews... solving that, at the whiteboard, in less than an hour, all I can say is the companies are setting a much higher bar than merely ensuring that someone knows his or her stuff. That's fine, but let's make sure we don't pretend this is all about rooting out people who can't do fizz buzz. You can be pretty good at this stuff and still fail pretty badly at these interviews.

Not only that, but it devalues and dilutes your own degree, which is significantly more damaging monetarily.