▲ 79 points
back
37 comments
>I have found that raw coding ability is easily the most important quality to look for.
I so strongly disagree with this. Strong coding ability is easily the most important quality I look for in my interns. For everyone else some level of coding ability is required - there is definitely some floor below which you cannot function. But anything beyond a junior engineer what I'm looking for is understanding of how coding solves a problem. How can you map requirements to scope your solutions, how does the end application shape the architecture of what you're going to write.
I think this points at a certain problem with software hiring, where you'll put a candidate through 10 interviews all of which test the same thing and if they get lucky you hire them. if they get unlucky and miss an optimization or assumption or trick in one of the interviews, too bad. Might as well do 1 coding interview per candidate, then take the resumes of all the people who pass and throw half of them in the bin - because you don't want to hire unlucky people.
What we're really often saying is "We haven't actually figured out what makes a good engineer and how to test it so we're just going to only test coding skills repeatedly".
> then take the resumes of all the people who pass and throw half of them in the bin - because you don't want to hire unlucky people
I laughed when I first read this, but then I read it again and can see a bunch of hiring managers actually taking it as serious and good advice due to Poe's law.
My experience is that raw coding ability is basically unteachable. At least by the time someone looks to be hired. The more "soft" stuff is easy to teach. Once an engineer burns their fingers on it he will learn it. So I would definitely look for raw coding skill. The rest is relatively easy to pick up.
My experience is the opposite - you can easily guide someone on a path to learning how to code, but the 'soft' skills you mention are often impossible to change in someone: like how they interact with peers, or how they approach challenges, or how they learn. These things are infinitely harder to evaluate during interviews but have far greater impact on your impact at work, as far as I can see.
You're mistaking average/good developers for great ones. There is definitely a gap between those and raw coding ability at that point is the one skill that you can't teach without fundamentally changing one's mental state. Soft skills definitely have that same issue, but to a significant lesser extent
The question then becomes, do you need great developers? And that depends on what you are doing.
A lot of the engineers I've worked with have often had extreme short-comings in their quality as an engineer because they have huge pride in their abilities to code. The result is re-writing stuff, building stuff that's neat rather than needed, failure to communicate and learn from others, failure to share knowledge and teach. And the worst of it, it's very difficult to persuade them that any of that is their job.
Previous discussion https://news.ycombinator.com/item?id=31047409
Hope this spreads. When I've had code up (find-a-bug-and-add-a-feature exercises), we could talk about qualities of the code and I would get useful signal.
To be honest, learning to code was a complete waste of time.
No one in their right mind would jump through all of the hoops required by the software world's completely insane attempts to filter people out of their hiring processes, all while complaining about being short handed.
The obvious takeaway is that none of these companies are qualified to be writing code at all, because they can't manage themselves. How are they going to manage a codebase if they can't manage their office head count?
>To be honest, learning to code was a complete waste of time.
Counterpoint: If the only reason you learned to code was to get hired, you'd be correct. Many learn it because they are fascinated by computing, and desirous of being able to make computers do things they previously could not.
On the other hand, totally with you on hiring dysfunction.
"Write a function that reverses letter order of words in a string.".split('').reverse().join('').split(' ').reverse().join(' ');
cant read code tho, ill show myself out.
In all seriousness, I like the idea. No one seems to know how to get interviews right. I kinda liked giving the applicant a real task but on second thought reading existing code might be the realest task on a new job.
> No one seems to know how to get interviews right.
Plenty of people do, but good interview processes are highly context-dependent and not trivially transferable.
And most companies just cargo-cult something associated with a name brand, then tweak it to something they're personally comfortable conducting.
I'll quote myself from an old comment:
> Every time one of these interviewing posts bubbles up I skim it to see if the author mentions things like: company size, team composition, the nature of the work the team is doing, the nature of the industry the company exists in, the way hiring decisions are made, the desired properties of their hiring process, their offer rate, acceptance rate, turnover rate, the amount of time positions tend to stay open for, or really just anything that would offer some context on what, specifically, their interview process is optimized for or achieving.
> Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.
This post is more of the same.
I had an interview with LINE that I really enjoyed. I prefer take home assignments, but their homework wasn't to code, it was an intentionally bad project. You could fix the problems and they would review your code or you could just state your findings.
I feel like it was the best of both styles of interviewing. People who hate in interviewing whiteboarding can show their skills on their own time, but if you're optimizing for packing in as many interviews in as possible you haven't written any unnecessary code.
>Write a function that reverses letter order of words in a string.".split('').reverse().join('').split(' ').reverse().join(' ');
Oooo. Sorry. Hard pass. Those symbols are redefined as something else in the context in question.
I don't give a shit if you can write in your favorite lang. I give a shit you can mentally my context and ask the right questions to get productive quickly, or build up your own from scratch while trying to mesh with something already there.
Argh.
...you can mentally [model] my context...
Always hoisted on own petard.
Point still stands though.
Reading + comprehension > writing.
> No one seems to know how to get interviews right.
Because it's all theater really. I've reduced the goal of my interviews to getting an answer(any) to the question "is this person a charlatan?".
There are fewer people than open positions and there are definitely fewer competent people than open positions.
I wish HR around the world would make do with what's available, filter out those who are actively harmful and focus on training.
This is actually a really smart idea... and it's how I gauge how good a developer is on my own team anyways...
A junior/intern can barely understand the code, has little to no knowledge of the complexities of the code-base, and can barely produce a function that will not have an unintended side-effect elsewhere...
A mid-level developer or one with a cursory understanding of the code-base/domain will grasp the general concepts and have some idea of what to fix.
The senior level developer barely needs to read the code anymore, but they can ingest the code-base quickly and understand and explain the whole code-base to e.g. a junior/mid-level effectively. They are likely to immediately know the fix, and how it will likely effect multiple downstream projects.
OFC skill can push a developer between these categories - a low-skilled senior may be closer to an upper-range mid-level developer, and a highly skilled junior may be closer to a mid-level developer, but this is how experience seems to tend to affect a developer's efficacy in my experience.
I'm baffled how you think a senior can just sense the codebase without reading and effectively explain it even to a junior, who as you just described can barely understand the code. I think you are describing a topcoder who is working with a small, well written codebase and is familiar with the domain and stack, most of which in my experience is quite rare.
You’re painting it too binary. Once you’ve seen a few dozen codebases you get pretty good at recognizing the patterns. A senior engineer could/should absolutely be able to familiarize themselves with the general structure of a new codebase in a matter of minutes/hours to the point that they could reasonably start directing a more junior engineer within it.
It’s not “go to this file and do X, Y, and Z starting at line 105”, but more like “Ok so it’s likely that the source of this data is coming from a feed, track down the feed consumer by grepping for [upstreamservice] in the feeds directory, and from there we can get a look at what we’re doing with the incoming feed data”
That's different than not reading the code. Technically, that's applying tool assisted reading techniques to quickly determine what subset of code to read.
I still find seniors are terrible in that they assume they know what code is going to do without having read it, or they refuse to learn the domain first.
I don't think that the things we're saying are mutually exclusive
I've seen this happen but without that "without reading" part. I've had a coworker, who about a 1-2 weeks after starting working in erlang (without prior exposure) on our big codebase was already able to contribute some fixes and soon new functionality and he was not even considered as senior dev when hired. Most of my coworkers are experienced and also able to work on new codebase pretty soon if required. They are not that rare.
A big codebase is full of the same patterns of every other codebase. If you've been doing it for a decade you'll recognize them.
Every codebase I've seen has a ton of brand new WTFs in it. If you've been doing it for a decade, you've seen between 1 and 8 codebases. A mix of "yeah yeah everyone does that" and weirdness bespoke to that culture. The "yeah yeah everyone calls 'new' to get a new object" isn't what needs fixing.
Seeing 8 codebases in a decade is a bad sign. I've significantfully contributed to maybe 30, contributed to at least 100 others, and read large chunks of 100s on top.
> but over the years I have found that raw coding ability is easily the most important quality to look for
Sorry but having a decent team player is generally a lot more use in my opinion. Smart devs who are divas are bad, divas who thinkk they are smarter than what they are are even worse.
I think that this would be particularly useful to gauge the approach of the engineer to coding. Is it practical and no-nonsense? Is it abstractions are everything and having variable called a and b are a “good idea” because it makes for clever code? Is this architecture tending towards growth or being so unwieldy that in a few months there’ll be nothing better to do than rewrite it?
The more time I spent coding the more I realize that I don’t code for myself, I code for my team and if what I’m making is not painfully obvious somebody (including future me) is very likely to break something in the future because they didn’t understand what the code I wrote was supposed to do and how it was doing so.
I like the idea, might not bother with the whole "actually execute it to see if it produces the expected result" thing, but otherwise it slots into the "so obviously a good idea I can't believe I hadn't thought of it before". I can't say I've ever been asked in an interview to review a piece of code and predict what bugs it might have etc., but it's definitely a skill I use on the job all the time.
I did this when I looked after interviews.
I'd print off a piece of legacy code that was particularly ugly and ask them to review it.
I'd tell them I wasn't looking for silly stuff like parser errors and instead was just looking for their opinion on the code. How they thought it worked and how they would improve or do it differently.
It was mostly just an interview prompt with a consistent starting point that lead to interesting insights about the interviewee but generally had repeated talking points across candidates.
This is it. Pack it up everyone. It's simple yet the signals are hard to fake. It's basically about taste and that only comes with experience.
> Some of you might want to know how to develop your skills to do well in such an interview. [---] The easiest way is to crank up some non-trivial side projects that you care about.
Contribute to existing open source! The next PR you help with is likely in a code base very different from the previous one you saw. Plus, you'll have someone give feedback on what you write.
Please don’t do this with fake functions. It’s very hard to read code that doesn’t have any purpose.
Not quite the same, but dead branches in code are quite common in my experience and being able to indent off them is pretty useful.
Identify*
Very important point from the OC:
"Before I ask my questions to candidates, I calibrate my questions against people I work with so I have a realistic expectation for how to gauge the skill of the candidates. Calibrating the questions also helps me refine them and weed out confusing parts."
Yes! Exactly!
I was once on a hiring committee that did it right. We created an interview toolkit. We then validated, tested, practiced our interviews on each other and own our people.
I've never seen another org do recruiting, screening, interviewing, and onboarding with such intent.
Like project management, requirements, architecture, QA/test... Everyone's winging it.