I just failed a coding test.
A lot of you are thinking "so what?", but here's the thing - it's quite possibly only the second coding test I've ever done, & the last one was 1998 (in C). In the meantime, I've been interviewing dev candidates quite regularly over the years, designing tests, developing ideal solutions in various languages, assessing the great unwashed brought before me.
I just failed a coding test.
Sure, I have some very reasonable excuses. I tried to set up a dev env on my Chromebook & spent so much time configuring the IDE to cope with Typescript that I forgot to actually practise some Typescript, &, oddly, Typescript would have been particularly useful on this occasion, but it had all leaked out of my brain in the process of ensuring that I could indeed run & debug said Typescript if I could actually write it. I can, by the way, along with a wide variety of languages that I have happily worked with over the last 35 years.
The problem is that I am not a <insert language> expert. I can move to a different job, dump the contents of my brain, & be quite comfortable in Chicken, for example, if that's what's required. I don't see problem solving as language-dependent. The programming language is just the tool at hand - like the IDE or the OS. Change one, & it doesn't stop me from working. It does, however, stop me from passing coding tests.
Actually, it only stops me from doing live tests, because if I spend half an hour looking at code to 'get' a language again, then I can do a take-home test easily - I've done that before. I wish I'd remembered this salient fact yesterday. Of course, it didn't help that the very kind interviewer suggested I write pseudo-code or use another language, & I plumped for Kotlin & realised that my IDE didn't have a clue where to go with that, either. I should have done Java, but I was already not thinking straight.
Live tests are supposed to give the interviewer an idea of the candidate's thinking skills & ability to communicate that thinking, rather than mastery of an IDE or even a language. If their approach to coding covers algorithm implementation, data structures, coding style, a nod to testing or test-ability, & an inkling of performance & memory implications, then you're on a winner. If they code that up like a machine, then that's confidence, at least (just check for arrogance).
However, that doesn't relate to the real world. I've just come from a large software company with products & tools & infrastructure & ... stuff. To fix a problem from the field, you analyse, you test (online, in prod or staging), you write more tests to prove your theory of what's wrong, you implement a code change to fix the problem, you write tests based on your implementation, then test online before getting peer review & such. New features only differ slightly. There's very little greenfielding where someone says "Here's a brand new problem, & I want you to start with an empty code project". Even new products & services start with a pattern, whether it's a microservice template, a plugin for the product, or a base line of configurability copied from the last such module.
Only twice in my career has someone said "Start with nothing; assume nothing". Both became patentable.
Professional developers don't get to write little algorithms in isolation from scratch. I actually think they should do it more often, though, because that's the basis of TDD & unit testing. Write an algorithm, prove it, then plug it into the code base. No-one does that, because of things like dependencies. There's a whole raft of 'stuff' that you need before you can prove that algorithm - like a test infrastructure, JSON manipulation, HTTP client or server implementations - that's already in the project. It's not laziness that makes you shy away from creating a new Maven/Gradle build to then immediately throw away, it's efficiency. I've done something like that a few times - do the work in an existing project, then copy the whole thing & pare it back to what I need as the new project.
I'll tell you who is good at writing one-off, independent, no-strings solutions to small problems: undergrads. In theory, they should be the perfect candidates to fly through live coding tests, because that's how they've been taught to code. Well, it's how I remember teaching them in the 1990s. Now, those students are, like me, giving coding tests to candidates with the belief that it's simple to pass the test themselves.
I'd like to think there's a way forward here.
The first point is to ensure that a coding test is not simply a verification that what someone says in their resume is accurate (never assume it's a lie, either). A coding test, like any interview, is an opportunity for the interviewer to get to know the interviewee & determine the fit for the role, the company, the future. I'm not saying that the code itself is irrelevant, but it's a part of the interviewing process, not a box to tick, a criteria to match. It shouldn't be a trick question that proves how clever the interviewer is, either, because, as always, the interview has to run both ways. You, as interviewer, are being judged as a representative of your organisation.
The second point is that live coding tests only work for someone who is comfortable with that exact process, so nerves, brain-freezes, distractions (like illness), are all a part of that experience. If someone can do an offline test beautifully, then an online is useful if you're looking for someone to pair-program, for example, but not necessarily for someone to work remotely or in isolation.
Most importantly, empathise with the candidate. You don't have to make allowances for their lack of social skills or inability to perform under pressure. That's called being human. If you can alleviate the symptoms, that's under your control, because you're in the dominant role in the conversation. Just don't make things worse by judging performance under unusual circumstances as indicative of how someone can actually perform their job - at least hold that back until you write up the review.
I just failed a coding test.
No comments:
Post a Comment