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!
The myth of the developer that can't code
41–50 of 79 posts
Re: The myth of the developer that can't code
#42This 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.
Re: The myth of the developer that can't code
#43> 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
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.
Re: The myth of the developer that can't code
#44Best 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…
4-6 hours is a ridiculous amount of time, and certainly not something many people coud fit in a few lunch breaks.
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.
Re: The myth of the developer that can't code
#45I 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".
Re: The myth of the developer that can't code
#46Earlier quoted context omitted.
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. He…
> 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
I've been implementing Dynamic Programming, from scratch, just yesterday. But it wasn't for work either.
Re: The myth of the developer that can't code
#47[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?
Re: The myth of the developer that can't code
#48This 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 m…
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. He…
> 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.
Re: The myth of the developer that can't code
#49I 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 the…
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.
Re: The myth of the developer that can't code
#50Accountants, 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 jum…
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...