>Instead of “how can we find the smartest people?” think about “how can we find people who will make our team stronger?”
I would have thought that was obvious? Why would you hire someone unless you had a need for their talents?
I guess I'm probably thinking small-business. At the biggest companies, they probably just hire and hope to fit them in because hiring for exact needs doesn't really scale.
My experience is this obvious perspective vacates with any level of moral maze. The hiring processes kind of require it --> getting headcount approval requires defining a role and arguing how it will lead to better outcomes and then finding/interviewing candidates takes months of time. If your priorities shift in that time...well now you have to shoehorn whatever candidates you get into the role definition you gave before even though you know at that moment they'll be working on something different.
And then priorities shift again before they start. Leaving you not knowing what they'll be working on, but also certain you'll need extra hands on something sooner rather than later...
AND SO: "give me a smart generalist that specialized in these 8 technologies that make up the entirety of our product" becomes the only viable hire.
> And then priorities shift again before they start. Leaving you not knowing what they'll be working on, but also certain you'll need extra hands on something sooner rather than later...
> AND SO: "give me a smart generalist that specialized in these 8 technologies that make up the entirety of our product" becomes the only viable hire.
I mean, unless you were going to fire this person when the project you got head count for is finished, that's pretty much what you should have hired for anyways?
I suspect it's a surprisingly easy trap many of us fall into. It's not about hiring someone without a need for their talents, it's that interview processes can amplify team weaknesses if the signal chosen closely aligns with the current team strengths, and as a result is less likely to fill skills and knowledge gaps.
And this is a sort of natural trap, since the skills we're best at judging are things we're already good at. I suspect these biases can happen at large and small companies. It's constantly on my mind that the signal we use for my interviews are too closely aligned with my own preconceptions, especially when it's a problem space I've spent alot of time in, and may be foreign to the candidate.
Your mindset is modeled after a simple selection process. Big companies often have pipelines for selection processes. HR does screening, leader does interview, manager approves.
Each step of the pipeline, the responsible has to optimize for what the team needs. In practice, each one is evaluated by what the layer above thinks. HR optimizes for CVs the leader likes, leader optimizes for profiles the manager likes.
Specially at large corporations, managers are removed from the daily needs and don’t have the context to evaluate if the person is the optimal fit for their future tasks, so they concern themselves with evaluating “raw talent” (obviously in a very subjective and biased way). Same thing happens with HR doing the screening.
So “talent” is defining both at the beginning and the end of the pipeline, it’s no surprise the end result is an inconsistent hiring pipeline.
Along those lines I'm getting shades/hints that people hire to fit a workforce that resembles something like how they think their software stack works?
Sounds good in theory but in practice people aren't actually programs/cogs and stacks are messy?
Another aspect is making it impossible to assemble parts any way but the correct way. For example, you can write C code like this:
for (i = 0; i < 10; ++i);
do_something();
A colleague of mine, a very good programmer, was stymied by this for a full day. The next day I added a warning to my C compiler for it. As time went on, this warning became commonplace in other compilers.
But in D, I didn't make it a warning. I made in an error. A ; cannot be used to create an empty statement, that can only be done with { }. I still can't believe C/C++ have never made that an error.
Another one is:
if (a < b < c) ...
That doesn't do what one thinks it does. So in D it's an error.
D is better because so many unnecessary things in C and C++ are minefields, and instead of warning the user, they're just illegal. (All have ways of doing the equivalent if one really needs to.)
Oh it took a while until I noticed the extra ';' :- ) It'd likely have slipped past code review o.O
> impossible to assemble parts any way but the correct way
Hmm make me think about database constraints & foreign keys :- )
> As time went on, this warning became commonplace in other compilers
Nice that different languages can help each other become better :- )
> D is better because so many unnecessary things in C and C++ are minefields
I remember long ago when coding C++, we had to add a bunch of macros in each C++ class, to remove dangerous-by-default C++ auto generated things (like the copy constructor that copied pointers). I guess you know a lot about such things. D and Rust seems nice :- )
Hmm there's something similar in the SRS book by Google, they call it "failure domains" (I haven't read all of it though).
> Monitors: If the output is outside some preset bounds, the system is shut down
Maybe in software, becoming read-only can be a similar good idea, when something looks weird
> Deadman: A deadman is a hardware timer switch added to a computer system that shuts it down if it isn’t regularly reset.
This is something I'm planning to add to the software I'm developing :- )
It's forum / blog-comments software, and, in case the admins have been away for too long (maybe vacation for some weeks), the forum would become read-only, maybe even retroactively hide some risky comments & discussions, until they're back — so there's always humans around that can remove toxic troll comments and such things.
> Improving the quality of that component by a factor of 10 will get us there, but at a cost explosion of 10 times the price. But suppose we add in a backup component B, that also has a 10% failure rate. The odds of A and B both simultaneously failing are 10% of 10%, or 1%. This is achieved by a mere doubling of the cost instead of an order of magnitude increase
I think it's interesting that this at the same time, doubles the attack surface, for hackers? Although the failure risk gets down to 1%, now the hackers can try to break in into both A and B? Hmm. I wonder if there're any ways to avoid this tradeoff, ... Maybe there aren't, in the same way as it's going to be 2 x expensive, too
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.
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.
> that was obvious? Why would you hire someone unless you had a need for their talents?
To me, that sounds like you think of weakness in terms of "Oh, our UI sucks, let's hire a javascript developer." But is that really what the article means? Could weaknesses be more abstract things like "low trust", "failure to speak up", "inability to change according to market needs"? Do you know many teams that really know their core problems and actually try to solve them?
If you’re hiring junior engineers, you can’t pick them for talents because they don’t have any. You hire them expecting to be negative for a little bit and learn on the job. If you don’t do this you’ll run out of senior engineers.
On the other hand, if you can work with them it’s good to get people who will contribute things outside the job description.
I would have thought that was obvious? Why would you hire someone unless you had a need for their talents?
I guess I'm probably thinking small-business. At the biggest companies, they probably just hire and hope to fit them in because hiring for exact needs doesn't really scale.