Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You only need to read a few dozen job adverts to see that tech companies are focused entirely on technical ability and don't hire for other skills. How often do you see "must know Typescript, expert in Docker, passionate about algorithms" compared to "must understand writing documentation, expert in sprint planning, passionate about user value"?

Skills that aren't tech are rarely valued by tech companies despite the fact companies need developers with those skills in order to deliver the best tech. Sometimes the best hire for the team is the second best developer but the best person-who-can-explain-things or person-who-can-run-meetings if explaining things or running meetings is holding the team back.



> expert in sprint planning

Because they need tech expert and not PO?

> passionate about user value

Lmao, this is such a vague and useless statement that it is barely worth commenting.

What the hell is "passion", how do quantify it and how do you use it? What happens when person you hired for "passion" loses it?

> Sometimes the best hire for the team is the second best developer but the best person-who-can-explain-things or person-who-can-run-meetings if explaining things or running meetings is holding the team back.

You test for that during interview. Do you think algo challenge, system design are just writing some stuff on the whiteboard and you're done? You need to explain stuff in such a way that interview wants to hire you.


Sprint planning is a collaboration between dev and product. If your devs aren't good at it they'll agree to far too much stuff in a sprint, or they won't spot what things are blocked, or they'll fail to report what happened in a sprint in the retrospective, which impacts everything from planning the next sprint to writing release notes to when the company can do marketing about a major release.

Hiring developers who are amazing at algorithms but terrible at everything else has huge, far-reaching consequences for everything a business does. Being a good developer is about so much more than writing good code.


> If your devs aren't good at it they'll agree to far too much stuff in a sprint, or they won't spot what things are blocked, or they'll fail to report what happened in a sprint in the retrospective, which impacts everything from planning the next sprint to writing release notes to when the company can do marketing about a major release.

You're describing common sense, not sprint planning.

> Hiring developers who are amazing at algorithms but terrible at everything else has huge

I like this argument from every anti-algo advocate. Because if they're good at algos they're certainly bad at everything else, like you need to sacrifice one to get another.

> Being a good developer is about so much more than writing good code.

Indeed, writing good code is a basis. You can't be good without writing good code, and you can't write good code without knowing basics of algorithmic design and thinking.


> What the hell is "passion", how do quantify it and how do you use it? What happens when person you hired for "passion" loses it?

It's harder to quantify than 'expert in typescript' and maybe ill described and abused, but there are a diverse set of needs when it comes to engineering, it's not just deeply technical, it's also broadly technical with strong planning, entrepreneurial thought process etc.. my, perhaps naive view is the world definitely needs both of these so keep and open mind and stay respectful.. 'lmao' I'm certain you wouldn't do in person, debate is good but cmon, always put the extra effort in to understand and communicate your own gut reactions


Is this really true? In my (limited) experience, the best coders are the ones who understand the technology, understand the hardware, and understand good program structure. "Communication" and "teamwork" are totally unimportant and they're usually organic side effects of understanding the domain. I've done open-source stuff with a total asshole and it wasn't pleasant but the end product was good because he was good, and I learned way faster than with most people.

But I've not been exposed to that kind of corporate environment. Is it really that important? It reeks of corporate buzzwords to me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: