
The myth of the developer that can't code - nsainsbury
https://www.neilwithdata.com/developer-myth
======
gregdoesit
This article is full of opinions, and brings no facts to the table. The author
does not mention his experience interviewing or hiring people, and the whole
piece reads more like a rant.

> When an accountant is in an interview, they're not asked to multiply on-the-
> spot in their head what 485 x 761 equals because "you have to be good at
> math to be an accountant"

This is an ignorant statement. Accountats don't have to multiply things in
their head day to day. Yet developers do need to code, day to day.

I'm a hiring manager and the reason people code on interviews is - well, after
joining a company, the first few months they _will_ spend a good chunk of
their time coding. And the companies I worked at, who dropped the coding
interview always regretted it, through mishires. People who could code, but
were not very good at it. E.g. their code was sloppy, incorrect and they
needed considerable mentoring and coaching to write code that worked. As
senior developers.

The other reason is to even the odds. 70% of people I've seen hired did not
have public Github profiles or code they could show. The people who complain
about "why can't they just look at my portfolio" and (potentially rightfully)
conclude that they're amazing developers don't realize that this approach
would result in more bias for hiring this group of people. Good luck
maintaining a fair hiring bar this way or hire diverse candidates.

This is why the coding test exists in most places. It's to test for something
that you're expected to do from day one and to even the bar that people need
to jump through, for everyone.

I'd love to hear what OP suggests to replace the coding tests with - a chat
about past projects, then make an offer? And what do you do with the people
who don't have these things to show?

~~~
seanmcdirmid
The coding tests in many places no longer test coding. They test algorithms,
dynamic programming, or how to deal with ambiguity for an incredibly under
specified problem. They are useful in weeding out 80% of the candidates who
are clueless, but they don’t provide much reliable distinguishing signal for
the 20% that remain. The coding interview isn’t going to tell you the
difference between a junior or senior dev. Heck, given that universities prep
kids these days for google style leetcode interviews while a senior dev lacks
the time for full time prep, junior devs are likely to do better on it.

~~~
zimpenfish
> They test algorithms, dynamic programming, or how to deal with ambiguity for
> an incredibly under specified problem.

I've been doing this for 25 years now and I've never had to implement an
algorithm[1] from scratch or do any dynamic programming. I'm not entirely sure
I'd consider myself "clueless" because of that.

[1] In the traditional computing sense of the word

~~~
leethargo
I've been implementing Dynamic Programming, from scratch, just yesterday. But
it wasn't for work either.

------
7777fps
Accountants, Lawyers, and Surveyors have credentialling bodies that train,
test and monitor performance.

Accountants don't need to show they are qualified in interview because they
have the letters ACA, ACCA, CEMA or whatever that they can clearly point to.

Lawyers and Surveyors similarly have profession bodies that handle
qualification.

Software engineering is not uniquely broken but it is broken, but the author
jumps to the wrong conclusion.

The other engineering and professional disciplines have professional bodies
who have official qualifications.

Software engineering has never solidified around any particular set of
qualifications and many think they are not relevant.

And artists are often asked to do some initial work for free before a client
commits, they often end up doing a lot of "wasted" work for free without
getting properly compensated, so it seems odd to argue that's a model that
software should look toward.

~~~
pjc50
Software has a couple of unique problems which prevent those from working:

\- the state of the art is both extremely diverse and rapidly moving, so any
credential system would run the risk of being too specific and easily out of
date. Very few are respected and most existing ones are tied to particular
products. Possibly the only set of those that is respected is the Cisco ones.

\- most of our work is (a) tightly intermingled with the work of others and
(b) copyright belongs to our employers, so we can't build portfolios like
artists. Many people have contracts that purport to own all code produced,
even in your spare time.

It would be _great_ if we could take all the basic tests once, upfront, under
exam conditions, and then re-use that for years. I can't see how it can be
coordinated. Maybe what we need is not a union but a professional body. In the
UK we sort of have one (BCS, and more absurdly, the Worshipful Guild Of
Informational Technologists) but their impact and benefit is also pretty tiny.

~~~
toyg
_> Possibly the only set of those that is respected is the Cisco ones._

And that just because their stack is slower-moving. This is a problem that
unfortunately is not going to be solved anytime soon, I fear. As industrial
revolutions go, we are still in the "mad inventor / amateur / visionary"
phase, really. It will take another 50 years before the field slows down
enough to solidify into a consistent curriculum.

 _> we can't build portfolios like artists._

