There's a lot of talk from engineers about how this process is broken, but never a solution.
What gives?
Please stop the coding challenges
311–320 of 493 posts
Re: Please stop the coding challenges
#312Earlier quoted context omitted.
But is there a good way to find the "better possible hires" which doesn't have other significant disadvantages? If you have a convincing method of doing that, many companies would be interested in your ideas.
interview followed by paid internship/probation. watch them work on your real system. Keep them if they're good.
Even with probation the cost difference between saying no at interview and firing them during their probation is enormous.
Re: Please stop the coding challenges
#313Earlier quoted context omitted.
And why is that? Do you not agree that time is our most valuable asset?
Interviewing is a time investment for both sides. Should the company charge you to evaluate your skills?
If someone gives me a take-home assignment that I spend 4 hours on, there is no commitment of time on their side. They may decide to not even look at the results. They may spend five minutes on it.
That's exactly my problem with take-home code challenges. If I go to an interview, and they waste my time, they have to waste their own. But with a take-home assignment, they can waste my time without wasting their own. That may lead them to be more wasteful of my time.
Re: Please stop the coding challenges
#314I once ended a job interview at a company because of their coding challenges at the end of a 2-3 hour interview. It was a job for a PHP developer working in a DDD environment. They were asking people to do algorithms, the last one just took the cake because it was completely unnecessary. The question made sense: how do you add to very large numbers together? I assumed the key knowledge they wanted was that the number…
Ugh, I got that question in an interview. Only they wanted me to write up a basic arbitrary precision math library, in C, on paper. (I may have chosen to do it on paper.) It was harder than I expected. I didn't do that well and didn't manage to finish in the time allotted -- halfway through, I switched from encoding things as ASCII numerals to base-256 binary (or the reverse?) -- but it was enough that the interviewer said it was clear I understood what was required. I got the job.
I thought it was a hard but fair question. I still feel bad about not doing well. It wasn't all that close to what I'd be doing in the position, but it wasn't unrelated. Perhaps if it were a PHP role I'd be more bothered? But even there, it seems like one way to check if someone understands what's going on under the hood, so as to not naively do expensive stuff without realizing it. The fact that one should not write their own library, and that if you tried you should get code reviewed to hell, isn't relevant if that's the purpose.
Re: Please stop the coding challenges
#315> When was the last time you had to debug an ancient codebase without documentation or help from a team? All the time. 300-400k SLOC in C++. Legacy in the sense that there were no tests of any kind. Little-to-no documentation. Solo developer at the tiny company. Fix bugs and add features while keeping the system available to the tens of thousands of users. A more recent example: here’s a patch for a critical feature…
Real. Engineers who don't think they have this problem, are engineers who see their dependencies and the lower layers of their stack as ossified black boxes they "can't" touch, rather than something they can reach into and fix (or even add features to!) when necessary.
IMHO the willingness to "dig your way down" to solve a problem at the correct layer (rather than working around a bug or missing feature in a lower layer by adding post-hoc ameliorations in "your" code) is one of the major "soft skills" that distinguishes more senior engineers. This is one of those things that senior engineers see as "the natural thing to do", without thinking about it; and fixes that take this approach work subtly to ensure that the overall engineered system is robust to both changes up and down the stack, and to unanticipated future use-cases.
And contrariwise, fixes tending not to take this approach even when it'd be a very good idea, is one of the central ways that a codebase starts to "rot" when all the senior engineers quit or are let go/replaced with more-junior talent. When, for example, every input-parsing edge-case is "fixed" by adding one more naive validation regex in front of the "opaque, scary" parser — rather than updating the parser grammar itself to enforce those validation rules — your codebase is actively evolving into a Ball of Mud.
Of course, the tradeoff for solving problems at the "correct" layer, is that you/your company often ends up having to maintain long-lived, trivial, private hotfix-branch forks of various ecosystem software you use in your stack. More often than not, the upstreams of the software you use don't see your problem as a problem, and so don't want to take your fix. So you've just got to keep it to yourself.
(Funny enough, you could probably trivially measure an engineer's seniority through a tool that auths against their github profile and calculates the number of such long-lived trivial private hotfix branches they've ever created or maintained. Much simpler than a coding challenge!)
Re: Please stop the coding challenges
#316Companies aren't incentivized to eliminate false negatives in hiring (talented people getting overlooked), they just need to make sure there are no false positives (bad hires). I'm guessing it's probably rare for companies to think about the bigger picture, like the long term health of the economy and nation, where it's actually really bad if there are a bunch of really talented people that are being underutilized.
If I were interviewer, I'd probably do a coding assignment that builds on an already existing mini codebase, quarter or half day assignment (2-4 hours), with a strict time limit to turn it in by the end of the allotted time. It would test for someone's ability to read unfamiliar codebases, with the codebase being reasonably small for the little time that's available, and the ability to build features on top of it, to write clean readable code compatible with the codebase, etc. And an a 30-60 minute more open-ended informal knowledge interview to gauge how knowledgeable the candidate is and where their strengths and weaknesses are. And previous work would probably be a good indicator, like open source work and/or previous job experience.
Re: Please stop the coding challenges
#317> When was the last time you had to debug an ancient codebase without documentation or help from a team? All the time. 300-400k SLOC in C++. Legacy in the sense that there were no tests of any kind. Little-to-no documentation. Solo developer at the tiny company. Fix bugs and add features while keeping the system available to the tens of thousands of users. A more recent example: here’s a patch for a critical feature…
> All the time.
Not just all the time — right now in the other browser tabs I'm ignoring in favor of this one lol
Re: Please stop the coding challenges
#318The more people online complain about coding interviews, the more confident I am that they are the absolute best way to filter candidates for a software development job. Across the industry there are way too many talkers/pretenders/meeting schedulers and not enough people who can roll up their sleeves, jump into the code and actually get stuff done. And this problem becomes worse at higher levels. You can bitch about…
Agreed. And a lot of people will say that you can just memorize a bunch of leetcode problems, but I've always created custom coding problems when I've acted as an interviewer so good luck finding the solutions online.
And frankly, if they're able to adapt a random leetcode problem to be able to solve the coding test that I give them, then that's exactly the kind of adaptability that I'm looking for in a prospective software engineer.
Re: Please stop the coding challenges
#319A small anecdote. A partner of a friend quit their job earlier this year. They then took 4-6 weeks to prepare for each interview with Big Tech companies (4-6 weeks for Meta, 4-6 weeks for Stripe, etc.). Along the way, they also took random interviews just to practice and build muscle memory. They would grind leetcode several hours a day after researching which questions were likely to be encountered at each Big Tech.…
If you talk to hiring at some of these companies, it is intentionally designed to be this way so that it is fairly meritocratic. In other words, anybody, regardless of what university they went to or what courses they took out what advantages or disadvantages they had, can learn this stuff in a couple of months if they have what it takes for the role. And because the skills are so standardized, the process is pretty…
The thing I think is funny in all this is that hiring a new manager is fraught with a high amount of risk (more so than an engineer), but they don't have nearly the level of hurdles to get over. Does the company interview past employees of the manager? Did the manager applicant have alcohol, drug issues, or weird sexual things he did to his direct reports or others? Or, instead, would you enjoy his presence on a golf outing?
I know one manager who had issues with all three got hired at Google. So. Think of the poor HR person that will have to clean up that mess.
Re: Please stop the coding challenges
#320Earlier quoted context omitted.
> Categorizing yourself exclusively as "a Ruby developer" is a career trap. And a lucrative one at that.
It’s lucrative if your bar is 6 figures. No engineer that makes 7 figures calls themselves a ruby developer with the exception of DHH.
Bro this comment is so out of touch it's ridiculous. A 6 figure salary is lucrative. 7 figures is a crazy pipe dream that basically nobody will ever experience.