9 ms·

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 as

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.

jdmichal 9y ago
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.
- chrismcb 9y ago
  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
  - apetresc 9y ago
    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.
    - Nition 9y ago
      The real problem is, the idealised goal of a university should be "learn something", but it's actually "get a degree".
      - majewsky 9y ago
        Another case of "Once you turn a metric into a goal, it ceases being a good metric".
        FabHK 9y ago
        Goodhart's Law https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
  - benchaney 9y ago
    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.
  - closeparen 9y ago
    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.
- lugg 9y ago
  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!
dragonwriter 9y ago
> 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.
- sqeaky 9y ago
  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.
orthoganol 9y ago
> 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.
- michaelt 9y ago
  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!
  - abalashov 9y ago
    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.
dasmoth 9y ago
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.
- JustFYI 9y ago
  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.
  - skookumchuck 9y ago
    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.
    - JustFYI 9y ago
      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.
kurtisc 9y ago
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.
- TeMPOraL 9y ago
  I suppose sales is already overcrowded with those people, so some of them expand to "greener pastures".
- crispyambulance 9y ago
  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.
  - shepardrtc 9y ago
    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.
lostboys67 9y ago
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.
komerdoor 9y ago
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.
- consp 9y ago
  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.
sitepodmatt 9y ago
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
- dccoolgai 9y ago
  "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...
  - abalashov 9y ago
    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.
Clubber 9y ago
>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.
princekolt 9y ago
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.
- bluGill 9y ago
  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...
- fab13n 9y ago
  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.
geebee 9y ago
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.

jdmichal 9y ago

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.

chrismcb 9y ago
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
- apetresc 9y ago
  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.
  - Nition 9y ago
    The real problem is, the idealised goal of a university should be "learn something", but it's actually "get a degree".
    - majewsky 9y ago
      Another case of "Once you turn a metric into a goal, it ceases being a good metric".
      - FabHK 9y ago
        Goodhart's Law https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- benchaney 9y ago
  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.
- closeparen 9y ago
  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.
lugg 9y ago
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!

dragonwriter 9y ago

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

sqeaky 9y ago
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.

orthoganol 9y ago

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

michaelt 9y ago
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!
- abalashov 9y ago
  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.

dasmoth 9y ago

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.

JustFYI 9y ago
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.
- skookumchuck 9y ago
  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.
  - JustFYI 9y ago
    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.

kurtisc 9y ago

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.

TeMPOraL 9y ago
I suppose sales is already overcrowded with those people, so some of them expand to "greener pastures".
crispyambulance 9y ago
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.
- shepardrtc 9y ago
  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.

lostboys67 9y ago

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.

komerdoor 9y ago

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.

consp 9y ago
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.

sitepodmatt 9y ago

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

dccoolgai 9y ago
"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...
- abalashov 9y ago
  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.

Clubber 9y ago

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

princekolt 9y ago

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.

bluGill 9y ago
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...
fab13n 9y ago
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.

geebee 9y ago

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.