That's basically what personal Github accounts are, de-facto.

~~~
pjc50
Yes, but that's not your "professional" work (which is copyright your
employer), it's your "amateur" work done in spare time. Which is a pretty
exclusionary approach to hiring.

It would be very different if more employers paid more than lip service to
professional development and encouraged the publication of personal githubs on
"work time" as part of that. It sounds like (some of?) the big Bay Area
companies do, but those are the ones _after_ the big hiring barrier.

The actuaries I know spent a lot of time on exams, but also in their early
years got some time set aside by their employers for that.

------
thayne
As someone who didn't major in CS, the technical interview is the reason I was
able to get a job. I didn't have ton of professional experience, and I didn't
have a degree in a directly relevant field. But in a technical interview, I
could show that yes, I really did know how to code.

I did have a "portfolio" of projects on Github, but it wasn't very large, and
the most interesting project there were, well, too complicated for an
interviewer to understand in short amount of time. And what about people who
don't contribute to open source, either due to lack of time or desire? What do
they have for a portfolio?

Don't get me wrong, technical interviews certainly aren't perfect, and there
are a lot of ways to improve them. But I think they should be improved by
making them measure what an developer actually does, rather than removing them
altogether. In fact, I would say that if accountants (or any other technical
profession) aren't assessed on their technical ability as part of the
interview process, maybe they should be.

~~~
Cthulhu_
This is the shift that happened in the 8 or so years at my previous job as
well. It's a consultancy company, and when I was hired there it was more of an
experiment - a traineeship, if you will. Their hiring practices were basically
a minimum of 5 or 8 years of professional experience.

While I was there they shifted their hiring practices, focusing instead of
merit and the results of a technical assignment and interview. We ended up
hiring early 20-some year olds fresh out of college because they wrote great
code and could explain it to us. I mean we've had some people that made a
solution that sorta worked but couldn't really explain some of the work they
did, or the underlying logic behind it. Some had great CVs (I mean that's the
first check), but there wasn't any skill behind it.

------
axegon_
I have to disagree with that statement. There are such and I've worked with
such far more than I'd even want to imagine. There have been entire releases
where I've had to re-do everything they've done from scratch because code
reviewing simply wasn't going to cut it: Spend 2 weeks explaining what they've
done wrong and then reviewing it all over again from scratch while the
deadline is right around the corner. In their final months they were literally
given nothing to do because we couldn't allocate the resource to clean up
after them. But I'd have to quote Niki Lauda for those particular individuals:
"At some point, it's no longer a question of experience, but a matter of
intelligence".

~~~
toyg
The point of TFA is that this sort of people exist in any profession. I can
assure you there are plenty of "bad" accountants, or the taxman would not have
to spend billions to review tax returns. There are plenty of "bad" lawyers, or
we wouldn't have mistrials and wrongful convictions. And let's not even look
at anybody involved in real-estate processes. And still, the hiring process
for professions that are much more critical for everyday life than
"guaranteeing cat videos download on time" is _much_ more forgiving.

~~~
axegon_
That is true, though I must also add that some of the ones in question came
from prestigious and world renowned universities. Once you'd struggle to get
in(in theory apparently, because otherwise I have no idea how that works).
They all had the "senior developer" in their titles with near or double digit
years of experience.

------
greenyoda
> But I suspect there are no more developers that cannot code than there are
> lawyers that don't know the law...

I suspect that's wrong. To get a job practicing law, someone generally needs
to have passed their state's bar exam. Similarly for other licensed
professions like doctors, CPAs, civil engineers, etc. But anyone can legally
call themselves a software developer.

~~~
c3534l
And if you want to be a firefighter, you have to pass fitness tests and climb
ladders and stuff. If you want to be an actor or musician, you have to
audition. The employer wants to know what you know. I guess maybe some people
think of these these tests as pass/fail where if you forget a semicolon you
"failed" the whiteboard interview. Any job where you don't have a degree or
professional certification guaranteeing a bare minimum of knowledge will ask
you to demonstrate your abilities and what you know. The fact that you don't
do that in some professions is more of an indication of how hard it is to test
without a comprehensive knowledge-based examination. Software development is
not unique. If you say you're qualified for the job, you have to demonstrate
it somehow.

------
meritt
I know these feel-good anti-whiteboard blog posts are in vogue right now, but
the harsh reality is we're entering a recession. If you refuse to do
whiteboard interviews, or complain about employers who want you to work hard,
or only looking for jobs that'll let you unnecessarily rewrite their stack in
Rust on k8s, or feel that FizzBuzz is beneath you: you're gonna be in for a
rough couple years.

