A Story of a Fraudulent Coder
shakycode.com
shakycode.com
1. He had 0 idea of coding, or why something was done - basically copy paste from github/stackoverflow and call it a day.
2. She has some basic understanding, but basically got into CS because she had heard that SE/CS Majors made "big bucks" and she thought she "knew computers"
Both graduated 4 years later, just as clueless but with degrees. When it came to interviews, both had 0 idea of the questions asked - to the point that I gave up helping them (if you can't do fizzbuzz, linked lists etc in any language or even psudocode, then you should really learn that first).
So they decided to do exactly what "Brian" did - downloaded a few of my public repos, uploaded as their own (btw it's funny because my name and email is on the README, and on almost every file - autogenerated with IntelliJ/Webstorm).
Somehow they land interviews, and both of them gets jobs at this fancy startup (making way more than me). One of them realizes that she's way over and since I was not helping, she decided to outsource it to Fiverr. She's been there 2 months and no one seems to raise any issues.
At times like this I kinda loose a bit of faith in our community - If that was what was needed, Why am I getting paid less to do more honest work? :/
And, I've got a feeling they'll figure it out when they have bugs, or ask her to fix bugs instead of adding standalone features.
(Unless she sends over the entire repo to the person she hires - at which point, I'm 100% sure she's breaking their contract).
You're optimising for doing good work. They're optimising for landing high-paying jobs.
Note that I'm currently doing software development in the Midwest, so my view may be biased.
There seem to be a lot of midwestern companies full of programmers, selling software products, which don't see themselves as "software companies" (like Yahoo is a "media company"). Without exception, I found that those companies were trying to buy code like it came off an assembly line - paying lots of people low wages to pump out their daily lines. Some of the "smarter" ones had realized that this offer was so unpalatable that they couldn't get existing programmers, and were shipping new hires to bootcamps to create candidates. (Cynically, I assume that they have an incentive to ensure these bootcamps teach bad, cargo-cult programming - if they were good they'd quickly lose trainees to better jobs.)
Job hunting out there, at least half the prospects I turned up had something hideously bad involved. Some mandated novice-bootcamp attendance, starting even experienced devs at "See Spot run, see Spot code". Some wanted 6 month (or 1 year!) trial periods on minimal salary or even sub-minimum stipends. Some just wanted the usual bullshit like "5 years of Java 8 experience". Many had ludicrous location requirements, like cycling through shifts in offices around the country before ending up in rural Montana. Pretty much all of it felt like commodity purchasing - I wasn't an employee, I was an agreement to deliver "six codes per week".
Moving back to the coast, and seeing a lot of self-described software companies, I have a lot more hope that people are at least trying to hire well. There are just a lot of companies which haven't gotten the message.
Not sure if this is a good or bad thing.
This isn't confined to developers. You find the same dynamic in commercial pilots (making an exception for Airline Transport Pilots with thousands of hours of experience!) and Park Rangers: enough well-qualified people want to do the work so badly that the pay remains very low.
My current work allows me a pretty decent look at literally thousands of different IT infrastructure set ups by this point only half a year in, and I'm still explaining the basics of IT administration, infrastructure, SQL queries, and so on to people with the title "Senior ______" and a list of certifications that adds a good 4 MB to each of their emails for all the banners.
Try not to worry about it, and don't enable them either. Be professional, but be firm. I won't promise that they will get their comeuppance or that you will be rewarded, but you can at least leave every day not having to look over your shoulder or double checking that you covered all your bases. In the long run, you'll have the knowledge to do what is necessary for future growth in your career, they will have to keep inventing new ways to fake it.
Sounds like there's no misrepresentation at all. Most people treat it as to become delusional of their own abilities or qualities, so functionally they are just tricking themselves in addition to everyone else.
"Changing your mental state" can be just as harmful as outright faking and sometimes there's no difference in outcome at all.
A little knowledge in a bad mental framework is a dangerous thing.
https://en.wikipedia.org/wiki/Ken_Williams_(game_developer)
Basically, he moved across country with his wife (Roberta), because (somehow, IIRC the story) he got hired as a software developer by a company in California - but he had no programming experience.
So - on the long drive from where they lived, he crammed learning how to code from a book for the language (don't recall - maybe cobol or fortran, given the time period), and was able to show up, day one, and code for his job.
At least, that's what little I recall about the story. I probably have a few details wrong. Regardless, its an even more amazing story when you realize this was at a time when Ken would have had no access to a computer until he got to his new employer's office (at the time, desktop PCs were virtually non-existent, and laptops were but a dream of Alan Kay - at best, you had a green-screen terminal, if you weren't submitting card batches)...
I don't think I'm a great programmer but if this is what a "bad programmer" is maybe I can breathe a little.
"Bad programmer" is a big range, but the low end is so much lower than we tend to remember.
It might land you a job, but then you have to keep the lies going indefinitely, living in fear of being found out.
Is it worth it ?
If the biggest threat is that you lose your job, you don't have much to lose. After all, that is the same place you would be if you didn't try at all. And if you can gain something in the process, which seems quite likely here, you're already well ahead of the game.
So yes, the only reasonably foreseeable risk is losing your job.
http://money.cnn.com/2012/05/13/technology/yahoo-ceo-out/
https://panampost.com/sabrina-martin/2016/02/25/uruguay-vp-a...
http://www.nbcnews.com/id/40630166/ns/health-health_care/t/f...
However, there are many more that aren't (I personally know a few cases, including a CEO, but I'm not going to out them).
In an interview, I gave a problem to a candidate and asked him how he'd tackle it. He said he'd google for a solution first. At that moment, I recall having a dilemma of choosing between "smart guy" and "no good as a problem solver". He turned out to be the latter, but it was a conceivable answer from a smart and capable candidate too.
Not really - if you aren't authorized to do that as a developer, it's likely because of IP issues, etc; IOW, you have access to privileged info (the code and IP) - and you are supplying it to an outside 3rd party without permission from your employer.
If all that happens is you get fired - you are lucky. A very expensive lawsuit would be a more likely outcome, depending on the company and their resources, and whether they want to "make an example". It's not much different than taking their code and handing it to a competitor.
Realize that your ability to continuously put in the effort required to become really good is a superpower, even though to you its just following your passion. Many people cannot manage this, and its a massive advantage.
Management material! (office space)
Unfortunately, this is also how many people decide to go into law and medicine.
If you are suggesting that we only want doctors and lawyers who are truly passionate about what they do, then artificial price ceilings are necessary to indicate to others that they are not needed. However, in doing that you create a shortage situation.
Well doctors are happy to limit the supply.
Because lawyers don't get paid that much any more...
You never count another man's money.
I'd say a company who hires like that is likely to go under.
Why aren't you applying for the jobs that they are applying for?
I like getting things done. I like working with smart, sane, kind people. I like working on good code. As long as I can make a decent living somewhere like that, there's no plausible salary that would make me give up that.
But if these people with little/no experience are getting paid higher salaries, it strikes me that ohstopitu is probably being paid under market rates at their current position and there will be companies with smart, sane, kind people and good code bases offering similar (or greater) salaries.
There are dozens of other reasons why it might not make sense to apply for those other jobs, but all of those are decisions and tradeoffs for you to make.
If salary is the overriding concern, it's probably an easy fix.
As an example, I took a lower salary at a nonprofit because I cared about the mission. Or at the other end of the spectrum, financial trading companies pay a fair bit more because they have no mission but money, and are often unpleasant places to work.
That's a fair enough point. My original post was just to point out that the answer to ohstopitu's original question is not some great mystery, and all they need to do is answer the question I posed back, because it's exactly the same answer to both questions.
The thing I remember is that while at the time most of them were worth a lot of money on paper, it was only about a year later that they were all unemployed and the hoped-for riches had vanished along with a huge cloud of VC funding.
I'm not personally cut out to be a complete mercenary but it seems like if you are it's critically important that you pay a lot of attention to timing your exit. Unless you have a high chance of getting so rich that you won't need another job, you really need more than that to take to the next gig.
But of course, this isn't new behavior and because we work in a job which is seen as well paid, so fraudsters will try to get something for nothing.
See: http://thedailywtf.com/articles/The_Brillant_Paula_Bean
This reminds me of a story from 2013 where a developer at Verizon had outsourced his job to a Chinese firm. He was praised as being a top developer but was eventually found out.
http://www.npr.org/sections/thetwo-way/2013/01/16/169528579/...
How?! I don't have a degree. But how? How can you get a degree and still be clueless?
>Somehow they land interviews, and both of them gets jobs at this fancy startup (making way more than me).
Either you are doing something very wrong, like not negotiating right, and should be paid more, or my understanding of the universe has just been flipped on its head.
There's an arms race between hiring companies lying about the experience they expect their junior devs to have and the prospective employees lying about the experience they have. To be fair, the prospective employees probably started it.
As someone who did a dev bootcamp, we were under a lot of pressure to make ourselves appear more interesting AKA selling ourselves AKA telling a story AKA lying. That's how those places stay open, they get to say "80% of our students found a job within 3 months!" (Note: the actual learning part of the bootcamp was fantastic, really enthusiastic teachers always happy to help, great environment for learning. But the "help you find a job" part of it wasn't so good).
I was pretty uncomfortable with the whole lying thing. Fortunately I found a company that looked at my projects, asked questions, and didn't react negatively when I honestly told them I had no experience with X, Y, and Z.
I'm not trying to apologize for the guy in this story. What he did was clearly unethical. But there's more to this story than some guy who is a pathological liar.
THIS.
Not sure how many times I get an email from a recruiter and the requirements portion goes something like this:
- At least 3 years experience
- Expert in (list various JS frameworks here)
- Expert in (list various responsive frameworks here)
- Expert in REST and SOAP services
- Expert in MySQL
It's like companies are looking for developers who don't have any experience, but want them to be experts in everything so they can pay them nothing while getting someone who's fluent in all these technologies. There is indeed a race to the bottom to fill junior spots while still having astronomical expectations as the desired skill sets.
I mean, three years in, I was still struggling with CSS quirks and IE. Being able to write decent Javascript? Not even close. I had little or no deep knowledge of why I was writing my JS one way instead of another. Was I an expert? Psssshhhh no way.
That crap gets me especially. Look, there are zero candidates who can truly claim to be a "MySQL expert" applying for your CRUD dev job, because all of the people who can truly claim that are making more money doing just that and not having to worry about the other junk in your requirements list.
I remember reading the resume then walking over to my boss's office to ask "why am I even wasting time phone screening this crap?" and getting the answer "Steve knows him and says he's pretty good. Cut it short if he's not."
Relatively meritocratic, yes. But at the same time, suffused with bullshit. In particular as regards to the (generally inflated and useless; and let's face it, nearly ubiquitous in tech position ads, even still) "N years of X" requirements that the commenter was referring to.
And as someone who's done a couple hundred interviews I don't really care what's on someone's resume.
So would you mind letting your HR people (you know, the ones who write the aforementioned position ad copy) in on this little secret? As in, just walk up and tell them sometime and say: "Actually, we don't really care if they have 5 years of Angular or 3 months. We just want someone who's good. Meanwhile these ads you're writing with these made-up and generally useless years of platform experience are turning away, in droves, the very species of developer -- hardcore generalists with solid fundamentals, both intellectually and coding-wise (in any language) -- that we're so desperately looking for."
Or would that just confuse them?
I have interviewed over 2500 programmers and have never looked at their previous work, on github or anywhere else. Never.
- I don't know if it's their own work.
- I don't know if they were part of a team that did the work.
- I don't know their role on that team.
- I don't know how long it took to build it.
- I don't know what else it connects to.
- I don't understand the context that the work fits into.
- It's usually far too much for me to review to get a feel of their ability.
I usually have them do something small in 15 to 30 minutes, on white board, pencil and paper, or environment of their choice. OP mentions fizzbuzz. This is often a good choice (and weeds out 90% right away).
Then I review what they've done with them. I'm interested in their "noun" (what they've produced), but more interested in their "verb", the discussion thay have with me about what they've done. That discussion can get very interesting...
- Why did you do it this way?
- How else could you have done it?
- What could go wrong?
- If you had more time, what else would you have done?
- What additional data could you have used to make your decisions?
Believe me, I know there are lots of Fraudulent Bryans out there. They don't get past me. They shouldn't get past anyone who doesn't have a lazy dependence on stuff like github.
Obviously you can't trust a generic todo app in someone's GitHub, but some people have a very unique set of projects and it's clear that it isn't Stack Overflow copy and paste. By not looking at their GitHub at all, you're ignoring a huge signal as to the applicant's coding ability, as well as organizational skills, git fluency, etc.
EDIT: that said, even on my worst day I can handle basic fizz-buzz problems. As long as the screener is basic enough, and only step 1 in a larger process, I have no complaints.
I'd rather find this out in an interview than during a critical sprint. That's part of the reason I do it this way. I'm interested in your work habits and personality as much as your code. I make my interviews as "low stress" as possible. A coder who can't code for me for 15 to 30 minutes is a big red flag.
you're invalidating months/years of open-source work
I'm not "invalidating" anything. I'm just doing my job as efficiently as possible, which is to assess your ability to contribute to my team.
I think that's a false equivalence. Crunch isn't like an evaluation.
There's already a joke about this, where the interviewer is verbally abusive to the interviewee to "test if they work well under stress." (Not to say that you're doing anything wrong, just that I don't think your gleaning the correct information from such a thing).
I don't think you can argue that you're not invalidating someone's experience (within the context of their suitability for the position) if you don't look at any of the code they've written outside an interview process, because it's self-evident that there are candidates that are talented programmers who cannot demonstrate those skills effectively during an interview.
You can argue about how insignificant of a minority that is, though. I'm a senior developer who has been offered most of the jobs he's applied for because I _have_ been able to prove basic code literacy during an interview (and have typically surprised employers by how effective I can be, when not in an interview situation). So if the _screening_ bar is low and if you're taking steps to ensure that the handicap of social anxiety is diminished, it may be a negligible percentage of candidates.
There is no relation between those.
Doesn't matter how good you are at coding if you're having a panic attack.
I disagree. Nobody is invalidating anything. Those contributions still exist, people still benefit from them and you still retain your experience. That being said, while they don't directly contribute to your employment chances in this case, your experience does.
Definitely no arguments that open-source work has merit far beyond its impact on hireability :)
When they share their github or website, I'll view the source on the website to see how they organized stuff or if they did literally copy/paste a template.
With GitHub, it gives some talking points. So for example, if they have some Angular code on their GitHub and also list it as a competency on their resume I'll ask them about the project.
Granted, I agree that this screener really did a poor job at seeing through this candidate's smoke screen but still, I find GitHub and personal websites useful in the interview process.
It does not take away the actual parts you mentioned about walking through a problem during the interview, or talking about real situations on the job and how they would approach finding a solution.
It's merely a talking point, it becomes super clear if someone has copied/pasted code.
I like to treat my github in a certain manner, and maybe I should change that.
Currently, what I have on my github is some repos that are all mine - but I also have a bunch more repos that are forks of other repos. I do this (fork other repos) because I like the repo, and some of them might be really old (that is, they haven't been changes in months or years - low commit frequency or such). So - a fork for me is kinda like "save it for later", in case the original repo goes away. Plus, IIRC, if the original repo does get updated, I'll be notified and I can pull down the changes into my repo (my only other option would be to download a zip of the master branch - but then if it did change, I wouldn't know).
Should I not do this? I mean, those forked repos are clearly labeled as forks from the original repo, and I have made it clear in the past that "only these repos are mine exclusively" - but should I not do this? Should I instead have a separate github just for those kinds of forks, and keep my personal repo for only my own stuff?
I'm just wondering how confusing this really is for prospective employers or others - I don't want them thinking that repos x/y/z are mine when they aren't, and miss the repos that actually are mine. It's too bad that there isn't an option to segregate this better on github, and only show your repos by default. Maybe I need to review my settings...
If the code style is completely out of bounds between the two projects, it either helps me dig deeper and ask about previous environments, etc. Adaptability.
It also has the rather interesting side-effect of calling out frauds, especially if the "custom project" was completed and the explanation scripted into rote memory for the interview. Asking why a pattern was used in 'X' for a similar function in 'Y' project versus the pattern used in said "custom project" usually does the trick, separating rather efficiently the people that know what they're talking about from those who are just trying to skate by.
Good luck creating a maven project archetype and getting it to work during a whiteboard session. I would choke so hard on a basic "make a console app to display these numbers". I don't even remember the calls to string split and console display in some of my favorite languages. Why? You'd be an idiot to use those over Log4net or whatever you use in real life.
You're asking a guy that might know how to design rockets how to put together a bicycle. A does not imply B in this case.
I've always thought whiteboard interviews were biased towards those straight out of school, since that's the only place you would write toy apps that use basal language features.
On the other hand, I've got a ton of my own libraries on my Github and some of them are pretty popular. It's abundantly clear that I wrote all of these since they're all published in official package managers with my private keys.
I see things from the other direction. An employer too lazy to check my github and verify my credentials probably sucks.
Provided you understand what is being asked, you shouldn't even need to remember a "favorite language". Most of the time, the interviewer doesn't care if you know something specific in a particular language, but rather you understand the process.
Heck - do it with a flowchart/process diagram, or write it in a "custom" pseudocode - provided that it looks like it will produce the proper output based on the input and the detailed process, it should be considered "correct" enough to get you at least past the first stage.
There are tons of people who claim to be programmers/coders/developers who can't even logically diagram a process or pseudocode a function/class/whatever. If they can't do that, they have some fundamental issues in their skill set that they need to remedy stat.
On a whiteboard you don't have to, pseudo code with "print fizz" is sufficient. Aside from that, it does sound like you are too framework/tooling dependent if you can't work without maven and an IDE.
Does relying upon such a signal risk putting minorites--who typically have less free time--at a disadvantage?
Over the course of a month we met several times, with him showing me exercises and me trying to teach him the basics he needed to solve them. Because he put more effort into getting the solution from me than understanding the material. I told him he would not be able to finish and I was not willing to help him.
A year later we met and he was still in the same spot. When he asked me again to help him I asked whether he was learning. He assured me he'd just read this Java volume he was carrying. He'd memorized the
public static main argh
int four = 4;
four = 5;
He wasn't the only guy like that. But the count of "hackers" I've met is even worse. Most recent one told me he can hack any computer so I told him to hack the router in the corner. "So what is the IP-address of this router?" "It's your gateway, figure it out." He eventually guessed he could use whatismyip.com to point his "hacker tools" at the right target. Turned out I'd done the filtering by interface so he actually saw the SSH port open even though it's closed from the net. Trying to explain to him why I was chuckling turned out to be impossible as he had no notion of interfaces.
He ended up telling me my router is unsafe. Some tool had told him so, well, the sshd version should be hidden.
I just don't trust people much anymore about their supposed skills. What I must learn still is to strictly apply this skepticism to fields where I'm not proficient. That's much harder because the feedback loop is not immediate. Getting a second opinion has saved my health in some instances and much expense on other occasions.
It is fun, but sometimes you really do say in an interview, "Yes I've used X but not deeply" knowing full well you have a weekend to get up to speed or you've spent a week playing with framework "x".
But whatever you do, deliver, and more importantly, keep delivering. To be able to achieve that, as the OP stated, takes years of being a developer.
That may also be the inherent beauty of what we do. Learning something new everyday is what excites me about the world of application development and probably why I dance in the moshpit that is modern javascript.
I think most developers have met at least one so-called "rockstar" coder (or as I prefer, prima donna). They used to be rampant in the games industry, but they turn up almost everywhere. And they are almost always permanent staffers. That's because they'd be fired as contractors.
Contractors are totally used to seeing different coding styles and practices, and dealing with a multitude of personality types. They are also well used to criticism, willing to learn from it when justified, and taking it on the chin when not. Having no political power makes you adaptable and diplomatic, the antithesis of the prima donna.
I met one guy once who didn't seem to understand that projects sometimes started before he'd arrived, and often continued after he'd left; the concept that maybe a load of code was written to satisfy some business requirements a year ago, but those requirements had now been dramatically changed, seemed impossible for him to understand - "Why wasn't this just done the same as the other thing in the first place? Code re-use is supremely important! This is lazy programming!" "We get that, but these two things used to be totally different, but now we've decided to merge them." "Well that's stupid! Obviously anyone who understood OOP would've subclassed this thing in order to..." lead developer loses it and pushes the contractor off the balcony
But most good contractors in my experience are acutely aware of the restrictions and realities of dealing with living, evolving codebases.
I think having the confidence and knowing that you just need a weekend to get yourself up to speed is what makes you a good coder. The more I progress in my career the more I surprise myself how quickly I can switch from one language to another or pickup a framework that shares some basic concepts as one that I've used before.
Proficiency isn't about knowing everything, it's in having the ability to learn quickly.
It doesn't have to be like this, though. I feel lots of clients really appreciate if you bring some fresh air also for the patterns and ways of working. Being able to change the working culture for better on the side will probably have longer-lasting effects than a couple of months of fully focused grunt development work.
Professional musicians can learn to play a new song fairly quickly just by listening to it; intermediate musicians can learn to play by following music sheet; and beginner musicians has to be guided by a teacher, and they basically emulate what the teacher does.
When you help someone like this get a position/salary that they don't deserve, you're actually making it harder for people who actually deserve that position to get it.
It's the same thing when it comes to investors helping a specific founder to raise funding just because they happen to frequent the same cafe and happen to have the same first name.
Whenever you're helping someone with anything, just keep in mind that you're also hurting someone else behind the scenes...
Why should simply meeting a person make them any more deserving of your help? You're just rewarding luck over hard work. This is really evil.
I get the point you're making of the people who didn't get the job that were hurt. And the employer was hurt too. But you can't put the blame on "helping people".
Who you make friends with is 50% of success in life. Yes, you need to be social with other humans to get ahead in life. It's not all based on the quality of your github checkins.
And it's not unfair. We're human. This is how we operate. It's reality.
I think it was an accident - clearly the goal wasn't to enable fraud. I tend to avoid writing full solutions to anything to help avoid making the same mistake.
> Whenever you're helping someone with anything, just keep in mind that you're also hurting someone else behind the scenes...
Only in zero-sum games - learning and teaching generally aren't. Mistakes like this aren't great, but collaboration in general averages out to helping us all out, in the end. Helping people out got me my first tech job, where I proceeded to help them finish their projects. Other people helping me out got me to the point where I could help other people out in the first place.
> Why should simply meeting a person make them any more deserving of your help? You're just rewarding luck over hard work. This is really evil.
Everyone gets lucky sometimes, and doing your part to spread the luck around isn't evil. If anything, it's attempting to balance the playing field. If everyone is just as lucky, then hard work becomes the differentiating factor once more. After all, it's not like luck is exclusive to the undeserving.
I never got anywhere near the kind of help that the author described in the article - If anything, I had people trying to drag me down at every step. Based on the income/wealth inequality statistics, I think that my experience may actually a lot more normal than the one you're describing.
I can't think of a more polite way to say this, but going by the attitude you've shown in the two posts I read, I can't say I'm surprised. Perhaps you're the problem.
Consider this life advice.... or not.
After they had started the job, I should occasionally help them getting traction with our technologies (Java-based), but they failed to understand even basic things. When trying to solve a problem while pair programming, they would just google it, click the first result link, literally copy the first code snippet there, pasting it randomly somewhere in our code and see what happens. I used to stop them and discuss the code line per line, but they failed to understand even basic concepts, like what an object is.
At an early stage, I had once mentioned how C# is rather similar to Java and they would surely get up to speed quickly, but they vehemently objected and stated how it was a completely different thing. At this point, I'm still not sure whether their provided project was fraudulent or maybe just patched up with WYSIWYG tools.
The rather small company I was working at almost went down the drain, and they were still wondering why. I told them it's due to this and another similarly poor hire, that they needed to change their recruitment, and that even a simply fizzbuzz whiteboard test would have revealed the problem. For the next wave of interviews, I compiled a couple of simple whiteboard-optimized tasks about writing fizzbuzz-like code, understanding simple data structures and basic mathematical skills. While they appeared rather simple, it was astonishing how some apparently competent, experienced devs completely struggled there. Obviously, it's not a perfect indicator of real world skills, and some candidates being medicre there (but not exactly bad) turned out to be rather good later.
TL;DR: Do whiteboard fizzbuzz interviews. They cannot be faked and may save you lots of trouble, which is probably worth those 15 minutes each.
Find out ahead of time what their preferred language is, set up a development environment for it, then sit down with them for an hour and have them go through one or two simple tasks, talking to them about their thought processes. Fizzbuzz, reversing a string, parsing a date-time, counting letter frequencies in a string, anything around that level. Basic stuff.
If you can't do problems like that, you aren't a programmer. I think it's an essential filter that should sit near the start of any hiring process.
When on a whiteboard, problems naturally need to be short and simple due to limited space, writing speed and editing capabilities. This leaves more room for interaction between interviewer and candidate, like planning an approach or discussing written code. Also, whiteboards are handy to sketch solutions non-programmatically, with diagrams etc.
Of course, there's the trade-off that the enviroment differs more from actual day-to-day work.
I wish he would have copied/pasted code from Google: Instead he used to bother me and my co-worker constantly, to the point that we nicknamed him "the interrupt controller".
Sadly, this is the kind of horror story people will trot out whenever they want to justify not mentoring earnest people with potential and instead put newbies through "trial by fire".
The thing is many people develop their careers by getting themselves into difficult situations for which they're profoundly under-prepared. Some are lucky to find mentors that provide guidance. Some succeed some fail, some take a longer path than others. A very small number decide to fraud their way into a job that they're going to fail at.
Why would such an inexperienced, ignorant developer need a blog? D. Richard Hipp doesn't have one. Neither does Fabrice Bellard. But for some reason, medium.com is teeming with blog posts from people I've never heard of (some of which end up on HN's front page), usually dogmatically dispensing bad advice about how to program or denigrating the profession and those who practice it by accusing them of racism, sexism, elitism, or some other -ism.
Have bootcamps made this style of blogging a requirement?
EDIT: Downvote all you like. Novice programmers shouldn't have blogs. A blog is a public platform, a soapbox, for sharing your thoughts. As a novice, your thoughts likely aren't worth sharing and might even be harmful. Spend more time on programming and less time on self-promotion and you too may one day be as good as Bellard or Hipp.
You can reflect on something without broadcasting it to the entire world, and if you're a novice, how do you really know what you did right? How do you know your advice isn't leading other novices astray?
> This is a perfectly valid thing to do.
It's "valid" as in legal, but hardly commendable. This style of blogging is generally unhelpful, unproductive, and it reeks of self-promotion.
You seem to believe everyone fits into a pattern you have preconceived. I was speaking generically, some people find it valid and valuable to do so, which does not mean that you (specifically) will find any value in it. I don't read about sports, should nobody be able to write their opinion about a sporting event? How do we know this may not lead novice sports persons astray?
>It's "valid" as in legal, but hardly commendable.
While arguable not 'commendable' is it 100% of the time reprehensible?
A better analogy would be someone starting a medical blog after having read a book or two and crafting a profile for it that gives the reader the impression that they're some kind of medical professional. This is in effect what these medium bloggers do when they claim to be a "fullstack" developer specializing in RoR, JS, React, Node.js, etc. despite having only graduated from a bootcamp last week.
> While arguable not 'commendable' is it 100% of the time reprehensible?
I never said it was reprehensible, but it's unfortunate that the people whose voices are heard the most are generally the least worth hearing, that many of the best programmers never blog at all while these incompetents drone on and on, and that many of the best programmer blogs, such as Pershing on Programming, aren't read.
Either you believe that people have the right to air their opinion/experience or you don't. How accurate it may be is somewhat irrelevant. If they do have a blog, people can contact them or otherwise reply in public, calling them out should the be spreading BS. Who decides when people have enough of whatever quality you deem satisfactory to be allowed to share their thoughts and experiences with the world? People being full of BS is not a problem which is unique to the internet, it's just easier for them to post, and easier for you to ignore than someone standing yelling something at you.
Enable comments or post to Reddit. If you're wrong there are content editors roaming the web who are alarmingly well informed and fast, and free of charge.
I kind of agree with this. It hinges on what you mean by "blog".
Novice programmers should absolutely have journals, to synthesize and record what they're learning, and share those journals with other people to get feedback. I kept a journal on paper back when i was learning, and today, it would be natural to do this online.
However, novice programmers should absolutely not be giving other people advice on programming, or clogging up search results with basic and probably incomplete or incorrect material.
The trouble is that we don't have distinct mechanisms for those two kinds of public writing. We just have blogs. It's difficult for either human beings or search engines to reliably separate the wheat from the chaff.
At the very least they can share sources of information they found particularly useful or clear. They can do so better than you and I, to whom too much is now "obvious" - only by virtue of having internalized it a decade or two ago. Even novices can have cool projects to share on occasion.
Not to say there isn't plenty of junk that wasn't worth blogging, but I wouldn't go as far as "Novice programmers shouldn't have blogs."
Especially when the alternative to even the junk is for the same (mis)information to fester by word of mouth and the like - we're social creatures after all - where it cannot be corrected.
A junior developer earning 20k more based on a supposed 6 months experience?
If you want a better job, go get it.
This taught me perhaps the most important life lesson I've ever learned: if you want something in this life, you don't ask for it, you don't wait for it, you take People don't give you what you want. And being "deserving" or qualified for something isn't necessarily going to get you what you want. This applies especially to those complaining about making less income than a known fraud.: if you don't demand more money, no one is going to preemptively recognize your talent and pay you what you think you are worth.
As an aside, software engineers are the worst class of salary negotiators I've ever seen. 90% of all the people I've interviewed just accepted the job offer and salary right on the spot without taking time to think it over, mostly because their personality type wanted to avoid anything they perceived as adversarial.
+1 :(
To me, the best repo reviews I've done is when I see something that is real: many granular commits, some refactoring, some documentation (even if just a real README), etc.
I love the concept of online education, but I think modern online programming courses are just perpetuating this idea that programming is a skill you can master in a couple of weeks and then you're done. You get people following along a path with lots of hand-holding, and ending up with the same end product and no understanding of any of it.
I almost yearn for the days where programming was so impenetrable you needed to have a real calling for it. You were guaranteed to get people that were in it for the love of what they could do, not because they heard in some podcast that it's the new thing and decided to pay for an online course with the promises of making $150k/y.
Around here, the average salary for a software engineer is 60K/yr. I only came into the average after working for 2.5 years in the field (and after working for 1+ years self-teaching at home). Started at about half the average.
Where is it that people are paying junior developers 150K/yr?
When someone asks me for help with some practice problem they are supposed to solve on their own, I'm now trying to stick with never ever giving the solution. Instead, I give at most a description of the next step towards the solution. If they get stuck, it's sometimes really tempting to just show them the solution, but I think it is better to find out what they are missing and then give yet another explanation.
The process may take hours, and fewer people ask me for help a second time, but I believe this way I'm helping more than if I just did the work in 5 minutes.
It may be the case that fewer people ask you for help a second time, but that sound like an effective filter - people who actually want to learn will come back, but people who just want the answer won't.
If there's one thing I know, it's that most devs have a distinct style when they code. This is especially true with JS. I'm sure taking a cursory look at "Bryan's" code would have revealed it probably wasn't something he wrote himself since the copy/paste mode would reveal totally different coding styles.
> Within 2 days Bryan was terminated from his position and back to doing contract work in his old industry.
Thid doesn't seem to be very ethical thing to do.
What's the moral of the story? Don't be Bryan or else I might rat you out to your employer?
People have different ethics, so I hope we can all agree to disagree instead of starting an argument. But if I know someone, even if I don't like them, they're a friend. No matter what problem you have with a friend, you don't take that problem to their job.
Yes, he's a fraud. Yes, the truth was told. But I prioritize people I know and I don't rat out my friends.
that guy was not a friend, that much is obvious.
That's not the definition of the word "friend" as it is conventionally used. Sounds like the word "acquaintance" would be more appropriate to me.
What if one steals from his company?
What if one steals from your company?
What if one steals from your family?
What if one sexually assaults a child?
My friends are my friends because they are good ethical people. We don't always agree on politics or religion, etc, but we don't steal/cheat/defraud others. If I find out they do, they aren't my friends anymore.
First the guy had it coming anyway and should have seen it coming, that his disqualification would be hidden forever.
If the company had a live coding interview, his incompetence would have stood out immediately, if he couldnt come up with a FizzBuzz in his own free time
Also, the author acted negligent to his friend if he knowingly let him go into that mess without warning him about the consequences.
Maybe I'm interpreting the term friend wrong but the author should have warned him anyway that he is not ready, given what he'd known about the guy.
Harshly put: shame on the author to complain on medium when he perfectly knew that this guy was going to fail.
The author mentioned that they were meeting with them on a regular basis to teach them coding. I would assume that it is the responsibility of a teacher to keep up with what their student is learning. Not stalkerish or creepy at all; purely professional if you ask me.
I think they could have flagged the employer a little earlier though. I would have told my inside source about Bryan's actions before he even landed the job. That kind of shit is just not acceptable.
I'm pretty sure that's what most people do to other people's blogs.
> the superior hero
He was supposed to be a mentor (role agreed to by both parts). Checking on his blog, github and linkedin accounts is not obsessive. If my guitar teacher would regularly check on my progress and provide insights on my public compositions, I would be pretty grateful for wasting his time with a two dime player like me.
I don't see how it's sustainable but it's working for them I guess.
The key trick seems to be to find a position where it's more important to your boss to have headcount than to have productivity. For example, i once did a project with an outsourcing shop, who could put ten programmers on a project at a rock-bottom rate with a day's notice. It was vital to them to have people they could assign and bill for. Whether they were actually any good was irrelevant.
He outsourced everything he had to do that he didn't know how to do himself...
Sometimes I wonder what happened to him...
The supply/demand inbalance in tech just makes this much more common.
One thing we need to develop is the strength to not care about what the other person might think of you and confront such behaviour head on. In the best case, you'd be doing the candidate (and the industry) a favour if they realize and transform to be better. In the worst case, you haven't wasted anyone's time or energy. So we have to pick up a "I don't care if you call me a *&^%, but.." kind of attitude with this.
In one interview of a "certified" candidate, I'd realized that the candidate had discussed an answer to a question with one of the earlier candidates, but knew so little that answers to two different questions were mixed up. When I realized that, I told the candidate point blank that this wasn't acceptable and that I wasn't willing to continue with the interview and may the candidate please leave immediately. (I'm not describing it in detail enough to convince readers here, but the evidence of false competence claim was aplenty.)
So in the case of "Bryan", I read it as a lost opportunity for transformation.
So all other shortcuts are ethical, not lame, or ethical and not lame. Got it. Perhaps, though, the author takes shortcuts to punctuation and grammar. Perhaps the author meant "The only shortcut I could find, which is totally unethical and lame, is that of being a fraud." which carries an entirely different meaning in written English.
I started my programming career by working someone else job (he was in the UK). He was working for a media agency and had absolutely no clue about web development. I was probably getting paid 1/10 of his salary doing 80% of the work.
Funny thing is that a friend of mine at the time was making money doing home work for rich guys and writing thesis for incompetent students.
The world is far from being a meritocracy and god forbid you are living on the wrong side of the planet.
Six years later his fake MSc is still up there in LinkedIn.
Nobody asked for degree proof. Ever.
I used to be furious about it but nowadays I don't care much. I don't condone lying, but if he's still there having a good career he's either on par with someone legit or rather the company never really needed such profile to begin with.
Man, just think how much I could've saved on booze and cigarettes if I'd just made the whole thing up!
That's a shame, but let me tell you a slightly different story.
We needed to hire a chemist. We found a great candidate: 25 years in industry, five jobs (i.e. not a job-hopper; people had apparently found her competent), some of those jobs were where someone at the company knew someone there so we could check on her.
BS in Chemistry from university X. Hey, I attended university X and she was my year! I looked her up on the alum site maintained by the university and indeed, she had graduated with a BS the same year as me! But the BS wasn't in chemistry.
Clearly she'd been doing the job. And if she'd put her actual degree on her resume we would have been excited to have her in for an interview. But since she lied on the resume it went into the trash and she never knew.
If it's something like the latter, I wonder if this behavior is encouraged by our school system. The jr high/high school homework I hear about is mainly done by cutting and pasting answers, with no effort to learn or understand the content itself.
Differentiating subtle shades of grey is hard in an interview, given not everyone interviews well. However, it is possible to tell in black and white if someone has the most basic skills required for the job (which Bryan didn't).
I once was recruiting for a startup. The CEO and his partner who was interim CTO (I was coming on-board as CTO), had lined up a candidate. Conversation went like this:
Me: Before we go through a coding exercise, I'd like to talk to you about how you might go through solving a problem we set you, I just want to see if you have a process.
Candidate: OK
Me: So let's suppose I give you a problem that involves routing, and identifying the shortest route between two points on a directed graph. What's your first stab?
Candidate: So, first I'd look for a gem [we were a Ruby shop] to see if this exists already.
Me: OK, let's assume that the data structure is proprietary, we are going to import and maybe translate it, and as a result it's unlikely that for this specific type of problem there is no gem. What next?
Candidate: I'd have a look at Stack Overflow.
Me: OK, there can be good things on Stack Overflow, but like I say this, is proprietary - the best you're going to get is inspiration.
Candidate: Hmmm.
Me: How about doing a search through some data structure and algorithm books? What sort of thing might you look for?
Candidate: In my experience, everything is either a gem or on Stack Overflow.
Me: What if it isn't?
Candidate: It always is.
This is the most egregious example I'd seen of what Jeff Atwood had identified a decade ago: programmers who can't progam - https://blog.codinghorror.com/why-cant-programmers-program/
I wrote an email to the CEO and his founder that afternoon. The subject line simply read "[Candidate] interview: can't actually write code".
If you don't know how to start chipping away at a problem, if you don't have a fire in your belly to go dig in, then you're a fraud.
Nobody has all the answers. Nobody has memorised AOCP and every DS&A book written. The trick to not being an imposter is knowing you don't know, but that you have the means to figure it out even if nobody else has before. You want to go dive into the books, into the theories, into discussions with colleagues and everybody else you can find who might have a handle on it.
If you've got the appetite to learn at each step, you're not an imposter. You're in the same group of people as the pioneers of computing who didn't have any text books or resources to lean on, and nobody gets to call you an imposter, least of all yourself.
And yes, I get imposter syndrome myself sometimes, and sometimes have to remind myself of this, in a mirror, whilst worrying I'm about to get fired for not knowing it all perfectly.
I also contribute to things like Django precisely to enable me to work this way day-to-day -- I don't want to reinvent basic things over and over again, I want to pull a well-tested piece of code off the shelf and use it. And I'd likely no-hire anyone who insisted on doing real work the way we insist people work in interviews.
Web pages and data warehouse are not such areas.
Another useful skill to verify for non junior hires would be navigation through complex code, approaches to maintaining and improving code quality. Without enough people skilled in this, anything not tiny will drown in technical debt over time.
That is true. But if you look at the way some companies does interviews, they do seem to expect you to memorize a lot programming trivia.
If am to be honest, I have forgotten how to implement the shortest route from using a directed graph from scratch. But I am confident that I can easily reconstruct the implementation after I review the actual algorithm since I have done it before. I never had to implement it myself in production in all of my years of programming.
But then again, maybe I am just stuck on one of those programming jobs that are considered 'menial'.
Candidate: I'm not sure, I think I remember something about A* or something.
Me: Cool, that sounds familiar to me as well. How about we go google it up and then have a look at implementing it. Here's some source data that comes from our supplier, let's pair on getting something working...
And an hour later, we would have built something trivial but useful, and I'd be happy.
I've never known, because I've never had to do it.
What I do know is that I've read about Dijkstra's Algorithm solving a very similar problem. A quick Google leads me to Wikipedia, which has a section on specialized algorithms for directed graphs.
This is the type of background information and research ability I would expect from a developer, not that they would necessarily be able to recite the correct algorithm and implement it without checking a reference.
Stack Overflow (and Math Exchange) is a meagre source mostly useful for details and even then answers are very varying in quality, typically poor but a decent starting point for proper analysis.
Never take a ready made solution without understanding its limitations and important details. I've seen poor or cruft libraries used where better ones existed. Also second guess pulling a big framework whole. Something like Boost might have many things, but they tend to have important shortcomings, so might not fit. (Say, their parser lib, concurrency extras, matrix math)
Lastly if there is nothing useful, there are general ways to implement algorithms. If doing something yourself, take platform specifics into account if performance matters.
If I didn't know that term, then I'd search "shortest path directed graph". That leads to a Wikipedia article with links to a variety of algorithms.
Seriously, when was the last time you had to identify the "shortest route between two points on a directed graph"?
I find questions like this to be absurd and a baseless way to gauge a candidates ability. It's more mental masturbation on part of the interviewer rather than a useful way to assess a candidate.
One time, I had to solve a problem that was kinda in left field; I don't remember the specifics of it, but it wasn't something common.
I soon found that out when I did my googling to see if anyone else had a similar situation.
There wasn't anything on SO, and virtually nothing else on google.
So I broke the problem down, and tried to see if there were anything on any of the parts of the problem. That started to lead somewhere.
Eventually, after a few hours of digging, googling, SO hints, testing, and cajoling around the issues - I got something working. It was crazy - but it worked, and worked properly as what was needed.
...and for every part of it that wasn't original, I linked to the source where I got help/inspiration/code, because ultimately, the whole thing was a group effort (even if those other coders weren't physically there, they were mentally in some capacity, though they didn't know it!).
I'm not even sure what you were looking for. If I don't know any graph theory, then my first reaction is to google what you just asked: "shortest route between two points on a directed graph". Knowing graph theory sounds like "the means to figure it out" from the conversation.
If you think everyone needs to know graph theory to write code, then I guess that's a fine opinion, but that's not a widely held opinion. It's not common knowledge to people looking to join the field that you'd need to know that.
I specifically don't want them to know graph theory. That's the point.
If they did, I'd find another example they are less likely to know.
If I can't find one, cool, they can have _my_ job.
I just need to keep reminding myself that crap like this is going on so I don't decide that I really am an impostor, because holy smokes are the stories in here miserable.
And for the record, the first questions should probably be "For the scenario, how often would it be used, how dynamic is the data, and is there additional data that could be used for hinting/prioritization in a depth-first search?" Not that this would matter for a simple programming exercise, but those are things you'd want to know in a real-world scenario where you were needing to do this.
maybe read up on directed graphs and come with the algorithm by hand.
then write tests and try and pass them while i wrote the algorithm.
The useful question to ask is not "how do lousy coders get management jobs?", but rather "why does anyone think being a good coder translates to being a good manager?"
> My inside source told me that they felt that Bryan was not even a junior developer and that his solutions were all from StackOverflow. Apparently they gave hime 3 weeks to get his shit together or they were going to fire him. I divulged to my inside source that I wrote the fizzbuzz test for him and that he used AirPair for his capstone test. My inside source was furious and called the VP of engineering immediately.
Is it so outside the realm of possibility that the junior dev in question could've gotten their act together in those three weeks, or at least used that time to prepare a backup plan? Reaching out to your "inside" contact instead of confronting the dev (which clearly never happens in this story) is cowardly and sleazy.
I don't think shakycoder left Bryan out to dry so much as he just stopped enabling the habit. Bryan had already written the job off from my understanding.
I do agree that at some point shaky should have confronted Bryan - the unfortunate and disagreeable part of being a mentor is that sometimes you have to be unpleasant and confront people. But I don't think that Bryan lost the job because of the actions of shaky - Bryan lied his way into it and lied his way out of it, and it was just a matter of time until he was found out; if shaky were to have helped, they likely would have taken a credibility hit as well.
I hope the author does learn to spot this behavior much earlier on and confront their pupils, but Bryan made his choices on his own.
Dishonest practices are deplorable, and should not be rewarded/encouraged.
CASE B: [cut&paste]=>[appear to succeed]=>[cut&paste]=>[appear to succeed]=>[cut&paste]=>[get job]=>[fail]=>[decide to struggle to learn]=>[struggle to learn]=>[gain key insight ~instantly]=>[succeed]
Case A happens all the time; it is the standard process of learning.
Case B doesn't happen.
Moreover, by his fraudlent cut&paste antics, 'Bryan' has already told us one of two things:
* either Bryan himself doesn't believe that he can learn, so why should anyone else believe that he can learn?
or
* Bryan doesn't believe that learning is necessary, so why should anyone expect him to start now?
The ideal and fair solution (which won't happen) would have Bryan not only fired on the spot, but repaying the company for all wages and costs of all the time that everyone wasted on him, and delays in the project. Bryan was already treated far more than fairly, and the author was correct to provide the accurate background information on him.
There are also larger considerations than the fate of the fraudulent Bryan himself -- the rest of the team. Not only is he failing to pull his own weight, he is taking deliberate actions that impede the progress of the rest of the team. He cannot be gone soon enough.
[edit - typos]