by nsainsbury on 4/14/20, 4:55 AM with 75 comments
by gregdoesit on 4/14/20, 7:01 AM
> 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?
by 7777fps on 4/14/20, 8:06 AM
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.
by thayne on 4/14/20, 8:18 AM
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.
by axegon_ on 4/14/20, 8:41 AM
by greenyoda on 4/14/20, 5:19 AM
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.
by ukoki on 4/14/20, 9:05 AM
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.
by angarg12 on 4/14/20, 9:34 AM
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.
by Adiqq on 4/14/20, 7:54 AM
by TurboHaskal on 4/14/20, 8:08 AM
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.
by bigpeet on 4/14/20, 11:58 AM
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.
by mattlondon on 4/14/20, 8:22 AM
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
by ltbarcly3 on 4/14/20, 8:36 AM
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.
by stefanve on 4/14/20, 9:09 AM
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.
by lmilcin on 4/14/20, 8:59 AM
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".
by hamburglar on 4/14/20, 8:29 AM
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.
by mothsonasloth on 4/14/20, 8:47 AM
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?
by santoshalper on 4/14/20, 7:56 AM
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.
by reallydontask on 4/14/20, 8:10 AM
I'm going to use this from now on to explain whiteboard interviews
by sgt on 4/14/20, 8:36 AM
by W0lf on 4/14/20, 8:18 AM
by flipcoder on 4/14/20, 8:49 PM
by meritt on 4/14/20, 7:19 AM
by t5sjnrtjnrfds on 4/14/20, 8:37 AM
by gridlockd on 4/14/20, 8:38 AM
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.