~~~
seanmcdirmid
I don’t feel like fizzbuz is beneath me, but Alien Dictionary is annoying the
10th time you are given it. Thankfully I got an offer from Google a couple of
weeks ago, but I did spend way too much time doing interview prep.

------
ukoki
I'll take coding interviews over expensive qualifications, work history and
nepotism any day of the week.

Let's say I give candidates a basic whiteboard problem that requires no fancy
algos/data structures other than knowing about arrays and dictionaries. A
passing candidate will demonstrate the following attributes:

1\. Understands basic programming constructs and elementary data structures
(loops, vars, arrays, dictionaries)

2\. Can model problems in her head

3\. Can communicate effectively

4\. Can work well under the pressure of an interview environment

So it's process that selects candidates that have desired attributes 1+2+3 but
the downside is that it also selects irrelevant attribute 4

This is a pretty good system! Sometimes it will fail because candidates will
be rejected for lacking 4 even though I don't care about it. Is there a better
system? I don't believe that just looking at resumes and past experience
selects for 1+2+3 nearly as well.

Furthermore I've said that "works well under the pressure of an interview" is
an irrelevant attribute, but I think you could also make a case that it is
weakly relevant in this way: if a candidate can do 1+2+3 while under pressure
then you would expect them to perform 1+2+3 as well _or better_ when not under
pressure.

There is also desired attribute 5 "is pleasant to work with" — coding
interviews don't really select for this, but I don't think anything else does
either short of probationary periods.

~~~
clarry
> Is there a better system? I don't believe that just looking at resumes and
> past experience selects for 1+2+3 nearly as well.

A take-home test would cover 1+2+3 without 4. With the caveat that 3 becomes a
test about written communication, which may be a good or bad thing. If you
want to do both, you can expect a written description of the solution, but
also go over things verbally if they pass the bar, in next phase.

------
angarg12
Software Engineering hiring is broken in more subtle ways.

Recently I went through the process of an internal transfer in my company.

I applied to a team and went through a loop, just like an external candidate
would.

I got rejected by that team. The reason is that I failed their systems design
round.

The funny thing is that I spent the last two years maintaining and optimising
the backend of my current team, that supports hundreds of thousands of
customers.

Let me be clear, I didn't do well in the interview. They asked me to design a
Dropbox clone and I flunked a few points. I didn't know long polling, and I
tried to implement some of the features using the same solutions that we use
in our system, which don't work very well here.

But what is the point of the interview? Is it to assess that I can design a
Dropbox clone in 50 minutes, or that I know about systems design? If it is the
later, you can just take a look a my work. You have access to all my pull
requests and code reviews, design documents, and peer feedback. Heck, you can
even ask me to walk you through our system and explain how and why we
implemented certain features.

The reason why internal transfers are set up like that is so that internal
candidates don't get a better treatment than external ones. Sure, I agree that
some checks are in order to avoid moving low performers around, but are we
trying to hire talent or make people jump hoops to get a job? The best part is
that the hiring manager recommended me to 'reapply in a few months' to the
job. What does that mean other than 'go study a bit and come back'?. If that
isn't broken, I'm not sure what is.

------
Adiqq
Personally I agree with idea. Software development and IT nowadays is complex.
Do you really think that whiteboard interview can truly check anything? It
will check if you can memorize definitions and patterns for solving tricky
questions and that's it. That might work for some type of people, however I
work poorly under such stress, my mind goes blank and I can't remember
simplest definitions. I don't want to work for FAANG, I'm not math genius, I
don't specialize in theoretical CS. I want to collect requirements, look for
solution (often with help of the internet) and provide good enough solution
that solves problem at hand. Currently I work in DevOps. I can easily answer
most questions from my team and help troubleshoot issues at different areas.
Should I never work in IT, because on some interview, my mind goes blank and I
struggle with question that can be easily answered by CS student?

