Hacker News Reader

Comment by glangdale | Hacker News Reader

Here's the trajectory:

Fake your way through basic CS courses.

Find your way into group-work heavy projects in later years, possibly doing enough ancillary aspects of the work to be semi-useful. It will be likely that your other group members will find it easier to grin and bear it.

Optionally: do a Masters or PhD. Plagiarize your work, or potentially hire someone to do it for you.

Continue into the work force, focusing on office politics, group projects, putting your name on things that you weren't really a contributor to, etc. Write a lot of reports.

This is why we're not a profession, folks. I'm amazed at the number of people who got on here to theorize about every goddamn thing ('grade inflation!' 'what are marks good for anyway?' 'I use the web all the time to remind me of things I've forgotten!') aside from the content of the article, which is that there are tons of people going through coding classes who are apparently aiming to get through without learning any code and want to cheat.

Every time you get dragged through some pointless, patronizing and degrading interview process that assumes that you don't know your stuff - you can thank the cheaters and fakers, and the fact that our industry doesn't have the will to root them out.

View on HN

A company in the Netherlands sometimes hires me to help them guide the interns. They are what is called a learning-company over here.

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.

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.

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.

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

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.

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

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.

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

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.

I really do not understand how so many people manage to fool almost everyone for so long.

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.

How can you understand object orientation and complex data structures until you've learned what a pointer or structure is (C code, yeah)?

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.

As someone that studied on Universities that prefer OOP first approach, I would disagree.

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.

I had a lecturer as a close friend in college. He was only a lecturer because he refused to do a dissertation to complete his doctorate. He was the best teacher in the department. So it goes.

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.

It isn't the University's job to teach people how to code. University isn't a vocational school. Yes, one should know how to code when they graduate. But the school is usually trying to teach the theory not the coding

Let's keep it real, the cheaters aren't opting out of learning to code because they want to dedicate all that extra time to mastering the theory instead.

The real problem is, the idealised goal of a university should be "learn something", but it's actually "get a degree".

Another case of "Once you turn a metric into a goal, it ceases being a good metric".

Goodhart's Law

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

It depends on the class, but often times it is the university's job to teach people how to code. For example, if you make it through an algorithms class without knowing how to actually implement the algorithms, that is probably ok, as long as you have a strong enough theoretical understanding of them. If you make it through a systems programming class without learning how to do any systems programming, then that is a problem.

What? Almost the entire meat of my CS program was programming projects in a variety of foundational domains (operating systems, networking, concurrency, databases, graphics, compilers, cryptography, machine learning, visualization, etc).

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.

Where I studied, our lecturers expected us to learn the fundamentals of whichever programming language on our own time. The vast majority of our courses were focused on theory of CS/physics/maths/engineering/etc. That might explain why our class size dropped from around 100 in first year to around 15 by 4th year.

I suspect there's a fair bit of variance between CS courses, and even how we remember it.

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.

Interesting, I guess mine skewed the opposite way: the theory served the projects, and the vast majority of what you needed to know for theory-based exams, you'd pick up by doing the projects. Some lecture slide and textbook review necessary, but not a lot.

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

We had 5 kinds of maths; algorithms and data structures, databases, computer architecture (with assembly), English lessons, history of mathematics, operating systems, networking, and 2 programming courses: C and Java. There was very little learning by doing.

I think you misunderstand. After an introductory course, it's expected that you don't need to be "taught to program" anymore. As part of your compiler class, you'll be taught about automata, regular expressions, grammars. For your projects, you might get some help with using a lexer and a grammar generator, but you should be able to figure out the "programming" parts yourself, and the teaching emphasis is on the theory.

Sure, but the vast majority of lecture time prepared you to do the programming projects, the vast majority of out-of-class time was spent on the projects, and the exams required minimal study besides having done the projects (one way of spotting cheaters was to look at the delta between understanding demonstrated out of class vs. in class).

See it this way: Each subject you finished at university, did you come at the end thinking "I learnt how to program", or did you come out thinking "I learnt how to structure a graphics pipeline"/"I learnt the tradeoffs involved in building distributed systems"/"I learnt how to structure data to make consistent updates and retrieval simple and highly performant"?

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.

I'm curious, where did you attend? I started a CS degree (at UC Irvine), then stopped because I felt it was too abstract. Maybe I bailed too early.

"It is not the medical university's job to teach people to practice medicine. It's not a vocational school. The school is usually trying to teach the theory, not the practice"

See how it doesn't make sense?

No, because a medical school is literally called a professional school.

I don't know why you are marked down for this

I'd disagree on this. Is it important for the university to cover the theory (algorithms, compiler design/automata/languages/parsing, logic, discrete mathematics etc)? Absolutely.

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.

The lecturers I had at uni would give individual grades if you ratted out the slacker and they couldn't prove what they did.

Using git helps a lot!

A big tactic the fakers use is to paraphrase everything everyone else says. We had a guy in our team that literally paraphased everything said by anyone else in the stand up. E.g. you could say we're waiting on the dba team for a qa db (grr large multinationals and their asshat dbas), he would seconds later say something like 'i think whats currently delaying our progress is waiting on the dba team'. Last I heard he got big pay rises (as a coder at the time with a net negative contribution) and eventually entered management, my friend that was a permie on the team got a insulting 500gbp annual increase and a bad performance review, he wasnt a faker, he quit.

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

"Fakers, cheaters, bullshiters are everywhere unfortunately"

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 can kind of relate to that.

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.

I dont underestimate the benefit of soft skills and also benefit masters of org/office politics can lend to the rest of the team, especially when your one step away from a contract renewal. Ive had great PMs before that add the benefits you mention. But occasionally you get a toxic bullshiter in the coding space, dabblers ranked as technical peers, out for themselves and somehow pulls the wool over management, asshats.

> Every time you get dragged through some pointless, patronizing and degrading interview process that assumes that you don't know your stuff - you can thank the cheaters and fakers, and the fact that our industry doesn't have the will to root them out.

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.

I agree with you having a centralized regulatory body set standards would help, but our business is highly resistant to this even if all programmers wanted it.

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.

I have never interviewed/hired anyone, but the more I work as a developer the more I feel challenged to do it and invent techniques to detect liars.

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.

There is actually a lot of research into how to conduct interviews for useful answers. They all come down to you need a deep discussion.

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

The truth is, you don't need anything elaborate to expose a fraudster.

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.

> you can thank the cheaters and fakers, and the fact that our industry doesn't have the will to root them out.

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?

Many professions have professional institutions which act as gatekeepers and audit the quality of university courses. For example, in the UK to become an architect you must become a member of the Royal Institute of British Architects, which requires a degree, a certain amount of postgraduate training, and a certain amount of experience working under an already-qualified architect.

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!

And all those gatekeepers introduce significant economic inefficiencies while often failing to control adequately for quality.

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.

I don't see this as such a problem.

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.

That's a very fair argument.

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?

Almost nobody I know would say it should disqualify you from the profession, but I can see why you're nervous about this.

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.

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

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

> 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

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.

I can't understand the mindset of someone who would go to all these lengths just to be employed at something they don't understand at even the most basic level. Those same people skills could make them a lot of money in sales without all the grief.

I suppose sales is already overcrowded with those people, so some of them expand to "greener pastures".

OK, but real success in sales takes enormous talent, skills, and experience.

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.

Unless the employer has invested a large amount of money on a salary for someone who is not skilled in their supposed area of expertise. In my experience, developers tend to start their careers making more money than salespeople starting their careers.

Yeah, no doubt that's a huge part of why we have these interview-as-exam experiences in software development.

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.

I think employers have a degree of responsibility here. Ultimately, they're the ones who've taken projects that ought to be within the capabilities of single individual hackers and said "this needs a team of six and a project manager". Thus transforming the project from principally technical (or tech + requirements gathering) into one of those highly-political group work exercises.

Employers don't need to take responsibility. All they need to do is to think about income. If they can bill the customer for an employee's "work" it doesn't matter to them whether the employee can actually do anything or not. This is common practice in the IT industry.

I don't know about companies, but I have a tendency to not pay a contractor's bill if he didn't deliver the work as agreed.

Yes, we all get that you don't get that it's easy for larger companies to mix in workforce that either does nothing or does not even exist. This is rampant in the construction and IT businesses.

>Every time you get dragged through some pointless, patronizing and degrading interview process that assumes that you don't know your stuff - you can thank the cheaters and fakers, and the fact that our industry doesn't have the will to root them out.

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

Not sure that PE/CE status will help my Father commented when going for his IEEE chartered status in the UK that its not what you know but who you know.

Reply on news.ycombinator.com