Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t hire top talent; hire for weaknesses

benjiweber.co.uk

Post reply on HN
Print view View original

161–168 of 168 posts

Re: Don’t hire top talent; hire for weaknesses

#161

Post by Dudeman112 »

jstummbillig wrote: post #105
tsimionescu wrote: post #97

Earlier quoted context omitted.

Not sure why you think FAANG is getting the cream of the crop. Looking at stuff like Rob Pike's comments about Go's use for the general Google employee base [0], I think there is quite a lot of misalignment between the aura of mystique from the outside and the situation as seen from the inside. [0]“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out…

> Not sure why you think FAANG is getting the cream of the crop. The best coders can demand the highest salary. If you can afford to pay the highest salary you are in an advanced position position to get the best coders. FAANG can afford to pay the highest salary. Anecdotal evidence to the contrary does not cancel this mechanism.

Ah, the myth of tech meritocracy.

As a community are we still stuck pretending that being the real deal will be better for your career than being able to convince other people you are the real deal?

Re: Don’t hire top talent; hire for weaknesses

#162

Post by proc0 »

Gustomaximus wrote: post #133

I had an interesting call once asking me to interview for marketing job at a women's online fashion business. I said to the person "not sure IM the right person, I'm male and have zero interest in fashion". To which she replied "That's great because I've got plenty of that fit, I want someone that looks at this more as a business than personal interest" I never interviewed as they salary was low, but I really liked t…

That's rare in my experience. It seems every startup wants you to think their area is the most exciting in the world and you are full of ideas of how to move the product forward. It's like wanting detailed specs means you are unmotivated, just because you're not interested in making decisions in that space, whether to use one color over another or think ahead about the behavior of the feature, for development it is technically irrelevant, as it's all just translating to code, but business people will have none of that attitude lol.

Re: Don’t hire top talent; hire for weaknesses

#163

Post by jstummbillig »

bananaface wrote: post #121
jstummbillig wrote: post #105

Earlier quoted context omitted.

> Not sure why you think FAANG is getting the cream of the crop. The best coders can demand the highest salary. If you can afford to pay the highest salary you are in an advanced position position to get the best coders. FAANG can afford to pay the highest salary. Anecdotal evidence to the contrary does not cancel this mechanism.

That assumes the selection process is effective, but FAANGs are all monopolies so there's very weak selection pressure for them to distinguish candidates correctly. They don't get punished for their mistakes. I'd argue the people at FAANGs are the people who are best at hitting the requirements of a FAANG. That's still a competition and they'll brain drain from smaller companies, but it creates arbitrage on unrecogni…

> [...] FAANGs are all monopolies so there's very weak selection pressure for them to distinguish candidates correctly. They don't get punished for their mistakes.

But they do. You see that happening every time a big company fails. It just takes a while longer because of the inertia the company has built (for example by having made more good than bad hiring decisions in the past).

I understand that good people fly under the radar all the time. Also I understand that there are startups that certainly have a higher skill level than Google does (anything else would be shocking, considering Googles immense work force).

Not all hiring decisions are good. Maybe most aren't. There's just no reason to believe that Google would be any worse at it than Random Small Company, considering that more money and expertise certainly helps when trying to hire the best talent.

Re: Don’t hire top talent; hire for weaknesses

#164

Post by KajMagnus »

WalterBright wrote: post #160
KajMagnus wrote: post #159

Earlier quoted context omitted.

> many things I learned designing gearboxes to the D programming language I'm curious about what are some of those things :- ) (embedded software for gearboxes? Or physical design things that were translatable to software?)

I wrote a couple articles about one aspect: https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b40.html which I learned from mechanical design at Boeing. 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 A colleague of mine, a very good programmer, was stymied by this for a full day. The next…

> was stymied by this for a full day

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 :- )

Re: Don’t hire top talent; hire for weaknesses

#165

Post by KajMagnus »

WalterBright wrote: post #160
KajMagnus wrote: post #159

Earlier quoted context omitted.

> many things I learned designing gearboxes to the D programming language I'm curious about what are some of those things :- ) (embedded software for gearboxes? Or physical design things that were translatable to software?)

I wrote a couple articles about one aspect: https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b40.html which I learned from mechanical design at Boeing. 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 A colleague of mine, a very good programmer, was stymied by this for a full day. The next…

> Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html

> Dual Path

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.

> Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html

> 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

Re: Don’t hire top talent; hire for weaknesses

#166

Post by bananaface »

tnel77 wrote: post #127
johbjo wrote: post #107

Earlier quoted context omitted.

> The best coders can demand the highest salary. How would you confirm this with data?

I’m not sure how you confirm this, but I don’t see how it’s not true. Do you (or other people on this thread) genuinely believe that the best software engineers aren’t demanding the best salaries? Who doesn’t want to make more money given the opportunity?

If the industry demands weird or suboptimal practices or has strange evaluation criteria then the people making the most will be the people who are best at the game.

I think the popularity of untyped languages is one example of that. Clearly worse, you're removing an entire class of embedded test and nuking your ability to refactor safely, but huge chunks of the industry don't see that as a bad thing. I'm a worse programmer because I've spent so much time in Python.

Re: Don’t hire top talent; hire for weaknesses

#167

Post by jfrunyon »

lmeyerov wrote: post #147
jfrunyon wrote: post #83

Earlier quoted context omitted.

You are the one who said body of work, the other person said portfolio. Stuff that you can't share isn't a portfolio.

most students don't work on classified fbi projects, see in the thread on some of the projects I've seen undergrads involved in that are more demonstrative than grades. a project portfolio is just a cv section that focuses on the projects and your involvement, and hopefully ways for the interviewer to see it and the code, but even descriptions and screenshots go far for the interview conversation. most good cs progra…

Many of the best programmers I know never went to school for programming.

Re: Don’t hire top talent; hire for weaknesses

#168

Post by [deleted] »

jstummbillig wrote: post #163
bananaface wrote: post #121

Earlier quoted context omitted.

That assumes the selection process is effective, but FAANGs are all monopolies so there's very weak selection pressure for them to distinguish candidates correctly. They don't get punished for their mistakes. I'd argue the people at FAANGs are the people who are best at hitting the requirements of a FAANG. That's still a competition and they'll brain drain from smaller companies, but it creates arbitrage on unrecogni…

> [...] FAANGs are all monopolies so there's very weak selection pressure for them to distinguish candidates correctly. They don't get punished for their mistakes. But they do. You see that happening every time a big company fails. It just takes a while longer because of the inertia the company has built (for example by having made more good than bad hiring decisions in the past). I understand that good people fly un…

[deleted]
Post reply on HN