------
TurboHaskal
If only it was a myth. I always like(d) to do a simple programming exercise
(no fancy data structures nor algorithms) that can easily be solved with a map
/ filter / reduce one-liner (or a for loop with an accumulator and a simple if
else, that's fine too).

I get that people aren't good at coding in interviews (count me in!), but I
have lost count of the number of applicants who can't get it done. The
situation got so bad that they kindly asked me to stop asking such questions.

~~~
reallydontask
I've seen people panic in coding interviews

I used to have a set of unit tests and asked the candidate to make them pass
and I thought this was a good system.

We have a senior dev that got something wrong early on, started getting more
nervous, refused help as it was a simple problem, got more nervous and flaked
out completely.

On the other hand we had people that were so unfamiliar with coding that this
was a good test to weed them out.

------
bigpeet
I've worked with "developers that can't code".

One example was an external contractor who, according to their CV, had
multiple years experience with programming in C.

The person was tasked to fix some errors in our code base that the static code
analysis tool found, e.g. remove implicit type conversion, etc. They submitted
their changes for review, claiming the analysis tool reports 0 issues now.
Their code simply did not compile (and the analysis tool only works with a
successful compilation)!

Even after explaining the issue, the developer asked if the task is completed
now and if they could move on to the next one.

This wasn't the only time this developer proved that they "can't code".

The issue is that it is very easy to claim to have experience. There are a lot
of self-taught programmers out there who learned coding at home by themselves.
How do you differentiate those from people who "can't code", but claim to do?

I like the approach to let them implement a small(!) piece of code ahead of
time and in the actual interview let them explain their code, their decisions
and ask questions.

------
mattlondon
Best technical interview I had (on the interviewee side) had me do a very
simple coding exercise at home - it took maybe 4 to 6 hours max so could
easily be done during lunch breaks at your current job.

Once you submitted the exercise and went to on-site interview you sat with
another engineer and they asked you to make some basic changes there and then.

I liked this approach: you could take your time working at home to be sure you
understand the assignment and have a chance to think through your
implementation, then when it came to the actual on-site interview you were
already familiar with the code you'd already written so thwre was less of a
deer-in-headlights effect. Bonus is you had to "work" with someone too so they
can see if you are a good culture fit/not a jerk as well

~~~
mattmanser
4-6 hours is a ridiculous amount of time, and certainly not something many
people coud fit in a few lunch breaks.

~~~
ltbarcly3
I'm sure they find time to watch 4-6 hours of TV a week. If they can't find
the motivation to put in an hour before bed for a week to apply for a better
job, then it seems like the process is weeding out the people it's trying to
weed out.

------
ltbarcly3
What's not a myth is the person applying for a job as a developer that can't
code. There are tons of people that apply for jobs as programmers that can
barely write two lines of working code. They can't read code, they get weirdly
confused when writing a simple loop, just total incompetents in every respect.

I'm not saying you have to be able to pass a FAANG technical screen or you are
crap, I'm just saying there are a lot of pretenders that still apply for and
manage to get jobs writing software.

------
gridlockd
This part of the interview is just another filter, it being applied at all
tells you that maybe the role you applied for isn't so desperate to take _you_
over the hundreds of other applicants.

In other situations, the interview may be as simple as you _showing up_ with
the right credentials. Those jobs might be scarce in silicon valley or not pay
as well, but they exist across the country.

Furthermore, if the procedure is bullshit, does that not mean people who are
otherwise geniuses are getting passed up? If so, then there's a pool of
geniuses out there to hire at a bargain, giving you a competitive advantage,
should you be able to actually manage them.

Conversely, there must be companies already exploiting this advantage, so if
you're a genius failing on the whiteboard, perhaps you're applying to all the
wrong companies.

------
stefanve
I did quit a lot of interviews for both development and devops position. I
always was happy with the hires. I never asked to write code, but I ask them
to explain higher level and some times lower level concepts. Than let them
draw it on aboard, paper or just explain it depending on there preference. The
reason is that if you have a good understanding of programing concepts you are
probably able to code.

For instance explain the concept of MVC. I have interviewed candidates that
only could explain where they would put certain code based on the framework
they used but could not explain the design pattern nor why they would put the
code where they said the would. these types of questions will give you some
insight if someone is able to reason about code and explain why they prefer
some style over the other.

------
lmilcin
This is demonstrably not true.

I work for large corporations, mainly banks.

In this setting there are couple of ways for people with absolutely no ability
to code to get through the cracks. For example, one way this happens is
through an external contractor vendor.

These vendors are only interested in fulfilling contract requirements and
typically will try to sneak developers with least ability they can get away
with. As hiring process for vendor-supplied contractors is relaxed it is not
at all difficult and will only depend on management of the team/project to
prevent. Then, if it is no longer sustainable to keep particular developer on
the project the vendor will not let go of the developer, it is more likely
he/she will be rotated to another project.

I have worked for a project in Credit Suisse where the "principal developer"
was a person rotated from another project where she served as "development
manager" and had many years of "experience" as Java developer before that.
This person had only barest ability to code, she struggled to write a simple
loop. When asked to add Json serializer to an application she was confused and
wrote a bunch of code that concatenated strings to produce something not
exactly resembling Json. She did not even have knowledge to spot the problems
and would blame tools and other team members for parsing errors produced from
parsing the code. Surprisingly, these explanations were accepted by the
management as she had more "experience" than other team members.

When I joined the team and spotted this situation I implored management to
reevalute her as principal developer. The management had no development
experience either and were taking her explanations on face value. They told me
that I need to spend more time on the project to "learn the way they are doing
things". Only after months of persuasion and showing countless examples of
glaring incompetence I was able to succeed to resolve this problem.

I find it not difficult to imagine more possible settings where people with no
competence in coding can flourish when they can initially build a strong
position for themselves and can exploit incompetence of their managers and
peers.

This is especially true for large corporations which have huge appetite to
hire developers and huge budgets but also can have managers with no incentive
to do their hiring very well.

In one project I worked for the manager kept overseas staff even though it was
net negative productivity because "higher management said so".

------
hamburglar
I recently interviewed a guy who decided to solve a problem recursively, and
he was allowed to choose his language. He wrote a function body that _kind of_
pseudocoded what he was describing as his algorithm, but was far from
complete. He wrote no function header. When he got to the part where he was
supposed to recurse, he got completely stuck because he couldn't figure out
how to make this block of code which wasn't even a function call itself.

This was a developer who can't code. You can't tell me this guy is a
programmer who's just been off "not coding" for a few months.

------
mothsonasloth
[Warning unempathetic post]

The author needs to take off the "happy town" rose-tinted sunglasses.

Like any profession, software development requires competence. Empathy and
understanding are not a driving factor.

Being able to produce a maintainable solution for a business problem and being
able to communicate that solution to others is what is important.

If what he says is true, then why aren't Google et al. hiring mediocre
developers?

Take home point would be this; you are responsible for your skills. If you are
in a role where you are not doing coding day to day, then you need to evaluate
that role and ask yourself, is code still right for me?

~~~
skytreader
You're missing the point. The article is commenting on how every company is
using FAANG practices even when it doesn't apply to them.

Quote: "Because make no mistake, that technical interview - that one-shot
coding test we do. That's it. If in the heat of the moment you make a mistake
or don't pass, absolutely nothing else matters. FAANG (and sadly everyone else
who has copied their half-assed hiring practices) will not hire you. Nothing
overrides it: you could be a Nobel laureate and it wouldn't make one iota of
difference."

