
A Story of a Fraudulent Coder - signa11
https://shakycode.com/the-story-of-the-fraudulent-coder-d4c6fcf273f7#.6c4pnbe4x
======
ohstopitu
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? :/

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

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

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

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

~~~
AstralStorm
Also known as Dunning-Kruger effect taken to an extreme.

A little knowledge in a bad mental framework is a dangerous thing.

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

~~~
at-fates-hands
>> 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.

~~~
ashark
> \- Expert in MySQL

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.

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

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

~~~
edw519
_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.

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

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

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

~~~
3chelon
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.

~~~
bshimmin
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_

~~~
3chelon
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.

~~~
awjr
Primarily it's the fear of being asked back in a couple of years to add
features to your own code ;)

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

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

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

~~~
HeyLaughingBoy
_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.

Consider this life advice.... or not.

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

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

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

------
crispyambulance
I think "Bryans" are actually quite rare.

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.

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

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

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

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

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

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

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

------
roddux
Moral of this story is that shakycoder needs to find a new job.

A _junior_ developer earning 20k more based on a supposed 6 months experience?

~~~
unreal37
That was an odd part of the story. If you make less than someone, you're not
really "mentoring them" in that.

~~~
pyro2927
That part read as jealousy to me. I have some friends who make more than me
and I do nothing but congratulate them.

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

~~~
unreal37
He wasn't "lucky" to get a better job. He got it. It's not a lottery. You
apply, and someone hires you.

If you want a better job, go get it.

~~~
pakitan
The "lucky" friend was just for juxtaposition. The point of my post was not
about the role of luck or lack of it in getting a job.

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

~~~
SoftwarePatent
> software engineers are the worst class of salary negotiators I've ever seen.

+1 :(

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

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

~~~
79d697i6fdif
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

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

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

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

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

~~~
at-fates-hands
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.

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

Thid doesn't seem to be very ethical thing to do.

~~~
bvinc
No one else seems to agree with you, but I 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.

~~~
valuearb
You don't rat out your friends?

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.

------
zython
I don't feel sorry for anyone involved.

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.

~~~
unreal37
He wasn't a "mentor" in the true sense of the word. Just a random guy he
helped a few times. That's not a mentor.

~~~
zython
His honest opinion would have costed him no time or effort, and would have
saved him an angry rant on medium.

Harshly put: shame on the author to complain on medium when he perfectly knew
that this guy was going to fail.

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

~~~
holtalanm
How is this creepy at all?

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.

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

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

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

------
basicplus2
I knew a guy who was an electrician who bull dusted his way into an electrical
engineering position.

He outsourced everything he had to do that he didn't know how to do himself...

Sometimes I wonder what happened to him...

~~~
hardlianotion
Management material, surely.

------
mathattack
I've seen this in other fields too. The ones who managed to get by in school
by cheating rarely ever revert back to hard work.

The supply/demand inbalance in tech just makes this much more common.

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

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

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

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

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

~~~
bshimmin
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!

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

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

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

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

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

------
jlebrech
I sometimes feel like i'm Bryan
[https://en.wikipedia.org/wiki/Impostor_syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome)

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

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/](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.

~~~
arvinsim
> 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'.

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

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

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

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

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

------
anilgulecha
One of the reasons technical screening interviews ask you to reverse a linked
list.

------
GrumpyNl
Great read and this happens a lot.

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

------
gcds
Man this is good story :D

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

~~~
throwanem
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?"

~~~
arvinsim
We wouldn't probably have this discussion if coders are paid as much as
managers.

~~~
flukus
It's not just the pay but the org chart. Managers can over ride coders on
technical issues.

~~~
throwanem
The same managers who have no idea why their best performers regularly quit
out from under them.

------
thesmallestcat
I'd rather be a fraud than the sort of guy who goes out of his way to get
somebody fired from their new job.

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

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

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

[edit - typos]

