Why Can't Programmers.. Program?
blog.codinghorror.com
blog.codinghorror.com
There are (edit:almost) zero programmers who can’t write a while loop. There are just 199/200 people who are stressed out by the bizzaro interview process that was designed by aliens to promote leetcode. There are however millions of programmers who can’t write maintainable or readable code
That spun me out and I crashed even harder. In his eyes I'm one of those 199 people who "can't even code".
Fuck 'em, if coding is knowing how to implement weird palindrome-related algorithms in a completely alien browser-based IDE (if you can call it that) over a call with a several second delay in your kitchen at 9pm local-time after a hard days work then maybe I can't code.
I had a very similar experience. Moreover, on the phone call there seemed to be some kind of soft ticking sound in the background, like a clock. It was very distracting. I wonder if the interviewer was actually timing me.
At my current place (and before as well) we give the candidates a 'take home test'. The problem is a bit larger than FizzBuzz, so that we can see how they would structure things, if they can write clean code, write tests etc. The 'take home' nature solves quite a few of the problems you mentioned, both for the candidate and us if you ask me. And even there you have to be careful that things don't get out of hand. Nobody good who currently has a job is going to spend any time on a take home test that the employer expects them to spend hours upon hours on over a short period of time.
Of course there are always managers that fear it's too easy to cheat but if you ask me, that's either never happened to us or if so, it was very clear after talking to the candidate in person about their code, that we wouldn't hire them anyway, so at best they cheated us out of some interview time.
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
I will note the person making this observation is apparently incapable of securing their website with SSL!
Smaller companies should absolutely break away from this way of interviewing to find developers that can do great work for them but the pressure (or envy?) to conform is too strong I guess.
The irony is that the founders and initial employees of these companies were never interviewed in this way. They were mostly just school friends. So it's highly dubious whether these specific hiring practices were even crucial to the success of those companies. People are emulating the wrong things and just cargo culting.
It’s the same as when you get that bag of mixed nuts and pick out a bunch, put the almonds back in and eat only the pistachios. About ten minutes in, your search for pistachios becomes ever so hard. You take a handful of almonds out, put them back in and repeat, barely seeing a pistachio.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But in a lot of cases it's overkill and makes everything harder. Following a rule to always do it is simple but using your judgement is better. The best code minimizes side effects and reduces stubs and fakes.
One of the big things I’ve noticed, is people don’t know what they haven’t used. Something pretty common I’ve noticed in some candidates is that when they’re asked how they would X they start going into some over engineered proprietary framework or library that they’ve used at their past company rather the more fundamental answer we’re looking for. They never really get the chance to learn things because their first job out of school has them working on problems that require a very limited skill sort or ability. I can’t speak to how 2007 was, but I wonder how many programmers couldn’t figure out fizzbuzz because they simply never had to use modulo division. I’ve never had to use the modulo operator in my time building CRUD apps and frankly I had never heard of it until I had heard of fizzbuzz many years ago. Keep in mind that many people come from non traditional background and do not have any sort of technical education besides what they learned themselves and that for a number of business that’s been enough to hire them to maintain whatever business applications they’re working on.
I myself am not a particularly good developer either. Though I could pass a fizzbuzz test there’s no way I’m making it through even some of the easier leetcode problems. And so, at this point I’m looking for a way out of the industry. But when you look at how much money even no name companies will pay for a job that is not gatekept by expensive credentials and can be learned on your own time, you’d be dumb not attempt run towards it. Note I’m not arguing for a credentialized gate keeping, I personally can’t stand credentialism, but there are a wide variety of people rushing into the field who can make decent money even if they’re not particularly good as long as they’re providing whatever the employer things is business value.
Or better, bury the article in an unmarked grave and never see it again. Few people have done more harm to hiring in the industry than Atwood and Spolsky.
Programmers can program, but they usually aren't stage performers. Using auditions to evaluate non-performers is doomed to failure, predictably.
Take homes might work if your company isn't very large but that doesn't scale.
Asking domain specific questions can easily have as many false negatives as Ds/A questions - Do you really need to have a precise, perfect definition of what a closure is in JavaScript on the tip of your tongue to be an effective front-end developer in 2021?
Domain specific questions are worse than algorithmic questions IMO because no matter how well you know a subject, there's always going to be pockets you might have missed.
What if you took a more holistic approach and actually went through a person's projects/Github? That's more time consuming and harder to be consistently objective with. Plus, then you get the crowd of people who say you shouldn't have to have side projects to be a programmer on your case.
There's going to be some level of anxiety inherent in interviewing, period. I do agree that making people write code on whiteboards is not good though. They should at least be given a somewhat similar environment to what they use day to day, like being able to type.
I say this as someone who has absolutely bombed in person interviews before on the same level (probably worse) as the guy getting tripped up by basic Python elsewhere in this thread.
When people ask this question, they almost always mean, what's the alternative to one kind of testing that's still a test?
Nobody seems willing to accept the answer that interviews shouldn't be tests. The demand for testing assumes the idea, the self-fulfilling prophesy, that 99% of programmers can't program. If you start with that assumption, then you'll always end up wanting some kind of test. But it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
We know that interviews, not just programmer interviews but interviews in general, are poor predictors of performance. The best predictor of future performance is past performance. In other words, experience.
Our industry is also insanely afraid of the proverbial "bad hire". It's a pervasive mental illness. There's a failure to recognize that perfection is unattainable, and mistakes are a fact of life. Look of professional sports: they spend vastly more time and money on talent evaluation than tech, and yet pro sports teams get talent evaluation totally wrong all the time! Bad draft picks, bad trades, bad contracts, etc. They just accept it, deal with it, and move on. Nobody has the perfect programmer hiring method, and nobody ever will. It's a crapshoot. And just because a programmer "can program" doesn't mean they're not a bad hire. They could still write buggy, overengineered code, they could be a bad teammate, they could be a sexual harasser, or have any number of other issues. Or they could leave for another jobs a few months after getting hired. There's no way to guarantee a good hire.
It's a mistake to turn hiring into an "algorithm". It's not a programming problem, it's a human problem. Programmers are humans, not robots, and they're not going to perform robotically in interviews. The only way to truly know is to give someone a chance. They may unpleasantly surprise you, but they may also pleasantly surprise you.
But that's not a compelling argument against doing coding assessments in interviews, I could see it as an argument in favor of also having behavioral questions.
>it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
There's no standardized licensing for our profession. The closest thing we have really is Computer Science degrees which, as the article this thread is about points out, doesn't churn out job ready programmers unless they're also doing independent study.
Evaluating on past performance alone would be impossible. What if this is to be their first job? What if their previous job won't tell you anything other than "Yes this person worked here" because they're scared of getting sued?
If you're relying on a candidate's self description of their past performance you've just switched out selecting for people who can perform under pressure to selecting for people who are good at bullshitting/charming.
To become a lawyer, you have to sit for a very intense and stressful exam that you took two extra years of schooling for. There are similar processes in place for becoming a doctor, after even more schooling and forced on the job training.
Some form of assessing coding skills is going to happen just like some form of skill assessment happens with any knowledge worker job. It'll just either happen during interviews or eventually through some kind of certification process.
The example you gave of professional sports is odd to me- Yes, they have to deal with it when they make bad hiring choices just like most organizations do but they still clearly feel that it's worth the effort to be very selective in their hiring process.
There is an opportunity cost to "giving someone a chance" - even if you moved to a very permissive system where it's easy in, easy out people still have to onboard that employee and go through the process of firing them. If a simple coding assessment had revealed they can't even complete very basic tasks it would avoid taking up company resources.
This isn't a defense of forcing someone to write perfect code on a whiteboard, I just think it's absolutely valid to ask someone to write code in an interview setting.
Most professions have no licensing. Doctors and lawyers are the exception, not the norm. This is because doctors have your life in their hands, and lawyers have your freedom in their hands. But usually an App Store app won't kill you or send you to jail. Moreover, licensing is not actually standardized! Every state in the United States has its own different licensing requirements. There are no national or international standards. It's a local government issue. Every time people bring up licensing, they miss these basic facts.
> What if this is to be their first job?
Obviously entry-level jobs and/or internships would hire differently. The crazy thing about software engineering is that they have fresh college grads and 10 year veterans in the same applicant pool for the same jobs! This should never ever happen.
> selecting for people who are good at bullshitting/charming
We already do this to some extent, because "leetcode" tests are bullshit. Anyway, this is just the insane paranoia of the tech industry. Yes, there are liars out there, but it's ridiculous to treat every job candidate like a criminal, guilty until proven innocent. Even our legal system has more respect for people. Remember, hiring is a two-way street: you have to convince the candidate to agree to work for you. Treating the candidate like a liar is not a good first impression. Imagine if you tried that method with dating — you'd never get a second date! You know, there are a lot of bad bosses in the world. I would argue there are more bad bosses than there are bad programmers, because programmers get promoted to management without having any experience or training for management. How about we have job candidates grill the interviewer? If you think "whiteboarding" is bad, then the hiring manager can do a take-home test given by the candidate. ;-) Nothing worse than getting hired by a bad manager.
> they still clearly feel that it's worth the effort to be very selective in their hiring process
I never said companies shouldn't be selective in their hiring process. I actually think they're too unselective in their hiring process. It's a waste of everyone's time to do a whole bunch of "screening" interviews of basically everyone who applies. Instead, companies should only interview the top candidates based on experience and skills, and spend most of their time trying to evaluate those few top candidates.
I would have less objection to doing coding as part of the hiring process if coding tests weren't used so ruthlessly to screen out candidates. Maybe it could be the final step before hiring someone. (Even there, you wouldn't use a "FizzBuzz" test, those just dumb.) But hardly any company uses coding tests in that way. Mass testing of candidates is nothing more than a test of performance anxiety. Mass interviews are just begging for some trivial matter to decide who gets hired.
Let me put it this way: if hiring is based mainly on the interview process and not on the résumé, then it's precisely the bullshitters/charmers you were worried about who will get hired, because those are the kind of people who are best at interviews. And the ability to grind on LeetCode doesn't make you a good programmer.
So once these people graduate, OF COURSE they're going to stumble over for loops and if statements; the only think they know is how to follow along in vs code while someone builds a react app over zoom.
I don't feel like i really went from programming stuff to knowing how to program until after i'd finished a bunch of smaller programs in a few different languages. Like a lot. Years worth.
There came a point though where, even if i was working with an unfamiliar language, once the syntax is out of the wat, i started thinking about the problems i was working on differently. I understand now how computers work on a more fundamental level and what the code is actually doing under the hood. What's actually happening when i declare a variable, define a function or compile some code.
Before i understood that stuff I realize now i was always kinda just shooting in the dark only vaguely understanding what i was actually doing.
But, it took a long time. I guess the very first time i ever programmed was i dunno at like 5 or 6 years old when i managed to write a loop on the atari. It took almost two decades learning on and off for me to actually understand what i was doing.
I'm still not sure if i'd feel qualified enough to apply for a professional programming job.
I would say that the ability to write good code is related to problem solving capacity and intelligence.
Someone with experience in a few languages has no difficulty reading code in a lot of languages, and can get going in them quite quickly, but the first few hours/days are going to involve a lot of looking up trivial things, especially if starting with an empty page instead of tweaking in existing code.
It would be astonishing to me if it's true though.
In fact I'm repeatedly amazed at how well people program and think about solutions to problems.
[](){}(); This doesn't test your programming skills either
Regardless, what’s the point in asking people how bad practice code works? Why would anyone write a lambda that does absolutely nothing?
What problems don’t boil down to that?
The other developer of this type that I've seen can only connect cloud services together.