> Being able to produce a maintainable solution for a business problem and
> being able to communicate that solution to others is what is important. > >
> If what he says is true, then why aren't Google et al. hiring mediocre
> developers?

FAANG interview questions do not constitute a "maintainable solution for a
business problem" for most businesses. Unlike the author, I'm more willing to
give FAANG the benefit of the doubt in their hiring practices but even then
I'd give a very generous guess that only something like 20% of FAANG employees
actually use the same skills in the interview in their everyday work.

Sure, Google might be able to save money if an engineer can come up with a way
to reverse-index a volume of Britannica with a memory constraint of 4MB but
other businesses won't if only for the fact that they don't have the
organizational infrastructure (QA pipeline, canary version rollout, etc.) to
properly verify the correctness of such hackery nor sufficient business clout
to cushion possible outages that come with the territory of building your own
libraries. For most businesses, hiring an engineer experienced with
Elasticsearch would provide them with the business value they are looking for.
Unfortunately, said engineer who spent the last 4 months debugging their ES
cluster's split brain problems did his whiteboard interview in a Python-like
pseudocode and couldn't handle memory swapping properly. So it was an
unanimous no.

> If you are in a role where you are not doing coding day to day, then you
> need to evaluate that role and ask yourself, is code still right for me?

I used to be in this "code everyday" mentality but I realized that a better
mindset is to "solve problems/puzzles everyday". Someone who works on yet-
another-CRUD-app on a daily basis is definitely coding everyday but is this
activity leading to growth? On the other end of the spectrum we have someone
who solves ICPC World Finals problems in that 20 minutes they have waiting for
breakfast to be served; honestly more impressive than the CRUD guy hands down
but consider that:

\- beyond something linear like lists, stacks, queues, there is very little
opportunity to build a data structure class on your own. I've found my data
structures knowledge useful in _reasoning about_ (not implementing) data
structures other people wrote: the DOM is a tree, DB tables are trees, regexes
are graphs, indices are look-up tables and/or hashes.

