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?
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.
> 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.
This depends on what the exercise tests. For datastructures and algorithms, yes maybe.
We use a test where the most advanced data structures you will likely use are dictionaries and sets, and even those aren't necessary. The main thing the exercise tests is how do you structure a chunk of non-trivial business logic such that other engineers can understand it and reliably contribute to it.
We assess this through code review, looking at the architecture and abstractions used.
> 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
The article is a follow-up to a previous post which I linked to in the leading sentence.
> The author does not mention his experience interviewing or hiring people
From the previous article: "I've been a software developer now for around 15 years. In that time, I've been a day-to-day developer, run my own successful software business, was co-founder at a VC funded startup, and I've had to hire and manage developers."
> I'd love to hear what OP suggests to replace the coding tests with - a chat about past projects, then make an offer?
From the article: "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?"
> "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?"
I have no Github, portfolio, nor education. My previous companies have a bad engineering culture. So they’ll give me good references, since they don’t know any better.
I have trouble writing a fizz buzz and yet that system could have me hired.
That introduces new problems. Hiring someone only to realize they are a bad fit, and then firing them is bad for both the employer and employee. Bad for the employer because they wated resources on on-boarding and compensating the employeed. Bad for the employee, because of they spent time working for a company that fired them instead of looking for a different job they could keep, and may have made other sacrifices for the job, such as relocating.
To be fair, a coding interview would address the "can he code at all" question, but not what you mentioned: sloppiness, incorrect coding and needing mentoring
I usually try to detect things like: "do you know lists and dictionaries?". Also very basic abstraction design and basic communication skills. This works well with juniors because we mostly code business logic.
It does not work at all when trying to recruit a senior. I am still clueless about that. I have at least two recent cases in mind of a senior hire that lead to catastrophic results. People that new how to present well at a superficial level but did really poorly once they had non trivial stuff to do.
general developer:
I don't know why people want to find out if a person can code? ... I assume that a person can code ...(if not you will see very soon)
I mean it's not about writing "hello world". If the person is not dumb, you won't find out in an interview if someone can really code. (repos are much better for that, but can be deceiving)
"We have a 3 month probation period and if something is really not true it will have consequences. I'm crystal clear about that."
I mean we are all humans, but there is also a contract with money involved. I have to look out for the company and it has to be fair for all the other team mates/colleagues too. If you hire some "faker", without consequences it will destroy the whole team balance. (Additionally there is a "meet the team" to address the consent process). From my experience, technical people have a low tolerance for people which can only talk...(in a technical team).
So it does not mean you are safe if you can make it through the inverviews with tricks. (it may seem a bit hard, but I don't like the general acceptance of "lying" or superbeautify ^^ in the application process)
And then I talk about what we are working on and how we are structured. So the interviewee also gets an impression what the day to day work will look like.
What I really want to see, is the ability to solve problems. Because this is our real job. We are solving problems(with code). So I ask questions you can not solve in 5 minutes, but you see how someone approaches a problem. Is the person collecting intel about conditions and constraints or is he/she immediatly starting to code etc. ...
For that I generally take real problems we had and we already found a solution. And sure I tell them, that it is not possible to find a solution now, because many interviewees are "conditioned" (or used to) to give you immediate solutions. Else they would panic or getting frustrated.
In general ask a question:
Why should I want to barbecue(or embarass) a possible colleague?
You also have to take into account, that there are people which don't know everything yet from the specifics you need. But in the right environment with support of colleagues, they become really great. It's more about the mindset & willingness to learn and also the support of the team members.
The above is more for a general developer.
For an expert with 7y+ (whatever..) experience in a specific topic. I would really ask very specific questions and maybe a "homework". Because I hire an expert for specific experience in a topic.
Also the risk of losing money & time is much higher. Because it's experts work...it's hard to judge if the person is not capable or if it really just needs some extra time.. ;-) You won't believe how many people have a lot of years of experience and made only basic stuff during that time. So on paper they should be an expert, but in reality they are not.
In my extremely limited experience in hiring (very few people), I made multiple mistakes. One of the thing I discovered (we were hiring a junior and both of us gave approval) was that you can find a person who can solve problems but can't actually code (there were a lot of red flags that we ignored on purpose I guess).
It isn't until I read your answer that I realized this: we were both convinced because the guy was smart, clearly, however he didn't know enough of the technology we were using to develop anything meaningful with it.
While when hiring a senior developer, it's possible that they can pick-up a new language or framework very fast, this is highly unlikely with a junior (this is not something I have in numbers, just thought).
The real side of the problem is that is very hard to figure out if someone will be good with everything that's not "oh, you can code".
It's not well defined in the industry, so there is no objective methodology to evaluate the skills of a person.
As a developer, you can usually recognize if someone can code, but determining if they are sloppy, care for design, that's a totally different thing: you need to work with them to figure that out, this is probably why an interview is not enough.
I used to work as a finance controller and I really never had to show a technical skill in an interview...
And never saw it/heard from colleagues in finance, maybe in international accounting(which is more rule/law based) they ask if you know some stuff about this and that but nothing serious...
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.
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.
> 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.
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.
> the state of the art is both extremely diverse and rapidly moving
I blame this on the tendency to reinvent the wheel instead of fixing the existing one, and the tendency to chase the last new shiny thing of the month.
Worth mentioning that engineers often build proprietary solutions with proprietary tools and methods. So, while there are a lot of solutions that can be licensed and modified for a use case, the guy or gal building, say, Cisco's WebEx platform can't transfer their skills as readily as the guy or gal deploying, securing and maintaining it within a company.
So much of your work has insane barriers to entry, even for internships, that I'm surprised your roles don't come with one or two assistants to manage the mundane business of scheduling meetings, filtering emails, and planning deadlines around out of office time.
I got my BS in Cybersecurity, and after a few interviews, I nope-d out of IT as a whole. They'd post preferred certs on the job description (like CCNA) only to ask why I wasn't a CCNP during the first or second interview. Or they'd debate whether some other candidate with a CompTIA cert was better prepared for the $15/hr. internship. And I'm nowhere near the specialization of most engineers.
Awesome, awesome work, but it takes a ton of grit to get your foot in the door, and even more grit to switch jobs.
There's some "accredited" credentials you can get in software development - I've got one for AWS, for example - but you can get most of those via a multiple choice questionnaire. Having the certification itself means nothing to me; sure, I know in theory how to set up some AWS services, but I have barely any experience in it, and I wouldn't dare to apply to an AWS position because I couldn't actually do it from day 0.
I went job hunting last year, and what I was really looking forward is technical interviews - PLEASE just challenge me, allow me to show you my work instead of my CV. I needed technical interviews to fight my impostor syndrome.
"I went job hunting last year, and what I was really looking forward is technical interviews - PLEASE just challenge me, allow me to show you my work instead of my CV"
I totally agree. I hate the irony of having a highly technical job but then needing some decent writing skills to put together a CV that isn't just a list of employers, dates and acronyms.
Why shouldn’t you have decent writing skills? There are so many highly skilled developers who get frustrated because their ideas aren’t taken seriously because they don’t communicate well and don’t have any persuasive capabilities. My career was stuck in neutral for a decade before I started working on my interpersonal skills and learned how to navigate corporate politics.
There is bunch of certifications available for devs and/or various scopes of technical knowledge. For some reason all of the people that I've met who are in possession of such a certificate were subpar developers in general. Same with uni degree. I've seen programming olympiad winners writing horrific stuff.
On other hand, if I to have a new guy sitting next to me tomorrow which code I will review and support... Well, I'd like to ensure somehow that I won't spend hours and hours on explaining things and that I won't get paged at the midnight because of suck trivial f-up.
What's the solution though? I can see anything but just hire the person for a week, 2, may be a month. Give them a boot camp project, observe and then make a decision.
That's what happens with lots of interns anyway...
But technology is so uncertain past 6 years that successfully making half decent tech bets might mean your specialty is somewhere else.
Will GCP certifications still be useful? Should Google be the certifying body for their own technology? When a field is so dependent on proprietary tech, does it make sense to certify people as metaphorical Windows Metro experts?
I keep reading that tech moves so fast that your tech stack becomes out of date. But, if you avoid the front end, it’s not hard to choose the technology that’s the right place on the hype cycle.
In 2008, I was looking for a job after being in at one company for nine years. I happen to keep all of my job search emails in a folder by year. Looking at the job reqs for standard enterprise development in 2008, they were looking for either Java, C# or a few were still looking for C++. Java has been in demand since 2000, C# since around 2004 they both still are.
As far as databases, the big four were Sql server. Oracle, Mysql and I think Postgres (wasn’t on my radar until 2012). I’ve been going back and forth between Mysql and Sql Server for two decades.
Javascript has been in demand since 2002. Definitely by 2008 when employers were asking for “AJAX frameworks”.
As far as your examples, it’s not hard to guess that you should stay away from basing your career on anything built on top of Google’s infrastructure (GCP) when they are in third place behind AWS and Azure, and aren’t really making that many inroads into large corporations. As far as Metro, by the time Metro came out, it had been clear for years to avoid desktop development of any kind outside of games if you wanted a technology with broad appeal.
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.
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.
My mom is a CPA, SM in Tax, and won't take anyone onto her team if they can't look through a list of allocations and correctly answer whether they do or do not apply for Real Estate and Hospitality.
She has had one person last more than three years on her team. But with 1/6th of the workforce of any other manager, her people have ranked top three annual billing and efficiency for the last 6 years.
There are tests, but they're unconventional. And there are times I hear my mom pick up her office phone, call one of the firm's partners and say, "Stupid question. Would you allocate this to X or Y?" And then 40 minutes of heated debate over whether it will or won't cause a $300 penalty on a multi-million-dollar return.
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".
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.
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.
> 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.
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.
IT is the far west. There are few educational requirements, and hiring laws specific to our craft. It's a very young field, unlike medicine or architecture, and we just beginning to establish professional standards on the job.
The fact most people see it as magic and can't evaluate it at all doesn't help.
Anecdotally, I've seen many programmers that can't code.
Remember that 2 dev projects out of 3 fail, for a clusters of reasons. And when it doesn't, there is sometimes a few hard kernel of devs that are doing most of the important part of the job, fixing other's mess on the fly, or just plainly doing it for them.
So those bad programmers can go from failure to failure, and never be blamed for it.
But honestly, it it weren't that way, I couldn't have entered the field. I've been given my chance more than once, and I've screwed up many times, before even becoming a decent professional.
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.
> 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.
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.
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?
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.
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.
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.
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
I live in a major metropolitan city in the US that is not on the west coast. Most jobs are bog standard software as a service CRUD/bespoked internal system roles. They all pay about the same at the same level of experience - maybe there is a $20K variance but you can usually negotiate that. Also, senior engineers come on the market infrequently and there are many open reqs (I’m speaking pre-Covid). Meaning that historically (over two decades) its never taken me more than a month to go from looking for a job to offer. Most interviews in my pure software engineering roles have involved soft skills questions, explaining past projects, sometimes standard multiple choice prescribing tests and occasionally simple on site at the computer coding tests.
All that to say if I both have a job and have two or three companies vying for me at about the same salary - I’m no special snowflake. I’ve just done a lot of targeted resume driven development and have built a strong network - why would I do a take home test?
I’ve scheduled six phone screens with different companies in one day.
My record for looking for a job, to having an offer is four days. I called an external recruiter on Monday, had a phone screen on Wednesday, in person Thursday morning and offer that evening. It was for a job at a recently acquired subsidiary of what was then a Fortune 10 company.
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.
I don't think it is rediculous - from what I understand of FAANG interviews they are full-day 8-10 hour things anyway, so 4-6 plus an hour or two on-site seems comparable.
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.
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.
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".
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.
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?
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.
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.
As a personal rule I immediately abandon the hiring process when I encounter an at home coding assessment that is not accompanied by a grading criteria. I once wasted my time on one of these only to be burned for not providing something the hiring company never asked for even though I completed the application assigned with a working original API and provided thorough documentation. Never again will I waste my time on some companies unpaid labor.
Even more dangerous were people who could operate IDE, could FizzBuzz, read all the soft blogs, had all the correct opinions about frameworks and methodologies. Guy I have in mind now knows that functional programming is the right and can code examples of it. He is even fun to talk about programming and people who dont work with him invariably assume he is good programmer.
And still could not produce in real world situation, because he cant do anything except self-contained examples and gets demotivated with pretty much any task quickly. He is good at remembering what blogs and forums said and repeating it to other people.
> 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...
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.
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.
>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 ..
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.
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.
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.
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!
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.
> 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?