内容简介:At the time of writing,Good.There's lots of agreement that developer hiring is broken. But there's also disagreement, or at minimum, a general feeling of helplessness: if technical interviews aren't the best way to hire developers, what else is there? When
At the time of writing, my last blog post on the subject of hiring has over 150K views and generated a lot of great discussion . It touched a nerve.
Good.
There's lots of agreement that developer hiring is broken. But there's also disagreement, or at minimum, a general feeling of helplessness: if technical interviews aren't the best way to hire developers, what else is there? When I read such comments, sometimes I wonder how sincere the question really is. Because ultimately, what do you get if you take away the technical developer interview? What are you left with?
Well, what you're left with is what every single other profession in the entire world considers sufficient when hiring .
Let's be clear here: the way developers are hired is not the norm. It's the exception. No other industry or profession does what we do.
- 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"
- When a lawyer is in an interview, they're not asked to recite legal cases on the spot.
- When a surveyor is in an interview, they're not asked to eyeball how far away a random point in the distance is.
- When a digital artist is in an interview, they're not asked to rapid sketch a portrait with a rusty spoon.
Our profession is uniquely broken. We fucked up. We are, simply put, doing it wrong. So how do you hire amazing developers without doing a technical interview?
In every other profession, the "skill assessment" portion of the hiring interview is fundamentally anchored around two key pillars: I) past performance and experience and/or II) portfolio. Why is this not sufficient for developer hiring? Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?
There's one reason I've heard several times now and it's a false belief I use to harbor also, so I want to talk about it. And sadly enough, it actually has nothing to do with technical skills and more to do with low empathy hiring managers: it's the myth of the developer that can't code.
The myth of the developer that can't code
There's a myth about developers that absolutely needs to die. Here’s how it goes: "I once met a developer who claimed to have 7+ years of Python/Java/whatever and when I sat them down in an interview they couldn't even write FizzBuzz."
I used to think I had met such people (with surprising frequency) too when conducting interviews, but then one day I realized I was the one that was wrong. Very wrong. Let me explain, because this myth needs to die.
If you're a developer working at a typical company, you probably don't write code every day. In my career, I've gone for multi-month stretches where I haven't written any code at all. I've spent months setting up and testing a complex MDM solution for iOS devices. Another time, I worked extensively on a CI/CD pipeline. Or I did a lot of code reviews. Or fixed up some CSS errors. Or wrote documentation. Or fixed up cache busting CDN issues. Or spent days pouring through PostgreSQL logs. Or read about and tried to make front-end accessibility improvements. Or talked to customers about their pain points and then summarized them and made recommendations for management.
And then there have been other periods of my career where I've had to juggle at least 10 different technologies simultaneously. I'd jump back and forward all day between iOS development (Objective-C), front-end development (JavaScript, React, Webpack, HTML, CSS), back-end (Python, Django, Celery, Postgres), and more. I'd hack nginx scripts, fight with AWS, ponder about the best HTTP status code to return in some obscure situation, fight a Promise, wonder why my IDE keeps crashing, and on and on and on.
Our jobs are inordinately complex and the array of tools and technologies we work with daily is dizzying. And that's just the tech side of things.
Now here's the crucial bit. If you pull me aside during any such period - for example, let's say after I had spent weeks doing nothing but pouring through PostgreSQL logs and making query performance improvements - and ask me to, on the spot, in a high pressure situation, fix a Python bug (maybe I'm being asked to fix a production outage costing 1 million dollars/minute to match the interviewing pressure stakes) there is a good chance I will absolutely fuck up something trivial. It doesn't matter how many years experience I have or how good I am.
Empathy
The myth of the developer that can't code exists for one reason, and one reason only: we lack empathy.
We lack the empathy to put ourselves in the shoes of someone else, put on the spot, under high pressure, and asked to recite the words to one very specific song out of the thousands of songs we are able to sing as part of our job.
That's it. That's all it is. And it's obvious this is true:
Senior developers brag all the time on Twitter about how they spend hours tracking down a single missing '=' sign or forget trivial language features. I've read comments like this a hundred times from well-respected and prominent developers. And we all laugh about how often we have to refer to documentation we've been working with extensively for years and years. We laugh at how we can google obscure technical problems we're having and find our own blog posts as answers.
And yet we throw all this away, and in an interview setting attribute a missing '=' sign...this inability to perform an arbitrary task in a high pressure, tense, and unfamiliar environment...we attribute this to instead be a signal the interviewee is an idiot! Despite having a CS degree, positive references, a strong GitHub history, multiple shipped projects, and a strong history of employment, they must be a faker !
Read that last sentence again and tell me who's the idiot?
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.
Look, let's be clear here. There are of course, in reality, some people who are faking it. Maybe you accidentally hired one once? It happens. But I suspect there are no more developers that cannot code than there are lawyers that don't know the law, or surveyors that don't know how to...I don't know... survey , I guess. Our industry isn't rife with fakers - it's rife with low empathy people. The myth of the developer that can't code is born out of a lack of empathy and a failure to appreciate that truly great developers tackle a wide variety of tasks and aren't just leetcoders hacking away on algorithms 24/7.
以上所述就是小编给大家介绍的《The myth of the developer that can't code》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Orange'S:一个操作系统的实现
于渊 / 电子工业出版社 / 2009-6 / 69.00元
《Orange S:一个操作系统的实现》从只有二十行的引导扇区代码出发,一步一步地向读者呈现一个操作系统框架的完成过程。书中不仅关注代码本身,同时关注完成这些代码的思路和过程。本书不同于其他的理论型书籍,而是提供给读者一个动手实践的路线图。读者可以根据路线图逐步完成各部分的功能,从而避免了一开始就面对整个操作系统数万行代码时的迷茫和挫败感。书中讲解了大量在开发操作系统中需注意的细节问题,这些细节不......一起来看看 《Orange'S:一个操作系统的实现》 这本书的介绍吧!