People's intuitions around hiring aren't Bayesian enough. I think a good process reduces down to something like:
- Are they smart? (understands quickly + communicates effectively)
- Are they cool? (won't put poison in the keurig + pleasant to be around)
- Are they high energy? (initiative + action bias)
- Do they have the experience needed to be successful in the role?
Those are pretty strong priors for success. If you find someone with all the above, you've got an ~80% chance of a hit. No need to over-complicate.
In my experience, adding more boxes tends to index towards box-checkers who grew up wealthy. That's how you miss the hyper-smart/diligent state school kids who happened to spend their summers working instead of doing model UN.
I have a 4-quardrant way of thinking about this that's similar.
- Y-axis is "drive"
- X-axis is "aptitude"
- low drive + low aptitude: never hire
- low drive + high aptitude: hire for targeted use cases where you need expertise
- high drive + low aptitude: hire, train, and foster aptitude growth
- high drive + high aptitude: hire on the spot
There's an indirect way of testing for this which is to test for curiosity and lack of ego. My experience has been that candidates with high curiosity tend to have low ego (they know what they don't know and are curious to learn). These candidates make great hires because you can teach them anything.
> People's intuitions around hiring aren't Bayesian enough.
People's intuitions around hiring are extremely Bayesian, which is why we have all sorts of laws and regulations and HR departments that try to counteract various prejudicial priors.
This is pretty much how I hire but also try to gauge "conscientiousness". Some people are smart, cool, high energy and decently experienced but just don't seem to care about the success of the team and aren't the best for a lot of roles. Its hard to judge because extraversion/cool/high energy can appear similar in an interview.
Breath of fresh air to see this at the top. The focus on leetcode always confused me, and this is coming from someone who took all the fancy graduate level algo courses.
It is a super cool story to hear in what jobs somebody already has worked in and a good indicator.
I worked as a dancing instructor assistant and learned so much about people.
This job does not correlate with my current job as a Java/Kotlin/Android dev but was taken quite well by everyone the interviewed me 10 years back.
You just have very little time during a job interview and mistakes are costly.
> Are they smart?
> Are they cool?
...
Are the right questions that need to be answered, but not asked directly.
The article talks especially about what to ask to get meaningful answers.
> adding more boxes tends to index towards box-checkers who grew up wealthy.
Yeah, but that's the point. Those who come from wealth bring connections. Connections are what make or break a business. A mediocre worker with rich parents is far more beneficial to the business than a standout worker that came from the slums.
We built Fly.io resume-blind and without interviews, hiring people at every level of experience without having to make decisions based on that experience. We did it by throwing away all this stuff, ditching interviews, and replacing them with work-sample tests. Some of the best people on our team, the best I've worked with in my whole career, are working here in their first job in our field.
I'm a little grumpy about this "diamonds in the rough" shit. I'm more concerned about what's lurking in the diamond mines. If people can demonstrate that they can do the work, I don't much need to know if "they have a chip on their shoulders". More generally: I have zero faith in anyone's ability to learn much from psychological interviews.
> Once you’ve gotten the overview, dive into each “chapter” and plumb the depths for their real stories. Go back to their childhood!
Oh God. A job interview isn't a therapy session. Why would people ever feel this type of questioning is appropriate for a job interview? How would someone who's dealt with intense trauma during some of those "chapters" respond? Especially given the power imbalance in a job interview, and the pressure you feel to give an answer.
I'd like to believe that I would be willing to politely decline to answer questions like this, thank the interviewer and tell them there just seems to be a mismatch, and walk out of the door. But I don't know if I'd be able to, due to the stress of a job interview.
This reminds me of an interview I have had in the past that made me very uncomfortable.
They asked me the same question and I paused for a moment and replied "excuse me, but this question makes me feel uncomfortable; I'm here for an interview not for a date!".
They realized they overdid it and asked me actual questions.
Eventually decided I was the right candidate for them, but until they decided to reply back, I already had found job elsewhere.
I'm getting red flags from this guide. "Tell me about your best X" is a very low effort question. Being excited about digging through person's life like it's an open book and even excited about them explaining how they cared of their dying parent is perverted at best.
> “Tell me about you. If your life was a book, give me the chapter titles from your birth till now.” Once you’ve gotten the overview, dive into each “chapter” and plumb the depths for their real stories. Go back to their childhood! I learn a lot about their grit and commitment to excellence from their basketball obsession or maybe their experience caring for a dying parent.
God damn that sounds exhausting. How about let's skip to the current chapter, titled I'm Good At Computers And I Want A Job.
This is exactly what I do with my team. I staff the upper levels first with people I trust (people have worked with me for 15 years across 4 different companies now) and then start fleshing out the rest of the teams beneath them with high potential n00bs.
Why? Because that’s what I was when I started and now I’m paying it forward.
It’s been a very successful model and continues to be.
Some of these questions may be borderline illegal. In my experience interviewing folks for Meta we are taught not to ask such questions because of the obvious bias. Even probing into what neighborhood someone lives in is dubious (oh you grew up on the wrong side of the tracks?). I don’t even look at résumés anymore, although recruiters have to screen them. Focus on the job, if you are conducting a coding interview asking coding questions, maybe ask about something they built in the past for fun/work/learning . If you’re doing system design ask them to architect something. If you’re doing behavioral interviews this is trickiest but focus on the on the job behaviors, even if their previous job was not tech or they only have educational experience you can see how someone works with others on a project. Personal questions like this are a really bad idea.
I changed careers at age 40+, learned to code, now years later enjoying it. It just took someone who thought I could grow.
Interestingly I was hired along side some capable, albeit green, college grads. The difference in terms of understanding how a business works, speaking to customers, asking questions / follow through to get down to the problem we're solving was enormous. They could code circles around me, but they also just wanted to be told exactly what to code and had no interest beyond exactly that.
Having worked predominantly in startups, we've almost always been cash-constrained in hiring. Some of the best hires I've found are highly motivated fresh grads or recent grads. I always look for the desire to prove themselves and take charge and full responsibility of a project; a majority of the times, money is secondary to these folks to the ability to make a difference and prove you're capable of completing something difficult. And ultimately, that's always something a startup can offer a young employee. That said, I've often had to teach them foundational things, but the desire to learn and get moving quickly outweighs any cons.
When I've been at big companies, it's all about experience and grey hair, and people become more motivated by money and low risk. I find many times, the quality of the average person at a big company is lower than the average startup fresh grad.
"I find many times, the quality of the average person at a big company is lower than the average startup fresh grad."
I wouldn't blame it on the people but on the environment. I have worked at both big companies and startups. In a lot of big companies it's actually quite hard to make a difference. There are lots of people who can say "No", raise concerns, ask for plans, but not many people who say "Yes". So after a while people learn that it's not worth the effort.
> “Tell me about you. If your life was a book, give me the chapter titles from your birth till now.” Once you’ve gotten the overview, dive into each “chapter” and plumb the depths for their real stories. Go back to their childhood! I learn a lot about their grit and commitment to excellence from their basketball obsession or maybe their experience caring for a dying parent.
I don't think I'd be comfortable sharing this much personal information with a stranger on a job interview.
Additionally, it sounds more like a psychological evaluation, than evaluation of a person's potential at a job. I understand that maybe that's exactly the writer's intention, but I'd personally be wary of companies which ask questions like this.
> Most smart people are actually terrible at having the drive/follow through to take things to completion. They’ll usually want to give up at the first sign of failure or slowness.
You can also hire that really "smart" person from a large co to a startup and watch them be extremely successful in a low-friction environment for crossing the finish line.
> > Most smart people are actually terrible at having the drive/follow through to take things to completion. They’ll usually want to give up at the first sign of failure or slowness.
Also, sometimes these people who don't follow through to take things to completion might "just" have something like ADHD. Struggling with finishing tasks is a very common ADHD symptom, and a good manager will help someone use the other "good" skills to compensate for such an issue. (Personally I believe the reason for this is perfectionism.)
The idea of low friction and similar environments and someone being productive always trigger me a little. In the sense that I think MANY people get a lot of things done in a low friction environment... BECAUSE it is a low friction environment. And once you have a few people who have to deal with the results that come out of nowhere, that other person is the friction for everyone else.
I've worked a lot of places where there's that special someone who gets to cowboy everything because they're "really good" and of course they look really good, because the rules or structure don't apply to them and they can move faster than anyone else by design. It's a never ending cycle.
Meanwhile everyone else or people who come later have to deal with everything the special someone did / didn't think of and so on.
I don't disagree with the premise, but there's consequences and a sort of inescapable feedback loop sometimes too.
What makes you think a startup is a low-friction environment rather than a different kind of high-friction environment where the corporate person could be absolutely miserable and unprepared for execution with resource constraints?
I hate that this is such a common thought process. This is something that makes sense for soldiers in the military. But outside of this context (being a low-information cog in a gigantic machine), it's terrible. If you can't convince domain experts that the plan is sound, then maybe it's a bad plan.
If you trust that the people you are working with are working towards the same goal, disagree and commit is important. You are not going to be right 100% of the time.
If the group is saying X is the right way to go and you’ve already given your reason why you think Y, you should disagree and commit. If you sit there complaining for weeks that they should be doing Y without any new information, you’re just being a shitty teammate and dragging everyone down.
The main point for the commit part is setting aside your ego to move the team forward. Most decisions are two way doors. If X doesn’t work out then try Y but don’t complain, work less hard, or sabotage because you didn’t get your way.
One big exception is if someone is making a decision that goes against company principles or morals.
> I hate that this is such a common thought process.
In most teams, not everyone is on the same page:
- There are people with varying levels of experience, some may not currently have enough background to fully understand all the aspects that a plan addresses.
- Many/most people have the tendency to let their various biases creep into team-level decision-making. For instance, if someone had a bad experience on a previous team using technology X, they are less likely to support using X today independent of X's suitability for the current situation. And people tend to have a massive bias towards their own ideas rather than others' - so when two competing ideas are presented, one's own ideas are often preferred to others' ideas.
- Especially in larger organizations, there may be political motivations for pursuing one plan over another plan - both for management and for workers. "Nobody got fired for buying IBM" and "resume-driven development" and "launches get promo more than landings" are a few examples that come to mind that I've seen.
Unless you're on a golden A-team of contributors who are all incredible and on the same wavelength (this does happen sometimes! if so, cherish it!), you're going to have a mix of people with a mix of motivations+biases+experiences, incapable of reaching consensus around the "true" best plan in a reasonable amount of time.
Making decisions in a reasonable amount of time is CRUCIAL to team performance. Obviously, sometimes you make a bad decision quickly when you might have arrived at a good decision with more deliberation+debate+waiting for consensus. But in my experience, the benefit of avoiding these "bad" decisions from time to time is dramatically outweighed by a team's ability to decide very on things very quickly and commit to a plan (and therefore execute).
Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations.
> If you can't convince domain experts that the plan is sound, then maybe it's a bad plan
The "disagree and commit" scenarios I see in the real world are usually one of the following:
- Disagreements within a team. One "domain expert" disagrees with others about what should be done. The only way forward is to disagree and commit, or remove that person from the team (or company). So disagree and commit is the first choice.
- Disagreements about NIH. Someone wants to build a custom framework or new library instead of using one off the shelf. Building things from scratch is fun, adapting existing things to your need is less so. Given limited resources and time you have to disagree and commit to using something off the shelf.
- Disagreements about priorities. Someone thinks we need to rewrite the codebase or refactor everything or address a low-priority bug instead of working on important feature work for the business. There are cases where too much tech debt is bad, but often it's necessary to focus on what the business needs to keep moving forward. If someone can't disagree and commit to working on what the business needs, that's not going to work out.
Some people simply can't commit to a plan they don't agree with, which means you're either letting them hold everything hostage to their own plan or you're going a different way while they sulk about it. Neither situation is good for planning.
You have a team of smart people. They come up with 3 interesting proposals. You have the bandwidth to execute on only one of them. At some point, a decision has to be made (by you, by vote, whatever).
Two guys on your team are going to hate that decision.
Are you going to be OK with those two not contributing to the end goal (i.e. the "commit" part)? Are you going to be OK with them bringing it up in each team meeting and 1:1 over the next year?
Are you going to be OK with them not voicing their opinions (i.e. the "disagree" part)?
What's your alternative?
As pointed out in a submission a few days ago, the worst experiences tend to be teams that always blindly do what the boss tells them, and at the other end of the spectrum, teams that question every little detail - all the time. Disagree and commit addresses the latter. I've been in that team - it sucks. Never again.
Disagree and commit is like your mom saying she'll forgive but won't forget. sounds good on the surface, but really slightly manipulative and rancorous.
For hiring software engineers, something I read decades ago that has been a consistent indicator for me is Bjarne Stroustrop's observation that good programmers are almost always good writers in their native language.
In my experience, this includes high level writing skills all the way down to sentence structure, but not including the ability to write in a formal or "educated" register. Basically, it shouldn't take a lot of effort to read what they write, on a macro level (what is this about? what are the points being made, and how are they related?) and the micro level (what does this sentence say?)
This doesn't correlate nearly as directly with formal education as you would think. Some people with a degree and an impressive vocabulary write text that looks like a courtroom transcript of their train of thought, and some people with very little formal education write nicely structured text that is easy to read, even if their dialect of English isn't what you'd find in the New Yorker. It's less about formal education than it is about their ability to organize your thoughts and their ability to see their work from another person's perspective, which are important skills for many aspects of programming, including writing the code itself.
The downside of this criterion is that if you don't read someone's native language, you can't judge them by it, so if you're looking at multiple candidates for the same job, it's problematic to give one candidate credit if you can't judge all of the candidates. On the other hand, writing well in the language the company works in is almost always a valuable skill in its own right, so it's rare that you would want to completely disregard a weakness in this area. You just have to be aware that an excellent engineer might struggle a bit in a language that isn't native for them.
Every time I read articles like these I cringe hard and feel sad about how far the youngsters of today have to struggle and bear bullshit just to get a good job and be financially independent.
People just starting out with their careers do not deserve to be subjected to such horribly intrusive and manipulative approaches from recruiters. They are freshers goddammit, you are not supposed to hire them for leadership positions from the get-go. Treat them accordingly and give them space to learn on the job; and if your firm is not capable of doing that yet, go back to hiring based on experience. I have seen way too many large companies of today try to save labor costs by hiring fresh grads and then offloading the responsibilities of C-level leadership onto them so that they don't have to pay large salaries to the experienced candidates instead.
I myself have been a victim of this pathetic practice - a large startup picked me right out of college and then made me lead the ENTIRE sales and customer experience wing of one of their divisions. With zero prior experience, zero training, just handed the reins from the get-go. This role involved hiring, training, deploying and managing literally a hundred sales executives (all of which had more ground experience than I ever did), chasing insane sales and customer acquisition targets, handling customer analytics for thousands of customers across diverse categories and segments _and_ planning and implementing outreach campaigns while desperately trying to learn the ropes at the same time. The job that I was handling was meant not just for someone more experienced, but for an _entire team_ of analysts, domain experts and mid-level managers. After a year of pushing myself and working literally 90 hours a week I gave up. This startup closed down that division the moment I left and lost ~60% of its overall valuation. From what I hear they have now fired everyone and are just looking for an exit chance. The whole thing was a F-ing nightmare that has scarred me from ever attempting to engage with startups in the future. I have joined a conventional consulting firm as an Associate currently and it's unbelievable how rudimentary things like employee training and mature, robust organization is making me feel.
To any recruiters reading this, please stop going after low-experience candidates if your organization is not specifically mature and equipped enough to holistically train them.
I never thought I'd say this, but... I'd rather grind Leetcode instead of being psychoanalyzed by a "Hip hop enthusiast masquerading as a San Francisco technologist".
Tip #1: You're never even going to get an application from these people if your job posting requires 7+ years with AI+Erlang+Azure.
If your codebase is C#, would you hire somebody with some Java and Swift, but no C#? If the answer is no, then feel free to scare people away who are not C# experts. But if the answer is yes, reword your job posting. Sure, be clear that you have a C# codebase, but be welcoming to other skill sets.
Just because you host your stuff on GCP doesn't mean that all applicants have to have experience on GCP. Unless it does. If you are trying to hire somebody who can jump in and solve a specific problem on day 1, then ok. But if you are hiring for potential, your new hire will be an expert in GCP two months after you hire them. You have a four month hiring process anyway. What's two more months?
The succinct guidelines from "Mastering the Art of War" (Zhuge Liang, Liu Ju) for interviewing people are still among the best (c.200 / 1300 CE). This is also good practive for the interviewee, you want to assess whether or not accepting a job offer at Theranos is a good idea (#5 is perhaps questionable):
Hard though it be to know people, there are ways.
First is to question them concerning right and wrong, to observe their ideas.
Second is to exhaust all their arguments, to see how they change.
Third is to consult with them about strategy, to see how perceptive they are.
Fourth is to announce that there is trouble, to see how brave they are.
Fifth is to get them drunk, to observe their nature.
Sixth is to present them with the prospect of gain, to see how modest they are.
Seventh is to give them a task to do within a specific time, to see how
trustworthy they are.
Everytime I read one of these "how to hire" posts, it's always a opinionated clusterfuck of a process that is arbitrary/capricious, gameable and biased towards what OP thinks are good traits.
This is a problem that is very easy to solve if you were allowed to use proxies for intelligence and grit. Just test for IQ and trait conscientiousness. [1]
But in terms of how to assess them, a lot of the advice here boils down to "you'll know it when you see it."
So I think this advice is best for seasoned hiring managers. If you're just starting out, it's going to be hard to accurately detect some of the nuance and subjective elements.
[+] [-] smeeth|2 years ago|reply
- Are they smart? (understands quickly + communicates effectively)
- Are they cool? (won't put poison in the keurig + pleasant to be around)
- Are they high energy? (initiative + action bias)
- Do they have the experience needed to be successful in the role?
Those are pretty strong priors for success. If you find someone with all the above, you've got an ~80% chance of a hit. No need to over-complicate.
In my experience, adding more boxes tends to index towards box-checkers who grew up wealthy. That's how you miss the hyper-smart/diligent state school kids who happened to spend their summers working instead of doing model UN.
[+] [-] CharlieDigital|2 years ago|reply
- Y-axis is "drive"
- X-axis is "aptitude"
- low drive + low aptitude: never hire
- low drive + high aptitude: hire for targeted use cases where you need expertise
- high drive + low aptitude: hire, train, and foster aptitude growth
- high drive + high aptitude: hire on the spot
There's an indirect way of testing for this which is to test for curiosity and lack of ego. My experience has been that candidates with high curiosity tend to have low ego (they know what they don't know and are curious to learn). These candidates make great hires because you can teach them anything.
Wrote about this a little bit here (with a handy diagram): https://charliedigital.com/2020/01/15/effective-hiring-for-s...
[+] [-] CobrastanJorji|2 years ago|reply
[+] [-] bigbillheck|2 years ago|reply
People's intuitions around hiring are extremely Bayesian, which is why we have all sorts of laws and regulations and HR departments that try to counteract various prejudicial priors.
[+] [-] s0rce|2 years ago|reply
[+] [-] Shocka1|2 years ago|reply
[+] [-] babyshake|2 years ago|reply
[+] [-] mixermachine|2 years ago|reply
It is a super cool story to hear in what jobs somebody already has worked in and a good indicator. I worked as a dancing instructor assistant and learned so much about people. This job does not correlate with my current job as a Java/Kotlin/Android dev but was taken quite well by everyone the interviewed me 10 years back.
You just have very little time during a job interview and mistakes are costly.
> Are they smart? > Are they cool? ... Are the right questions that need to be answered, but not asked directly. The article talks especially about what to ask to get meaningful answers.
[+] [-] j7ake|2 years ago|reply
A prior would tell you how much each of those attributes would change your viewpoint.
Having very strong priors actually means your decision won’t change unless you have very strong evidence on the contrary.
[+] [-] randomdata|2 years ago|reply
Yeah, but that's the point. Those who come from wealth bring connections. Connections are what make or break a business. A mediocre worker with rich parents is far more beneficial to the business than a standout worker that came from the slums.
[+] [-] tptacek|2 years ago|reply
I'm a little grumpy about this "diamonds in the rough" shit. I'm more concerned about what's lurking in the diamond mines. If people can demonstrate that they can do the work, I don't much need to know if "they have a chip on their shoulders". More generally: I have zero faith in anyone's ability to learn much from psychological interviews.
[+] [-] noamchomsky1|2 years ago|reply
Utterly ridiculous.
[+] [-] Trasmatta|2 years ago|reply
Oh God. A job interview isn't a therapy session. Why would people ever feel this type of questioning is appropriate for a job interview? How would someone who's dealt with intense trauma during some of those "chapters" respond? Especially given the power imbalance in a job interview, and the pressure you feel to give an answer.
I'd like to believe that I would be willing to politely decline to answer questions like this, thank the interviewer and tell them there just seems to be a mismatch, and walk out of the door. But I don't know if I'd be able to, due to the stress of a job interview.
[+] [-] stefanos82|2 years ago|reply
They asked me the same question and I paused for a moment and replied "excuse me, but this question makes me feel uncomfortable; I'm here for an interview not for a date!".
They realized they overdid it and asked me actual questions.
Eventually decided I was the right candidate for them, but until they decided to reply back, I already had found job elsewhere.
Why do they ask such type of questions anyway?!
[+] [-] reportgunner|2 years ago|reply
[+] [-] SketchySeaBeast|2 years ago|reply
[+] [-] trgn|2 years ago|reply
[+] [-] karaterobot|2 years ago|reply
God damn that sounds exhausting. How about let's skip to the current chapter, titled I'm Good At Computers And I Want A Job.
[+] [-] varjag|2 years ago|reply
[+] [-] garciasn|2 years ago|reply
Why? Because that’s what I was when I started and now I’m paying it forward.
It’s been a very successful model and continues to be.
[+] [-] dojorno|2 years ago|reply
[+] [-] dkasper|2 years ago|reply
[+] [-] duxup|2 years ago|reply
I changed careers at age 40+, learned to code, now years later enjoying it. It just took someone who thought I could grow.
Interestingly I was hired along side some capable, albeit green, college grads. The difference in terms of understanding how a business works, speaking to customers, asking questions / follow through to get down to the problem we're solving was enormous. They could code circles around me, but they also just wanted to be told exactly what to code and had no interest beyond exactly that.
[+] [-] griffinkelly|2 years ago|reply
When I've been at big companies, it's all about experience and grey hair, and people become more motivated by money and low risk. I find many times, the quality of the average person at a big company is lower than the average startup fresh grad.
[+] [-] rqtwteye|2 years ago|reply
I wouldn't blame it on the people but on the environment. I have worked at both big companies and startups. In a lot of big companies it's actually quite hard to make a difference. There are lots of people who can say "No", raise concerns, ask for plans, but not many people who say "Yes". So after a while people learn that it's not worth the effort.
[+] [-] bheadmaster|2 years ago|reply
I don't think I'd be comfortable sharing this much personal information with a stranger on a job interview.
Additionally, it sounds more like a psychological evaluation, than evaluation of a person's potential at a job. I understand that maybe that's exactly the writer's intention, but I'd personally be wary of companies which ask questions like this.
[+] [-] poorman|2 years ago|reply
You can also hire that really "smart" person from a large co to a startup and watch them be extremely successful in a low-friction environment for crossing the finish line.
[+] [-] user_7832|2 years ago|reply
Also, sometimes these people who don't follow through to take things to completion might "just" have something like ADHD. Struggling with finishing tasks is a very common ADHD symptom, and a good manager will help someone use the other "good" skills to compensate for such an issue. (Personally I believe the reason for this is perfectionism.)
[+] [-] duxup|2 years ago|reply
I've worked a lot of places where there's that special someone who gets to cowboy everything because they're "really good" and of course they look really good, because the rules or structure don't apply to them and they can move faster than anyone else by design. It's a never ending cycle.
Meanwhile everyone else or people who come later have to deal with everything the special someone did / didn't think of and so on.
I don't disagree with the premise, but there's consequences and a sort of inescapable feedback loop sometimes too.
[+] [-] rabi_molar|2 years ago|reply
[+] [-] nradov|2 years ago|reply
[+] [-] mywittyname|2 years ago|reply
I hate that this is such a common thought process. This is something that makes sense for soldiers in the military. But outside of this context (being a low-information cog in a gigantic machine), it's terrible. If you can't convince domain experts that the plan is sound, then maybe it's a bad plan.
Honestly, disagree and commit goes against my...
> Theory for excellence.
[+] [-] skellera|2 years ago|reply
If the group is saying X is the right way to go and you’ve already given your reason why you think Y, you should disagree and commit. If you sit there complaining for weeks that they should be doing Y without any new information, you’re just being a shitty teammate and dragging everyone down.
The main point for the commit part is setting aside your ego to move the team forward. Most decisions are two way doors. If X doesn’t work out then try Y but don’t complain, work less hard, or sabotage because you didn’t get your way.
One big exception is if someone is making a decision that goes against company principles or morals.
[+] [-] beisner|2 years ago|reply
In most teams, not everyone is on the same page:
- There are people with varying levels of experience, some may not currently have enough background to fully understand all the aspects that a plan addresses.
- Many/most people have the tendency to let their various biases creep into team-level decision-making. For instance, if someone had a bad experience on a previous team using technology X, they are less likely to support using X today independent of X's suitability for the current situation. And people tend to have a massive bias towards their own ideas rather than others' - so when two competing ideas are presented, one's own ideas are often preferred to others' ideas.
- Especially in larger organizations, there may be political motivations for pursuing one plan over another plan - both for management and for workers. "Nobody got fired for buying IBM" and "resume-driven development" and "launches get promo more than landings" are a few examples that come to mind that I've seen.
Unless you're on a golden A-team of contributors who are all incredible and on the same wavelength (this does happen sometimes! if so, cherish it!), you're going to have a mix of people with a mix of motivations+biases+experiences, incapable of reaching consensus around the "true" best plan in a reasonable amount of time.
Making decisions in a reasonable amount of time is CRUCIAL to team performance. Obviously, sometimes you make a bad decision quickly when you might have arrived at a good decision with more deliberation+debate+waiting for consensus. But in my experience, the benefit of avoiding these "bad" decisions from time to time is dramatically outweighed by a team's ability to decide very on things very quickly and commit to a plan (and therefore execute).
Famously, section 5.11 of the CIA's Simple Sabotage Field Manual [1] describes some pretty timeless ways to ruin an organization's productivity - all kinds of behavior that are kind of indistinguishable from the behavior I've seen arise from "disagreeing and not committing" in organizations.
[1] https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...
[+] [-] Aurornis|2 years ago|reply
The "disagree and commit" scenarios I see in the real world are usually one of the following:
- Disagreements within a team. One "domain expert" disagrees with others about what should be done. The only way forward is to disagree and commit, or remove that person from the team (or company). So disagree and commit is the first choice.
- Disagreements about NIH. Someone wants to build a custom framework or new library instead of using one off the shelf. Building things from scratch is fun, adapting existing things to your need is less so. Given limited resources and time you have to disagree and commit to using something off the shelf.
- Disagreements about priorities. Someone thinks we need to rewrite the codebase or refactor everything or address a low-priority bug instead of working on important feature work for the business. There are cases where too much tech debt is bad, but often it's necessary to focus on what the business needs to keep moving forward. If someone can't disagree and commit to working on what the business needs, that's not going to work out.
Some people simply can't commit to a plan they don't agree with, which means you're either letting them hold everything hostage to their own plan or you're going a different way while they sulk about it. Neither situation is good for planning.
[+] [-] BeetleB|2 years ago|reply
You have a team of smart people. They come up with 3 interesting proposals. You have the bandwidth to execute on only one of them. At some point, a decision has to be made (by you, by vote, whatever).
Two guys on your team are going to hate that decision.
Are you going to be OK with those two not contributing to the end goal (i.e. the "commit" part)? Are you going to be OK with them bringing it up in each team meeting and 1:1 over the next year?
Are you going to be OK with them not voicing their opinions (i.e. the "disagree" part)?
What's your alternative?
As pointed out in a submission a few days ago, the worst experiences tend to be teams that always blindly do what the boss tells them, and at the other end of the spectrum, teams that question every little detail - all the time. Disagree and commit addresses the latter. I've been in that team - it sucks. Never again.
[+] [-] trgn|2 years ago|reply
Disagree and commit is like your mom saying she'll forgive but won't forget. sounds good on the surface, but really slightly manipulative and rancorous.
[+] [-] dkarl|2 years ago|reply
In my experience, this includes high level writing skills all the way down to sentence structure, but not including the ability to write in a formal or "educated" register. Basically, it shouldn't take a lot of effort to read what they write, on a macro level (what is this about? what are the points being made, and how are they related?) and the micro level (what does this sentence say?)
This doesn't correlate nearly as directly with formal education as you would think. Some people with a degree and an impressive vocabulary write text that looks like a courtroom transcript of their train of thought, and some people with very little formal education write nicely structured text that is easy to read, even if their dialect of English isn't what you'd find in the New Yorker. It's less about formal education than it is about their ability to organize your thoughts and their ability to see their work from another person's perspective, which are important skills for many aspects of programming, including writing the code itself.
The downside of this criterion is that if you don't read someone's native language, you can't judge them by it, so if you're looking at multiple candidates for the same job, it's problematic to give one candidate credit if you can't judge all of the candidates. On the other hand, writing well in the language the company works in is almost always a valuable skill in its own right, so it's rare that you would want to completely disregard a weakness in this area. You just have to be aware that an excellent engineer might struggle a bit in a language that isn't native for them.
[+] [-] rahimnathwani|2 years ago|reply
This doesn't just apply to software engineers!
[+] [-] dartharva|2 years ago|reply
People just starting out with their careers do not deserve to be subjected to such horribly intrusive and manipulative approaches from recruiters. They are freshers goddammit, you are not supposed to hire them for leadership positions from the get-go. Treat them accordingly and give them space to learn on the job; and if your firm is not capable of doing that yet, go back to hiring based on experience. I have seen way too many large companies of today try to save labor costs by hiring fresh grads and then offloading the responsibilities of C-level leadership onto them so that they don't have to pay large salaries to the experienced candidates instead.
I myself have been a victim of this pathetic practice - a large startup picked me right out of college and then made me lead the ENTIRE sales and customer experience wing of one of their divisions. With zero prior experience, zero training, just handed the reins from the get-go. This role involved hiring, training, deploying and managing literally a hundred sales executives (all of which had more ground experience than I ever did), chasing insane sales and customer acquisition targets, handling customer analytics for thousands of customers across diverse categories and segments _and_ planning and implementing outreach campaigns while desperately trying to learn the ropes at the same time. The job that I was handling was meant not just for someone more experienced, but for an _entire team_ of analysts, domain experts and mid-level managers. After a year of pushing myself and working literally 90 hours a week I gave up. This startup closed down that division the moment I left and lost ~60% of its overall valuation. From what I hear they have now fired everyone and are just looking for an exit chance. The whole thing was a F-ing nightmare that has scarred me from ever attempting to engage with startups in the future. I have joined a conventional consulting firm as an Associate currently and it's unbelievable how rudimentary things like employee training and mature, robust organization is making me feel.
To any recruiters reading this, please stop going after low-experience candidates if your organization is not specifically mature and equipped enough to holistically train them.
[+] [-] elevatedastalt|2 years ago|reply
[+] [-] tinycombinator|2 years ago|reply
[+] [-] thih9|2 years ago|reply
Note that this approach, when not supplemented by other questions, favors outlier great results over consistent good results. E.g.:
Distribution A: 3, 2, 3, 2, 2, 1, 100, 2, 1, 3; MAX(A) = 100
Distribution B: 72, 73, 78, 79, 44, 75, 78, 79, 78, 79; MAX(B) = 79
[+] [-] SilverBirch|2 years ago|reply
[+] [-] freeopinion|2 years ago|reply
If your codebase is C#, would you hire somebody with some Java and Swift, but no C#? If the answer is no, then feel free to scare people away who are not C# experts. But if the answer is yes, reword your job posting. Sure, be clear that you have a C# codebase, but be welcoming to other skill sets.
Just because you host your stuff on GCP doesn't mean that all applicants have to have experience on GCP. Unless it does. If you are trying to hire somebody who can jump in and solve a specific problem on day 1, then ok. But if you are hiring for potential, your new hire will be an expert in GCP two months after you hire them. You have a four month hiring process anyway. What's two more months?
[+] [-] photochemsyn|2 years ago|reply
Hard though it be to know people, there are ways.
First is to question them concerning right and wrong, to observe their ideas.
Second is to exhaust all their arguments, to see how they change.
Third is to consult with them about strategy, to see how perceptive they are.
Fourth is to announce that there is trouble, to see how brave they are.
Fifth is to get them drunk, to observe their nature.
Sixth is to present them with the prospect of gain, to see how modest they are.
Seventh is to give them a task to do within a specific time, to see how trustworthy they are.
[+] [-] fardinahsan|2 years ago|reply
This is a problem that is very easy to solve if you were allowed to use proxies for intelligence and grit. Just test for IQ and trait conscientiousness. [1]
----
[1] IQ is a stronger prediction of on the job performance than anything else. https://www.steveloh.org/news/2020/5/27/best-predictor-of-jo...
[+] [-] freetanga|2 years ago|reply
More like /r/LinkedinLunatics than HackerNews material.
[+] [-] jawns|2 years ago|reply
But in terms of how to assess them, a lot of the advice here boils down to "you'll know it when you see it."
So I think this advice is best for seasoned hiring managers. If you're just starting out, it's going to be hard to accurately detect some of the nuance and subjective elements.