14 ms·

The myth of the developer that can't code

62 points by nsainsbury 7y ago

otabdeveloper4 7y ago
What can I say? Only LOL. This guy's nuts.
greenyoda 7y ago
> 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.
- BiteCode_dev 7y ago
  Exactly. 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.
- c3534l 7y ago
  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.
gregdoesit 7y ago
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?
- sparsely 7y ago
  Recruitment for accountants etc often includes a technical skills component, I don't know why he thinks it doesn't.
  - peschu 7y ago
    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...
meritt 7y ago
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 7y ago
  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.
Adiqq 7y ago
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?
santoshalper 7y ago
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 7y ago
  > 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 7y ago
    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.
7777fps 7y ago
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 7y ago
  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 7y ago
    > 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.
TurboHaskal 7y ago
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 7y ago
  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.
reallydontask 7y ago
> 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 7y ago
  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 7y ago
    >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 ..
thayne 7y ago
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.
- mixmastamyk 7y ago
  They are, on the job and let go when they can’t perform.
- Cthulhu_ 7y ago
  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.
- ooobit2 7y ago
  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. Maybe engineers need more unconventional tests?
W0lf 7y ago
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.
mattlondon 7y ago
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 7y ago
  4-6 hours is a ridiculous amount of time, and certainly not something many people coud fit in a few lunch breaks.
  - ltbarcly3 7y ago
    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.
  - mattlondon 7y ago
    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.
- scarface74 7y ago
  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.
hamburglar 7y ago
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.
ltbarcly3 7y ago
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.
- deleted 7y ago
  [deleted]
sgt 7y ago
Sounds like this guy is trying to make mediocrity more acceptable. If a developer is not able to do FizzBuzz, something is deeply wrong.
t5sjnrtjnrfds 7y ago
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 7y ago
  Could you put your github in your profile, So that we can see your github?
gridlockd 7y ago
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.
axegon_ 7y ago
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 7y ago
  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_ 7y ago
    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.
mothsonasloth 7y ago
[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 7y ago
  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.
lmilcin 7y ago
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".
ukoki 7y ago
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 7y ago
  > 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.
stefanve 7y ago
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.
angarg12 7y ago
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.
bigpeet 7y ago
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.
deleted 7y ago
[deleted]
flipcoder 7y ago
I believe the fizzbuzz failure thing is largely interview anxiety

62 points by nsainsbury 7y ago

What can I say? Only LOL. This guy's nuts.

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

BiteCode_dev 7y ago
Exactly. 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.
c3534l 7y ago
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.

gregdoesit 7y ago

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?

sparsely 7y ago
Recruitment for accountants etc often includes a technical skills component, I don't know why he thinks it doesn't.
- peschu 7y ago
  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...

meritt 7y ago

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 7y ago
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.

Adiqq 7y ago

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?

santoshalper 7y ago

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 7y ago
> 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 7y ago
  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.

7777fps 7y ago

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 7y ago
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 7y ago
  > 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.

TurboHaskal 7y ago

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 7y ago
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.

reallydontask 7y ago

> 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 7y ago
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 7y ago
  >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 ..

thayne 7y ago

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.

mixmastamyk 7y ago
They are, on the job and let go when they can’t perform.
Cthulhu_ 7y ago
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.
ooobit2 7y ago
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. Maybe engineers need more unconventional tests?

W0lf 7y ago

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.

mattlondon 7y ago

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 7y ago
4-6 hours is a ridiculous amount of time, and certainly not something many people coud fit in a few lunch breaks.
- ltbarcly3 7y ago
  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.
- mattlondon 7y ago
  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.
scarface74 7y ago
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.

hamburglar 7y ago

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.

ltbarcly3 7y ago

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.

deleted 7y ago
[deleted]

sgt 7y ago

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

t5sjnrtjnrfds 7y ago

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 7y ago
Could you put your github in your profile, So that we can see your github?

gridlockd 7y ago

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.

axegon_ 7y ago

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 7y ago
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_ 7y ago
  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.

mothsonasloth 7y ago

[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 7y ago
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.

lmilcin 7y ago

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

ukoki 7y ago

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 7y ago
> 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.

stefanve 7y ago

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.

angarg12 7y ago

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.

bigpeet 7y ago

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.

deleted 7y ago

[deleted]

flipcoder 7y ago

I believe the fizzbuzz failure thing is largely interview anxiety