\- I've had to work with DP in my day job once and only once so far (out of 8
years working) and that was a very special circumstance at that. And, guess
what, DP didn't really save the business in that situation. Communicating and
cooperating with the non-engineering departments did.

\- Not to mention that sometimes life is just yak-shaving, as the article
points out. I've made PRs with nothing but logs only so that three days later
I can PR a one-line change (four, thanks to the linter) that would fix a
performance problem I tracked down for three weeks. Or soldier through Jenkins
and Maven so you can finally migrate your outdated CI pipeline.

------
santoshalper
Several times in my career I have worked with people in software developer
roles who could not write basic code. This was not a situation of mistaken
title, they were in a position where they were expected to write code and
could not. In several cases, they struggled to operate Visual Studio in spite
of claiming to be a proficient .NET developer. Non-technical management could
not tell the difference or nepotism was involved. In each case, it took months
to weed them out while other developers had to shoulder their work.

I am now in a position where I lead an organization that hires hundreds of
software engineers every year. We start our interview process with take at
home coding tests as a first line screening. These tests are not hard (I am no
longer a day to day developer, they are not hard even for me) and of course
you can always go to Stack Overflow. ~20% of our candidates fail them
routinely. I am glad we are not wasting time interviewing them.

Those are facts. There are no facts in the article. Until this industry deals
with its fraud problem and certifies engineers like other fields, technical
testing is here to stay.

~~~
newcrobuzon
> they struggled to operate Visual Studio in spite of claiming to be a
> proficient .NET developer

Just out of curiosity: were these junior devs? Were they maybe more proficient
in other language/IDE? Couldn't better mentoring/on-job training help - rather
than just to "weed them out"?

I might be naive but (and I have also been on leading positions) I still
believe that if it seems that somebody "cannot code" it (most of the time)
just means that somebody a bit more senior just have to invest a bit of time
to coach them...

~~~
scarface74
From a company’s perspective, why spend time mentoring juniors and doing on
the job training - both of which takes time away from your senior resources -
instead of just hiring someone else who can hit the ground running? Yes I
realize _someone_ has to train them, but you might as well let someone else do
it and poach them once they have experience and they are looking for another
job.

Inevitable as they gain experience at the other company, their market value
will go up quicker than their HR policy will allow for raises (salary
compression) and you can still offer them slightly below market rates and they
will be glad to take it because they don’t know their worth and it’s a big
jump for them. They probably don’t know how to negotiate either.

I’m not making a value judgement. This is just the world we live in.

------
reallydontask
> When a digital artist is in an interview, they're not asked to rapid sketch
> a portrait with a rusty spoon.

I'm going to use this from now on to explain whiteboard interviews

~~~
ltbarcly3
They are asked to submit a portfolio of their own original work. Incompetent
programmers don't have anything to show, and our industry makes it easy to
come up with excuses about why, excuses that wouldn't play for a digital
artist.

~~~
reallydontask
>They are asked to submit a portfolio of their own original work.

How do you assess that it's their own work?

> Incompetent programmers don't have anything to show, and our industry makes
> it easy to come up with excuses about why, excuses that wouldn't play for a
> digital artist.

Such as?

One thing to bear in mind is that ultimately there is no perfect way to hire,
whether programmers, artists etc ..

------
sgt
Sounds like this guy is trying to make mediocrity more acceptable. If a
developer is not able to do FizzBuzz, something is deeply wrong.

------
W0lf
The conclusion that those rejected developers eventually ended up getting a
job at another software company and hence they must be able to code properly
is false IMHO. In my experience there are _a lot_ of dysfunctional software
companies out there where people do get hired for software jobs but they all
end up doing whitebox testing or clicking around in some Excel sheets.

------
flipcoder
I believe the fizzbuzz failure thing is largely interview anxiety

------
t5sjnrtjnrfds
I'm so beat down by interviews lately. Hours of softball questions and days of
teeth-grinding anxiety just to be hit with a vague rejection. Repeat for weeks
as the rejections just keep stacking up. I'm honestly thankful for the
whiteboard interviews just so I don't have to repeat my resume spiel for a
tenth time or making up BS answers about conflicts with coworkers. You can see
my resume, you can see my github, if you want to reject me because I don't
know scala then just do it before the interviews please!

~~~
malux85
Could you put your github in your profile, So that we can see your github?

