A few friends of mine did exactly the same. They still have their jobs (btw, both are Software Engineers).
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? :/
Don't be disheartened - most industries are like this, and it even has an idiom "fake it till you make it".
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.
I get what you're saying here and agree with it, but I just wanted to make a minor point about "fake it till you make it." FITYMI was never supposed to be a synonym for "misrepresent your credentials and lie about your experience." In other words, it's not related to scamming people, but rather avoiding the self-fulfilling prophecy that results in lacking confidence or being a failure.
I agree, FITYMI is one of the most missunderstood mottos of all time. It has to do with changing one's mental state about something in order to achieve that thing rather than framing someone about what you are capable of.
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)...
> It has to do with changing one's mental state about something in order to achieve that thing rather than framing someone about what you are capable of.
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.
I've noticed a rather sad correlation of passionate software developers that are interested in the trade with low pay. At this point, I don't even know if employers are legitimately interested in "hiring the best". In my experience companies that aren't Google or Microsoft generally just want to hire the cheapest possible labor. If they luck out and get a strong engineer that can't effectively negotiate for themselves, that's just the icing on the cake.
Note that I'm currently doing software development in the Midwest, so my view may be biased.
Having worked in the Midwest, I had a lot of terrible experiences I haven't seen replicated on either coast.
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.
I've noticed a rather sad correlation of passionate software developers that are interested in the trade with low pay
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.
I'm still looking for a dev job in Columbus, OH where I can be part of the engineering team, and not part of IT. Seems that all of the dev jobs are in the IT cost center around here.
While it is dishonest to claim credit for the Fiverr job, isn't it a smart thing to do? I mean if this person was in management instead and said "we can outsource this on Fiverr and save a ton of money instead of hiring these devs fulltime", they'd get a bonus, no?
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.
> While it is dishonest to claim credit for the Fiverr job, isn't it a smart thing to do?
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.
To ask if it is worth it, one must ask what is the risk?
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.
If maintaining the illusion requires unauthorized outsourcing of work (and, therefore, exfiltration of proprietary company information to third parties), then the risk extends beyond losing your job.
In 99.999% of cases where they find out, the only downside is you'll be fired. Could they sue you? Of course. Will they? Almost certainly not. What would it get them?
So yes, the only reasonably foreseeable risk is losing your job.
People do all sorts of crazy things for 100 bucks. If you fraudulently get a job as a programmer you might be making thousands and thousands more than you would otherwise. It's not hard to see the incentive.
A surprising amount of people do :( , and there have been a few very high profile cases where they're found out, like Yahoo's CEO and Uruguay's vice president. There are even cases of fake doctors.
I'm not him, but here's one good answer: who wants to work for a company populated with frauds and run by idiots who don't know how to hire or manage?
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.
It could be, but I don't think this is good evidence for ohstopitu being underpaid. One way terrible companies get people to join despite being terrible is by paying more.
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.
> but I don't think this is good evidence for ohstopitu being underpaid
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.
This was really common during the first Internet bubble – I remember being on the phone a number of times with a whole room full of people worked on a household-name .com and realizing that maybe one of them had more than a superficial understanding of how the web or commerce worked. Several people basically stated that they were just killing time waiting for the IPO.
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.
This is probably more possible now given the ease with which a fraud can get someone else to do their work for them (I remember a news story doing the rounds of an experienced developer doing all of this and outsourcing all their work to India).
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.
Either they will eventually learn and become competent while faking it or they'll implode spectacularly. Either one of those outcomes is nearly a given.
It doesn't matter if they implode: they will immediately start mail-bombing a thousand companies (for they don't care about the company purpose, the job content or anything) and will eventually get hired at one of them (and more easily than the first time because they can now put a company name on their CV).
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.
Why is that unfortunate? That's the entire purpose of high prices: To alert others that supply is not keeping up with demand and that their help is needed. Choosing a job, or anything else, because of "big bucks" is exactly what "big buck" offers are meant to achieve.
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.
I've seen similar cases, and while they may appear to be successful for astoundingly long periods of time, ultimately most (unfortunately, not all) of those guys will fall on their face.
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.
>Both graduated 4 years later, just as clueless but with degrees.
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.
Also in some places you can get through most of the assignments by either being in a group or copying and pasting the relevant algorithm from the Internet
Does it really work like that in the Valley? I might have to come out there. Where I'm at, it's mostly big established fortune 5's. they hire they're fair share of idiots with degrees but I'm not sure you'd be able to make it by outsourcing the Fiverr.
I don't see what this comment brings to the discussion. I think it's obvious that the salary discrepancy and the skill discrepancy don't match up. Since salary defines 'market value' of a developer it's worth exploring why the market behaves this way. And I say this as a developer and also as someone who's got input on hiring decisions.
Something you didn't mention is the huge amount of pressure on "junior developers" to meet requirements like "5 years of experience in X, Y, and Z."
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.
>> Something you didn't mention is the huge amount of pressure on "junior developers" to meet requirements like "5 years of experience in X, Y, and Z."
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.
When I have looked for jobs in the past, I will sometimes apply for positions like this even if I don't have all the requisite skills if the job looks particularly interesting otherwise. I have found that these kinds of postings typically come from a communication error between the technical manager and HR. If you can get past HR and to the manager they are typically much more realistic, and are totally fine if you don't know technology x, y, or z as long as they feel comfortable that you can learn it, and you are strong in at least one or two of the other areas.
Eh. As much as we like to complain about it tech is still one of the most meritocratic fields out there. If you can code you can get jobs. And as someone who's done a couple hundred interviews I don't really care what's on someone's resume. If there is a correlation between a good resume and good coding skills it's pretty weak.
As much as we like to complain about it tech is still one of the most meritocratic fields out there.
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."
I can concur with that last part. One of the strongest developers I've ever hired had one of the worst resumes. If it weren't for the fact that he had a friend on the team who vouched for him, we'd have never bothered with the interview.
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."
This could have also been entitled, "A Story of an Incompetent Screener".
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 only need to see a very small sample of work done just for me.
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?
That is how you find you what a programmer can do, not by looking at some repository without context.
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.
What's frustrating for me is I tend to choke in high-stress situations like this.
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.
What's frustrating for me is I tend to choke in high-stress situations like this.
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'd rather find this out in an interview than during a critical sprint.
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).
Yeah, as another commenter said, an interview is not the same as a critical sprint. I don't mean that I find coding stressful, I mean that I find the social aspect of being interviewed stressful, and it's hard for me to get in the problem-solving state of mind when in that situation.
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.
> By not looking at their GitHub at all, you're invalidating months/years of open-source work
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.
Practice, he just said fizzbuzz is a good example, if you choke up implementing fizzbuzz and consider it high stress situation. You don't deserve to a job, not even as a junior. I can understand if you were told to implement a red-black tree or some esoteric algorithm.
You misunderstand. I don't mean that fizzbuzz is so challenging that it causes stress. I mean that I have social anxiety that causes my brain to not work during interviews.
Doesn't matter how good you are at coding if you're having a panic attack.
You would never hire somebody like me :). I write code in IDEs usually, and never basic console apps. Always inside of a framework or a bigger project.
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.
> I don't even remember the calls to string split and console display in some of my favorite languages.
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.
> I don't even remember the calls to string split and console display in some of my favorite languages.
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.
This is exactly the same format I've used, with two exceptions: I _do_ look at previous work, and the "custom project" isn't done in-person to keep it low-stress. This allows me to draw parallels in terms of patterns used and other commonalities I can then further ask about and reference while going over the "custom project" for the interview, without giving an opportunity to overwhelm them with anxiety.
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.
Yes, github can be falsified, but that doesn't mean it's useless. It's really not that hard to look at a repo and figure out if the things there are likely to be real or not. Is it an absolute guarantee? No. Should an extensive github history be an absolute requirement for jobs? No. But it can be a tremendous source of signal if you spent a few minutes actually looking at commits to find some evidence that the person has committed non-trivial code for a project that is not something generic that could be found on StackOverflow.
I don't consider github to be a requirement and am completely open to hiring people who don't have any work on github. I view github code as a sanity check that helps me reduce false negatives from the other steps in the hiring process.
That's rather interesting. I've actually found that reading code on someone's github or checking out their personal website is great for ruling in/out candidates.
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.
Here's a question - to you and anyone else who cares to respond:
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...
Wouldn't change a thing. No sane interviewer would think you're claiming your fork of a repo is your own code. Not to mention it's mostly used as a talking point for me, so if I did make that mistake I'd be fine when you said it was a fork. That's pretty interesting to me as well, so it opens up an avenue to have a conversation about why you liked that project, why you want to emulate it etc
do you search for code theft? 80% of the code submitted for my interviews is 100% copy and pasted. When they put in effort, they remove the comments and rename the variable.
I had a similar experience, but the guy didn't get that far. We were still at university when I was approached by him.
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
incantation like a religious verse and was quite proud of its recital. So I asked him what the result of
int four = 4;
four = 5;
in Java would be. He was unsure whether this was an error or whether the result would be nine.
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.
To a certain extent, as a contractor, I sometimes feel like a fraud. Primarily because every place I go to people do things differently. Do I change it for the better? No. They have their development 'pattern'. I adapt to fit their coding style, technology base, and more importantly, their working pattern without criticism.
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.
Well said. One major difference I've noticed between contract and permanent developers, esp. senior ones, is humility.
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 don't know... I've met some absolutely maniacal contractors too.
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
Yeah, I've seen contractors walk into the PM's office on day one and tell them how they should be running their project to be fired an hour later. I never get that attitude. Then again I do get extensions on a regular basis ;)
Yes, I agree not all contractors can see the bigger picture, and some of them can be pretty opinionated. I met one just recently. I guess that's the flip-side.
But most good contractors in my experience are acutely aware of the restrictions and realities of dealing with living, evolving codebases.
> 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".
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.
I've noticed an interesting parallel with musicians.
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.
> I adapt to fit their coding style, technology base, and more importantly, their working pattern without criticism.
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.
The author was far too generous with that guy. I actually think that this SV mentality of helping others (to that extent) is morally wrong.
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 actually think that this SV mentality of helping others (to that extent) is morally wrong.
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.
Well I guess I must be very unlucky then because my experience of the system is that nobody will give me anything unless they are legally obliged to do so.
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.
nobody will give me anything unless they are legally obliged to do so
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.
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've worked with someone like this. This person had a higher education in computer science and provided an alledgedly great (never saw it myself) graduation project in C#.
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.
Even better than a whiteboard fizzbuzz, do fizzbuzz on an actual computer.
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.
Computers aren't ideal for interactive interviewing situations either. The problem is that when operating a computer, people tend to have trouble keeping up a conversation (thinking out loud) at the same time.
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.
However, such filters can go top far if you receive an automated (!) test where you get to correctly parse two (!!) pages of text and then it is still not clear.
15 years ago I had a boss who hired someone from the local state university with a degree in CS who was (allegedly) a defense of his thesis away from a masters in CS.
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.
> I kept an eye on his blog and he was publishing a coding tutorial every week
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.
Posting and sharing your experiences can help you reflect on where you went wrong, and what you did right. This is a perfectly valid thing to do. If your beef is people posting content about which they are ill informed, that's >90% of the internet.
> Posting and sharing your experiences can help you reflect on where you went wrong, and what you did right.
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.
> how do you really know what you did right? How do you know your advice isn't leading other novices astray?
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?
> should nobody be able to write their opinion about a sporting event
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.
> Novice programmers shouldn't have blogs. A blog is a public platform, a soapbox, for sharing your thoughts.
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.
>> if you're a novice, how do you really know what you did right?
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.
> As a novice, your thoughts likely aren't worth sharing and might even be harmful.
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.
Putting right or wrong aside, blogging has one crucial benefit: it's practice for explaining your code to other people. That's a critical skill you'll need throughout your career, no matter your level of talent.
We hired a support staffer, Kevin, with a good amount of C experience on his resume, but he didn't need it on our job. Months later, a junior guy started and needed a little help with some C code so we had Kevin help out. Hours later a DBA sitting near them comes over and tells us they've spent almost an hour trying to figure out how to printf() a variable's value but can't figure out where the quotes go. Unsurprisingly, the rest of his resume didn't hold up very well either.
It is jealousy and it's fully justified jealousy. It's not just some buddy who makes more than you, because he was lucky getting a better job. The person in question is incompetent, 100% not fit for the job, a fraud and adds negative value for the company. Would you be happy and congratulate him on making more than you do?
A friend of mine who I mentored did almost the exact same thing. He was attracted to the high pay, relaxed dress code, and flexible working hours. The difference is he saw what an amazing point in time it is to be a software engineer and understood that the facade would not last long. So he turned his lies into truth. In the interim between being hired and starting the job (2 weeks), he spent over 100 hours coding, reading, pestering me and basically everything he could to become more proficient in LAMP and bash. I helped him and hoped for his success because (1) Schadenfreude is something I avoid and (2) Whenever we hung out, drinks would be on him
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.
I've seen more and more of that behavior where people will just dump someone else's code into a GitHub repo and call it a day, assuming it'll look great when someone reviews that. I instead normally look at the commits and it's pretty obvious when something was not actually made by them, or what little changes they did to someone else's code. Even easier if you look for little snippets of the code and find it replicated somewhere else; a good indication it's just some online tutorial's code.
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.
I can't image anyone paying someone 150K/yr that has little to no experience, or is just a 'bootcamp' coder.
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?
If you're in the US ur gettin ripped off. I live in a really low cost of living area and make around 70. Most of my friends with 3+ years make around 90
That's not what's happening (in theory), it's what's implied in a lot of these courses' promises. Some people see "average" salaries for engineers in NY/SF, and assume they can take a quick 2-month course and join in the fun.
Nice story but I find it hard to believe you would keep helping this person after it was obvious they were looking for someone to do everything. The author should have quit long before some poor employer got stuck with them. Being a mentor is one thing, being an enabler is another.
It may appear obvious to you, with the benefit of hindsight and a condensed explanation. As someone who has been in superficially similar situations, it can be hard to tell the difference between someone who only wants some help learning and someone who wants to offload all the work.
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.
I also think this is the right way to do it. But moreover, i thought this was well-known to be the right way to do it. After all, if you ask your teacher for help with something at school, do they tell you the answer, or write the essay for you? No, they point you in the right direction.
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.
Yes that makes much more sense. Implementing a simple exercise for someone teaches them nothing. Helping them understand why theirs didn't work is much better.
This article just shows that the company had a really bad hiring process.
I think this also shows why on-site technical interviews are so important.
In my 2 years or so of taking interviews it took me 10-15 minutes to see whether someone was competent enough to write code.
On the plus side, on-site interviews also help you in determining whether the candidate will be a good cultural fit or not
Even just looking at the github repos would've revealed what he did.
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.
> 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.
> Within 2 days Bryan was terminated from his position and back to doing contract work in his old industry.
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.
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.
This is a really creepy article, the level of obsession and stalkerishness exhibited by the superior hero writer is borderline disturbing. How much free time does one have to stalk someone's blog they don't even know and do the internet detective nonsense required to make sure they can talk trash about every aspect of them? So creepy.
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.
We got hit by a fraudulent coder recently when we tried to hire a contractor to help out on a short-term project. Went through an agency and interviewed several of their developers via telephone and screen sharing until we found a competent one, but never brought him in for a face-to-face interview. Then when we hired him and he showed up in the office we figured out after a few days that he was completely incompetent. Turns out it was a different person! I'm not sure whether the agency orchestrated the fraud, or if that individual contractor just had one of his friends do the interview for him.
I know of two guys who routinely get high paying senior jobs but can't code their way out of a paperbag. One of the guys I have worked with at two different companies. He just pops up, works for 6-8 months always needing help and never meeting deliverables then he leaves for his next job. Rinse and Repeat...all the while making 6 figures
I don't see how it's sustainable but it's working for them I guess.
I've run into a few people like this, who absolutely can't code, but have some skill at hiding it by getting help, copy-and-pasting, finding other 'useful' things to do, etc. Some of them have had quite stable careers.
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.
Why should they ever stop? The sad reality is that cheating and fucking people over is exactly what most management structures incentive. Hell, it can get you all the way to the Presidency if you're shameless enough...
I was curious about this post as I've come across a couple such cases in my own experience, though my interactions with them were not so deep.
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.
"The only shortcut I could find which is totally unethical and lame is that of being a fraud."
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 think the OP is a bit jealous of "Bryan". And "Bryan" gets 20k more in salary than the OP (supposedly an experienced developer) just doesn't add up to me.
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.
I have a friend who lied about having a Master's degree in CS and went on to become a software engineer with an income way above his education level.
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.
I have a BA (Hons) and an MSc and I don't think anyone has ever asked for proof of them - certainly not in the last decade, but I also don't think even my very first "graduate" job (specifically advertised thus) required any sort of proof.
Man, just think how much I could've saved on booze and cigarettes if I'd just made the whole thing up!
> Six years later his fake MSc is still up there in LinkedIn.
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.
The only time anyone ever asked to see proof of my degree was when I was buying car insurance and the company was offering a discount for STEM degree holders.
Neil Gaiman once said you only have to nail two out of the three following traits: be nice to work with, be on time (deadlines) and be talented. If you're talented and you're nice to work with, you can be late all you want. If you're on time and you're a delight to work with, you can get away with being a mediocre talent. And finally, if you're talented and on time most people will let slide the fact you're a bastard.
I went ahead and bookmarked this. Now, whenever I'm feeling the effects of impostor syndrome, I can just click on the link on my bookmarks toolbar and instantly be reminded that no, I ain't the impostor.
I'm curious, what's the fraud's mental model of what he is doing? Does he know he is cheating, and is he telling himself that's what he has to do to survive? Or does he not actually know that the code has meaning and that he can't, in general, cut and paste to solve a problem?
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.
This sounds a lot like the startup didn't do some basic due diligence on his submitted work in an interview.
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).
A good share of recruiters and some managers are frauds too, so how would they tell? And if they realise it after it is too late, they cannot ever expose the con for it would reveal that themselves are frauds as well.
Good read that I think most with some experience in this field can relate to. I do think that you were too easy on him from the start. No point in letting all those mistakes slide, you are certainly not doing Bryan nor you a favor.
Unless your only solution to a coding problem is to find somebody else who has solved, or will solve, the issue for you, you are not an imposter.
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.
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.
> 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.
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'.
> If am to be honest, I have forgotten how to implement the shortest route from using a directed graph from scratch.
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.
Even for this, search engines are a good starting point. You might want to look for libraries under a suitable licence, for algorithms in both wiki and research papers, lastly in a book. If it is some implementation detail first docs then sources. If that fails, look for a blog (weirdness is often blogged about), only finally ask a friend.
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.
In my experience, finding the right search terms is 80% of the battle. Knowing the phrase "Dijkstra's Algorithm" is a big leg up here, and would put me only one or two degrees of separation away from the correct answer.
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.
Exactly, so the way that interview should have gone is something like:
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.
>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.
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 think the candidate gave you perfectly fine answers. Virtually every problem is on S.O. - and if it isn't, there is usually something superficially related to get you started. I don't remember the last time I opened my copy of Introduction of Algorithms and implemented something from there. I do, however, look to S.O. multiple times a day.
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.
> Virtually every problem is on S.O. - and if it isn't, there is usually something superficially related to get you started.
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!).
The goal is not to reduce it to simple trivia, but rather to tease out the process to arrive at the answer from the interviewee. If your answers to a question are basically forms of "get help from someone else" without even considering the problem, that doesn't bode well.
I have got to get back to doing development instead of generalized IT consulting (aka small business support & admin).
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.
I've done this to annoy recruiters and interviewers, and to make a point about the stupidity of popular interview processes.
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.
Depends on what you're doing, if the problem domain is relatively exotic, you might want people who can handle work from scratch.
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.
I read things like this and wonder how long we have until one day shit hits the fan and causes a chain of events that will eventually put regulations in place on the entire industry.
No, I never did a degree and I am in this industry deep for many years, and I love it. Leave it alone - just hire better, I am sure recruiters can improve on it.
Some people have a cheating/shortcut mindset which is pervasive in every aspect of their life. He was probably cheating in his job as a contract manager as well. His former coworkers were probably happy to see him go, since they had most likely been doing his work.
Sounds like Bryan should apply for a managerial job, not a development one. Nine out of ten IT managers I've met can't code shit. How exactly did they get the job is one of the great mysteries of our world.
Management and development are largely disjoint skillsets, which is why it's so rare to see a successful transition from the latter role to the former.
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?"
I didn't say that a good coder should translate to a good manager. But a good IT manager should know how to code, or at least use to know. Otherwise, how can he estimate whether project managers are jerking him off or not?
By comparing actual with predicted results, I should think. I'm not sure how past programming experience, most likely in an environment very different from the one in which one's reports operate, necessarily translates into a close understanding of how one's reports go about actually doing what they actually do.
Did we read the same story? It seemed to me that he went out of his way to not get Bryan fired, despite knowing that Bryan was doing unethical things. When he eventually spilled the beans on Bryan's behavior, it was when Bryan was already on a 3 weeks notice to get fired.
> I had to make a decision with Bryan and fast. So I decided to ignore him on Slack and just let him fall on his face. If my mentor found me doing fraudulent shit like this, it would have been 10x worse. Blacklisted and booted permanently...
> 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.
CASE A: [Struggle to learn]=>[Succeed a bit]=>[Struggle to learn]=>[fail]=>[struggle to learn]=>[fail harder]=>[struggle more to learn]=>[gain key insight]=>[succeed]
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.
I think you're misreading the last section: the inquiry to the inside source came after Bryan was looking for another job already and moving on.
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.
I've felt the same way as the writer myself. There is an immense feeling of betrayal when you are a mentor and your protege decides to cheat instead of learning what you are teaching. They begin to try to use you like "Bryan" used his mentor. If you did help them cheat, you feel dirty and put-upon. I don't think the mentor went out of his way to destroy a promising career. He had to do what was necessary to allay the negative feelings he felt, and he couldn't get over them any other way. You might have been different and just dropped communication and went on with your merry life, but it's Bryan's fault for abusing his mentor, not the mentor's fault for restoring balance.
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? :/