I have always focused on hiring for attitude and aptitude. If you have the attitude to learn, and the aptitude to grown your skills, then you'll do great at anything you're passionate about.
I literally hired a guy who was a part-time computer hobbyist but, a full time pool man. I told him "hey how would you like to spend 40 hours a week learning more about computers." Today he's working as a leader in his company's security group. He often thanks me for the job, and I always remind him "you did the work, all I did was give you the opportunity".
Sadly as stated in the thread linked, its hard when you have 10k applicants, to treat each as a potentially amazing member of the your team. I still try hard to look for that attitude and aptitude, and if a candidate demonstrates this in our dialog, I will do my best to find a path for them to connect with other opportunities if they're not a strong match for roles I'm filling on my teams.
What I know is we're born to this world knowing how to eat, breathe, cry, and a couple other things. The rest, all of it, we've learned on our way to this day. Just because the person in front of me didn't have the same path as me, doesn't mean they won't learn to have an incredible impact going forward. Searching for this potential and type of partnership at scale is hard. My heart wants to say it can be solved, but my calendar is an evil overlord that only allows me only so many hours a day to invest in growing my teams...
This is pretty much where I am at now. Attitude, open-mindedness and general ability to endure pain are what I look for.
I can teach 100% of the tech stack to a total noob in a matter of weeks. Trial by example is my lesson of choice these days. The good apprentice will absorb these like a dry sponge to water.
It also really helps that our tech stack is simple and fits on 1 computer. It is not bullshit abstraction either - You install 3 things on a fresh Win10 box to promote it to "Official Developer Machine" status. None of these things happens to be Docker or any other containerization tech, so even junior developers are expected to understand how the product runs on the bare metal/vm. Spoiler: It's 1 process & 1 service so they learn it fast.
Basically what I am trying to say is that your ability to consume non-PhD candidates is partially predicated upon how you've decided to run your tech business. If you (ab)use enterprise arch like message buses, event sourcing, et. al., you are going to find that it requires additional mountain ranges worth of background knowledge to understand how these things fit together. If your tech stack can be considered within the context of a single process, the margin of understanding becomes much more practical to work with in my experience.
Honestly, I almost prefer to start with a blank slate these days. Don't know how a computer works? Fucking fantastic! I can probably still get you productive in my simple C#/SQLite tech stack faster than if I had to de-program some web-scale zealot for the same purpose.
This is a fantastic comment, and it matches exactly the attitude that Anthony Bourdain wrote about in his book Kitchen Confidential, which I read in eighth grade and have thought about weekly ever since.
CTRL+F for "WHO COOKS" and read the whole section to see a professional chef say exactly the same thing you said about programming.
> Honestly, I almost prefer to start with a blank slate these days
This is about Technical Support training (not programming) and is from my recent experience.
When I was running a small customer service team on a Linux based product, and needed new staff, I thought that the best idea was to get people who had 'significant' experience in Linux.
That was until I discovered (from a bad hire) that people lied about their experience (resumes) and motivation (interview).
This was an older guy - he wasn't motivated at all and treated me like a babysitter..
It wasn't about his age - he was just useless - and he had managed to fool me.
That hire was my fault..
And although I utterly hate ageism (being 50+), I was turned off by this experience..
The next two I hired were younger guys (sorry ladies, no resumes submitted).
Those two (somehow??) took to my particular style of training really well - and were able to take over all but the most advanced cases after 3-6 months of training on a bespoke php application.
- one loved all the SQL I could throw at him
- another loved getting deep into networking issues and how to solve them
Between us we were able to work through a ~200+ case backlog down to 0 by the time I left the company.
I am very proud of what these two guys put into their work (bash/shell/vi remote primary tools - all mostly alien to them to start with).
Not sure that I could do the same with training a programming role..
It reminds me of a place I worked years ago that had their own unique and I would say simple tech and they did hire from the street. What was standing between you and that job was a rigorous two week U program. Daily classes taught a small group of prospects the ropes and at the end a small number of obvious people were hired. It was always pretty obvious. Some of the people hired were homemakers, blue collar workers, even a Cobol programmer.
> Trial by example is my lesson of choice these days.
That's an easy way to develop lessons, but seems like it would lead to a lot of cargo cult mechanisms. Especially once those people started teaching.
> your ability to consume non-PhD candidates is partially predicated upon how you've decided to run your tech business
I've found a PhD (without work experience) is a bad sign.
>. If you (ab)use enterprise arch like message buses, event sourcing, et. al., you are going to find that it requires additional mountain ranges worth of background knowledge to understand how these things fit together
I know I've hit the point several times where what I consider trivial is complex, but are message buses and events really that difficult? (And isn't event sourcing just one of the standard ways events are used?) Aren't buses covered in programming 101?
I took multiple CS classes at a top university* and I never heard about message buses or events...
Admittedly I was not a CS major and don't work in software engineering.
(To be honest, it being a top university probably decreased the probability that they would teach me practical/useful engineering practices like this. The programming classes I took were fairly focused on more theoretical concerns)
It looks more like the hiring process for McDonalds...
You probably didn't mean it like that but "attitude, open-mindedness and general ability to endure pain" is the qualities that I would want a slave to have. There is no experience, inventiveness, leadership, autonomy, knowledge, logical thinking, initiative, problem solving, etc... here, even though there are qualities that matter to engineers. There are only qualities that matter when it comes to executing orders. I doesn't mean that they are undesirable, it is important to have people who stay enthusiastic even when they don't do as they please, but it is not all there is to a skilled job.
You want someone who learns by example, and from a blank slate. Yep, that's how you get a good burger flipper. But for a developer to quickly learn by example in all but the most simple projects, he needs a solid background. A programmer who knows 10 programming languages will pick up the 11th in no time at all, literally. One who knows zero will need more than a few weeks of looking at you to code competently.
You seem to be in a rare situation where you need a low-skilled developer. Most projects require either high skills or no one at all (automation).
Note that many people think they don't need skilled developers, until they realize the mess people have done. It is a common problem with off-shoring to countries with low labor cost, like India. People think they are going to save a lot of money until they realize that it is cheap for a reason. You can get quality work done in India if you pay the price, but too many people go there to not pay the price.
As for "web-scale zealots", you probably mean people who are on top of "mount stupid" in the Dunning-Kruger curve. Yep, they are the worst and you'd rather have a "blank slate". But if you think about it, since we all have that bias to some extent, the fresh people you have are walking towards mount stupid and will become worse, if you hire them when they are overconfident, they are passing it and becoming better.
Not trying to be snide to OP, but his/her anecdote does hit the typical Linkedin influencer plot beats which I find amusing:
I literally hired a guy who was a part-time computer hobbyist but, a full time pool man.
I told him "hey how would you like to spend 40 hours a week learning more about computers."
Today he's working as a leader in his company's security group.
He often thanks me for the job, and I always remind him "you did the work, all I did was give you the opportunity".
LinkedIn is full of completely farcical stories about recruiters who had the prescience to hire someone even though they were 30 seconds late for an interview or didn't wear a tie or hadn't graduated from an Ivy League school or some other such nonsense. And because of this HR drone's largesse, this person later did their job satisfactorily.
I honestly can't tell if the GP meant it in a snide way (like my example above) or as an honest compliment. It could be either, really.
What the person means here is that on Linkedin there are a lot of (usually staged) comments or videos of people that "saved the life of that person that had $X and nobody employed and (s)he is now the best $Y". These posts are highly shared and commented upon. I don't think the comment was mocking you really, it was just a funny parallel (hope I'm not wrong).
What's hard is to interview for attitude and aptitude, and scaling that so other people know how to interview for those traits. Would you mind sharing some insight on what type of interview, green flags, things you are looking for, or process? Hopefully it's not only gut feeling :)
Focus on asking the candidate "why", and you're 50% there. Why did you choose X, why would you pick Y, why is Z better, why is W more expensive, why did K happen... The "what" are just conversation starters (unless severely incorrect or misguided, of course).
> What I know is we're born to this world knowing how to eat, breathe, cry, and a couple other things
Something I found interesting about having kids was the realisation that even some of those things had to be learnt to some extent. Babies have natural drives that lead them to feed, but they often still have trouble in the early days with breast feeding. Even the first breath doesn't always happen as automatically as you might think.
In my decades experience hiring, there are only three archetypes you want to avoid:
- Someone who has no clue. This is rare but it does happen. I have seen some fly through interviews and then literally do nothing until they leave for another company as we are set to fire them.
- Assholes. Everyone is nice in the interviews. Not everyone is nice during code review. There is a sub-archetype of asshole called The Complainer. They can live in pairs, but if there is no Assholes, a true Complainer will find a way to turn someone into one. They are two sides of the same coin.
- My way or the highway types. Your team uses Design Patterns and Unit Testing. Bob says that is overengineering and refuses to be a team player.
Interviews focus on the first one, which is honestly simple for a relatively experienced interviewer to weed out. I don't believe in 10X rockstar ninja programmers. Either someone has the ability or they don't.
The real keys to great hiring are good managers and cheap firing. Good managers are hard to come by, but they can be built fairly easily. Cheap firing is usually easy, if that is your goal. Some locales restrict this legally, but there is always a loophole.
Firing is dangerous, it can demoralize the team extremely quickly. My rough rule of thumb is that for anybody who was even marginally liked who gets fired, expect one of your best people to leave.
On the other hand, if there is someone who people don't like, who visibly avoids work, and the rest of the team resents them, then firing is actually a really positive thing.
> Firing is dangerous, it can demoralize the team extremely quickly.
Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work. I don't mean junior folks who get it but are building experience. A company I worked for hired a junior against the advice of the team (red flag anyone?). We spent 6-8 months with this individual spinning their wheels. They just did not get it. It created more work for the rest of the team to help them, redo the work correctly, etc. Did they fire him? Nope...they transferred him to another group within the company. And of course he's not doing well in that group either. Why should people work their butts off if it seemingly makes no difference?
I've since left that company - this wasn't the primary driver, there were lots of other supporting reasons, but ultimately it came down to my loss of faith in management's ability to steer us in the right direction.
> Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work.
I think this is only true in the most egregious of cases. A somewhat counter-intuitive thing I've learned is that highly productive programmers like working with less productive programmers. They've spent a lot of time with this person, maybe got to like them on a personal level. But beyond that, they don't have to butt heads all the time, it's one more person to stamp your diff without excessive nitpicking, someone to bounce ideas off of, someone to handle the more mundane coding work, someone to share blame with. Almost like an assistant programmer. A backfill will have to trained and knowledge-transferred again from zero.
This isn't to say the organization is best served by keeping low-performers around at full salary to keep their high performers happy. That depends on higher level organizational goals. My point is to support GP's quoted statement in your post, that firing is dangerous and can demoralize teams.
The obviously clueless are rarely controversial fires. The problem is when leadership have a different opinion of the employee than workers.
I'm on my notice right now. I started hunting a new job after the company fired their recently hired well-liked VP Product. Most of the organisation believed this guy had made a substantial positive impact, and the firing reasons were concocted. They weren't entirely unjustified (he was too expensive, and focus wasn't aligned), but I still disagreed. I've heard both sides independently, and nowhere near enough effort was made to find a better way.
When people see good people fired for weak reasons, they become concerned for their own role. As a senior engineer, this is particularly worrisome. A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. If I see people getting fired like this, then my career becomes a factor in my decision making.
Ultimately, this firing has cost a small engineering team both it's senior engineers. I'm gone, so is the other senior (for the same reason). The CTO is management focused. There are a few other reasons I won't go into, but this team is in a very difficult position.
“Weak reasons” obviously heavily dependent on priorities at the time, which can change quickly. On small companies it has a massive impact on others and that shouldn’t be taken lightly.
I had a previous boss that hired someone senior to do X but their expectations of the role quickly changed and they were fired for not performing well enough. They jumped from a good job stable job and took a risk, asking all the right questions about the role but CEO/CTO never lived up to their side of what the role ended up being.
This same CEO also admitted to me part of their management style was “push people to breaking point, and back off a little” to get the most out of people. I left soon after.
I don’t know how to avoid working with this kind of leadership personality in the interview process but has definitely made me more cautious.
> A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases.
This paragraph should be a great frame for so many problems. Engineers are people whose identities are wrapped in the perception of their intelligence. But value is created when we disagree and "the right" person wins.
Any non net-negative developer being fired risks demoralizing the team. If they are net 0.1% as productive as a typical developer, but not preventing anybody else from getting their work done, they are a cost to the company, but not to the remainder of the team.
Agreed. This individual was a net negative. They could not get their work done, and thus required other engineers to pick up their "slack". Everyone pitched in to help mentor the individual, without much success. Compared to other similarly skilled/experienced developers we'd hired around the same time - who became productive in a few months, this person made zero progress.
Not firing this person was demoralizing to the team. Moving them off the team to another group seemed to upset people even more than keeping this person around (I'd moved on by this time, but kept in touch with the team). Rather than doing the right thing for the organization (firing them) - management decided to make it someone else's problem in the organization. Yes from management's perspective they 'solved' the team's problem but the optics of what they did created resentment towards management.
They are a cost to other developers as well. If one person is not able to (or choose not to) handle the tasks he is assigned to then he is a burden on others. Not to mention others' tasks can have dependency to that person's.
In my experience (I think I had two people that intentionally slacks around and wants to get fired) the companies often put such persons on low prio tasks that barely matter. And be a bit more pessimistic with their estimates
As a hiring manager, the hardest people to fire are the ones that try hard, always show up on time but still end up doing terrible work. The best way I’ve found to do this is 9 box them, unfortunately point out how they’re holding back the team to the other people on the team (ie talk shit) and then formal review followed by firing.
> point out how they’re holding back the team to the other people on the team (ie talk shit)
It is terrifying to think that you are in any kind of leadership position. I instantly lose respect for anyone who "talks shit" about team members, especially leaders. If I found out anyone was talking shit, especially someone in a leadership position in my company I would fire them on the spot. Well, I would first ask to speak privately so that they could still have the dignity they were denying their former team.
There are no bad teams, there are only bad leaders.
There are team members that are beloved for characteristics besides what they’ve been hired for. It’s explicitly why I pointed out it’s a hard decision to make but ultimately the right one. Pointing out how they are bringing down the team is not easy but necessary and part of what makes the job hard. This is after several quarters of speaking with privately and many attempts at coaching and external training with no change, which is how we get to the 9 box rating in the first place.
I have a guy in my team who hasn't produced anything meaningful. 3 months ago I told my manager and the product owner that I can not include him into our sprint plans since he can not deliver anything. He still shows up in the scrums and tells us he is "working on errors". No one has any clue what he is supposedly doing. We wish our manager would just fire him.
Currently our suspicion is that he is related to some higher up.
Oddly at many large organizations it's not the dead weight that's getting fired. In fact, the dead weights are usually the safest. Anyone that's managed to be dead weight at a Fortune 500 company for more than a couple years is very good at it. Think of Wally from Dilbert.
There's a 4th type, the competent but lazy engineer. They do great in the interview, then it's rest and vest time. They thrive in remote positions where they spend most of their time at the doctor, dentist, and vet.
The most influential essay I've ever read on hiring was titled I Don't Hire Unlucky People[1]. At the time, I was struggling to build a mobile dev team, and I could always find reasons to not hire anyone in the pipeline. However, there came a point where I had to apply the secretary problem [2] to my situation and realize it was costing me more to not have these positions filled. To that end, my only hard requirement became whether I left the interview with them feeling like this was someone I could manage and grow.
The irony is that once I embraced this, I ended up with a pretty diverse team almost as a side effect. It made me realize that most "unspoken disqualifications" are usually anti-diversity in practice, though I don't think that's done consciously.
That's essentially the point of that essay. That, and most of those boxes you want ticked are artificial means of whittling down candidates and not hard criteria for whether someone can do a job.
I prefer working with, and hiring, the sort of people that FAANGs would never look at: diverse and weird education or experience be backgrounds, grossly unrelated hobbies, and pressing personal responsibilities like a band, family, or sport.
Some of the best programmers I've worked with were ex high school teachers, military, set designers, nurses and such.
I _want to believe_ that folks like this trend towards flexibility and teamwork. That they're at work for the purpose of earning, and work with the goal of delivering. They'll collaborate when possible, and cut features when necessary.
Yea I've worked with some great programmers who would never pass an interview at FAANG, but whose work at various startups surpasses the work they and others do at those big tech companies. I love working with people like that!
That’s what worked for me (as an employee). I’m a high school dropout, with a GED, and some tech school training (from a now-defunct certificate mill). Not exactly a Stanford Ph.D.
When that’s your pedigree, no one gives you a break, so you have to make your own, and prove yourself at every step. Sort of “A Boy Named Sue” thing. It either makes you, or breaks you.
Kept me humble, hungry, and a team player. Yeah, I got taken advantage of, but I also found that people would give me incredible opportunity, as I was a lot cheaper than an architect. My very first engineering project was complete hardware and firmware design of a microwave switching device[0]. Almost no one gets that kind of opportunity. Most folks have to wait years before being trusted with much lower levels of responsibility (I had almost no supervision or guidance, during the project).
Did I mention that this was my very first engineering project, ever? The only reason I got it, was because I was given the rather humble task of assembling an ATE system, and I was getting tired of constantly stopping the test to rewire the units. My boss got sick of me bitching, and said “Why don’t you do something about it?”
So I did. Since he told me to do it, he couldn’t very well prevent me from following through.
That’s been the story of my life. People toss me difficult problems, to shut me up, and I solve them.
This has not always won me friends. I’ve learned that, quite often, people don’t actually want their problems solved, and get quite upset, when you solve them; even when they asked you to.
In the aggregate, it has worked out well. I’ve retired, ten years early (not by choice -thanks, ageism!).
> Hiring is an obvious example, with "requirements" that filter out large chunks of applicants that don't have some kind of back channel
In my experience, it is very tempting to filter for the most qualified candidates, and that should happen. However, there should also be a filter for the most dedicated candidates, as that can also lead to very good outcomes. Many of the best employees don't look that great on paper, but love their jobs, and are very motivated to excel. The same is not always true, at all, for "qualified" people.
My old company used to hire broke, desperate, and underachieving college students out of the local university for that exact reason - desperate people are often the most dedicated people.
The scheme worked something like how the New England Patriots run things: keep a solid core of veterans well-paid and happy, then use them to train the hell out of new hires. Later, make sure those new hires get excellent jobs elsewhere in 4-6 years and repeat the cycle, ensuring that you never have to pay for premium talent since you can develop it at budget cost in-house.
When I say "train the hell out of", I mean each new dev had a senior dev dedicated to just them who would criticize everything about their code and workmanship like a Mr. Miyagi. Every email that dev sent also got CC'd to that senior dev and the senior dev always knew what they were working on, how long such a thing should take them, and knew what questions/difficulties were likely to come up and when during the process of that item. Good mentorship cannot be substituted for during the training process.
The system fell apart once management got flipped and forgot what made them successful in the first place.
I've seen places where the juniors don't even really send email. They are essentially apprentices for their senior in like the medieval blacksmithing tradition. Working the bellows while the senior pounds out the sword. Eventually they graduate up but at first they aren't really trusted with anything but the most basic tasks.
More like an advanced apprenticeships where like me you'd be doing 1 day a week and possibly an evening at community collage and that is in my case was a four year.
The trouble is the cohort that would be ideal candidates now go to university as those roles are now degree entry.
> When I say "train the hell out of", I mean each new dev had a senior dev dedicated to just them who would criticize everything about their code and workmanship like a Mr. Miyagi.
The management should also be aware that senior dev productivity will also go down in order to train the junior devs. Schedules should be adjusted to accommodate this.
That sounds awful for the morale of the juniors. Juniors should feel empowered to take their own initiative and find their own groove. Having trust put in me when I was a greenhorn made all the difference to my verve and drive at the company. The times where I was castigated and hounded over every little style choice made me loathe the company and the senior doing it.
Expecting a new graduate/junior to stay at the same (probably his first) company for 4-6 years seems a bit optimistic. The companies often pay shit to such people and even if they excel at what they do, that additional +X% performance impact on their salary will barely matter if their starting salary was shit. Often job hopping is needed for any significant bump.
Well this approach doesn't work unless you actually promote people once they're no longer junior. In my time at a FAANG, I got a 33% pay rise nine months in along with a promotion. That kind of behaviour engenders a lot more loyalty than CPI adjusted raises when an employee is clearly killing it.
Before, mentoring was something that was only present when I started for less than a year but I could've used a more persistent program like this, I think, to help rectify a number of long-standing problems I'm only now starting to perceive and take action for much later.
How do you determine who is a dedicated job applicant? First, everyone shoots their resume and maybe cover letter into your black hole. Are the dedicated ones the ones who actually included a cover letter? Or is it how enthused/personalized the cover letter seems? A qualified individual should do that, perhaps even better since they have experience and talent, if they're indeed qualified.
Next, they have to go through interviews. Are they expected to fully research the company and its methods before the initial round? Or how about coding questions: Would you take someone who spent 3X the time on leetcode but only got 50% as many coding answers as the qualified person? Do you purposefully choose those who you deemed "worked harder" or "wanted it more"? Are things like follow-up emails, thank you's, further reflections, are these things how you determine dedication? Or do you purposefully over-look those you think are well qualified, ruling them out in favor of those "trying harder"?
We have a variety of low-commitment projects that we pay people to do. These projects add value to the company, of course, but they also allow us to get to know a variety of people who can become more involved with us. In other words, we've found ways to take risks on people, and get to know them, without hiring them outright. We hope to hire them, but they still do need to go through our filtering system first. It may not work in other fields, but it works well in the field we're in.
Of course, we also have a more traditional path, including resumes, interviews, etc. It's good to have multiple methods for finding employees, IMO.
I think what you're really asking, is are we "dangling a carrot" of actual employment, in order to trick people into working for low pay. The answer is a definitive no.
We actually do not advertise, in any way, that our smaller projects could lead to much bigger projects, and long term employment.
That being said, the pay itself is usually more than is offered elsewhere for the same type of work, or at least at par. We're lucky to have a business model that can support this.
They usually pay the standard rate that would be applied for the expected amount of hours of completion of that task, with a small plus. this way, even if you don't land the job you still don't get out of it feeling like you lost invaluable time of your life.
But in my own experience I have once worked for free on those tasks, hoping to get hired, and when it didn't pan out it made me a bit sour. Won't do that again.
I think it's a matter of how a company is run. Some like to exploit their employees, while others value them, and want them to be happy for the long term. In the long run, my hope is that the people we work with will believe they're getting the better end of the deal, and that (if they're employees), they are given stability and support for the long term. It's a matter of respect, responsibility, and commitment.
We always look for “rough diamonds”. It is a creative process, lots of tea leaves reading, but will yield excellent results if you have the ability to read these tea leaves. I am not sure we ever hired “the best on paper” candidate. But we have had great success with people who had no knowledge of out stack, down to the programming language.
I've always thought that there is undue emphasis on the tech stack and the language. I've always felt that filtering for raw engineering ability, thinking prowess, and attitude would get you farther in the long run.
While I tend to agree, there's obviously jobs where familiarity with stack, tools and best practices is more important than engineering ability.
They may not be interesting, but they do seem to comprise the majority of openly availible jobs.
My current job has minimum emphasis on language (C#, targeting original Framework 2.0, no new features) and zero tech stack. On the one hand it is interesting - not enterprise stuff - and puts the brain to real use often, on the other, I think it doesn't provide anything market worthy to my CV. As most of my collegaues work for over 7 years there, it really seems to be so.
Add to the list that the people who are best on paper and are good at interviewing will probably be looking for a new job in a year and/or when things get tough.
Wouldn't dedicated candidates generally hit up someone on LinkedIn to get put into the backchannel? Heck, people on HN have generously offered to put me into their company backchannel, so it doesn't seem to hard to get into it if you really want it.
I ended up being hired directly from university for my first position - another student in my algorithms class was a local company's VP. That said, I absolutely loathe back channels as they are a highly effective tool for discrimination. I don't hop jobs all that often but when I do so I do it via a recruiter and isolate myself from potential companies before the interview. I personally find leveraging back channels extremely distasteful.
There are some good ways to gain that level of contact though - directly reaching out to current employees is pretty effective with very few downsides as failing to get the job means they aren't going to be your coworkers anyways. However, I think even these approaches make the process overall less fair and equitable.
hiring someone you know, trust, like and you've seen their ability is no bad thing. Don't think there is any reason to loathe this. Lots of people network at meet ups to find positions this way.
It is a safe bet for the employer and ends up benefiting the employee chosen - the issue is that it can leave folks stuck "outside". Hiring is a messy process and anyone who says they only hire the best is lying to you - sometimes folks interview poorly due to having a bad day or end up being screened out due to automated software not seeing necessary keywords in resumes by blind chance.
However, the more you limit your hiring pool the more you're missing out on good folks and you can end up breeding a culture of nepotism within the company if you're not careful - where those folks that make it in from the outside are outside of the social group you're drawing from and end up leaving because it's cliquish.
We have hired those "rough diamonds" through "back channels" even though they have had terrible interviews due to lack of communication skills. They probably would not have been hired in most places. And it turns out they are good at their work and also loyal since they are a bit afraid of jobs interviews.
If a good employee vouches for someone, there is big chance we will give it a try. :)
I agree that it can be less fair and equitable, but it’s factors more effective in terms of conversion to productive employees.
If I ever decide to go out on my own and form a startup, my co-founder will 100% be an ex-colleague. Is that fair? Dunno, but it’s the only reasonable choice IMO.
Not only does the backchannel save a company many man hours of senior engineer time (which has the bonus effect of not upsetting said senior engineers), companies often give substantial cash rewards to employees who's referrals get hired and stay for some period of time. I'm talking tens of thousands of dollars, it's pretty insane.
I think a lot of it is cultural or learned. It doesn’t occur to some people that you can do things like reach out on LinkedIn or do things beyond just checking the careers page.
I read about people who fill out hundreds of applications and never get a response. I know it’s a numbers game, but that is absolutely wild the amount of effort people put into a strategy that clearly isn’t working.
What’s the chance that me hitting up some rando on LinkedIn isn’t just gonna result in them ignoring the connection or telling me just to line up at the front door.
Most people reply to me. I am currently job searching and I have one who didn't reply? Don't target the CTO as he probably gets barraged, but a fellow guy with 2-3 years experience? They reply. Random people off Hacker News? They reply.
Message a recruiter working with the company (internal recruiters for example), they are litteraly searching for people, they'll be excited that a candidate reached out.
Of course some don't answer, but it's not a big number
The best book I've read on hiring is "Who: The A Method for Hiring." It's so good in fact that I feel kind of bad sharing it, almost as if I were giving away a competitive advantage.
It makes a very simple point that runs counter to most silicon valley talk about "hire for slope not Y intercept" or "hire hustle" or whatever:
Hire people that have the skills necessary for the job that needs to be done. That's it! It sounds simple to the point of ridiculousness, but the truth is that most job descriptions/roles in an organization are written in a lazy way, in which the org has not actually done the work to figure out what specific skills are required by the organization to complete it's mission.
So instead, they hire for generalists, or for "people they like" or for people that fit a pattern--all because they haven't actually done the work to figure out what skills are actually needed.
Examples. A small startup puts up a job description for "senior ruby engineer." If the org is bottlenecked because they are working on very tricky code they should be interviewing for a very different engineer than if they are bottlenecked because they actually need someone who can ship simple CRUD features fast. "oh, but see we only hire senior engineers because {reasons}." Balderdash! Think about the problems you actually have, the skills and experience required to guarantee (or as close to it) that a candidate can Do The Job, and go.
Corollary: Have your interviewers be experts in the specific are you're trying to hire.
If you need a ruby engineer, don't submit them to a generic hiring panel. Have them spend an hour or two talking shop and doing some pair programming with one of your most expert rubyists. Master craftsmen can pick each other out in a second, but a whole hiring panel can fail to spot both bullshit and greatness.
Have at least one interview stage with experts in something specific. Having someone else filter out "cannot program" is fine to prevent the Sr. Ruby Engineer from looking at 95% "cannot program" candidates.
But that whole thing fails because often a skill needed is new. The easiest example I can think of is when a startup goes from 0 to 1 in the HR/legal/accounting areas.
In that scenario, is everyone hired on a contract basis? Do good workers get dumped after successful projects simply because the requirement they were desired for is complete?
I think companies hire for general skills not just because they aren't clear about goals, but because they're dealing with people. I get why you like the idea but you can't just malloc and delete people, they need some stability. And since the company probably won't be dropping their tech stack with each new project, hiring for knowledge in an area rather than knowledge of a narrower task seems reasonable?
People here are saying that Carmack isn't really saying much (quantity-wise he's not) or giving their own personal anecdotes, but he's touching on information theory for imperfect markets.
Basically the employer and candidate screw up the signals to each other about buying/selling of labor today, and it creates costly overhead for both parties. In a perfect market, employers and candidates know everything about each other and quickly fill- or land-in the best possible positions (respectively).
Not sure if the startup he's promoting, or throwing in random population sampling, solves this problem though. Seems like the random sampling is only a temporary fix to uncovering missed positive signals in candidates.
This is a long and polite way to acknowledge the UnderdogDevs group and not say much else.
Companies have a very strong incentive to miminise the false positive rate and the tradeoffs that they make there mean that they increase the false negatives because the cost of a bad hire is so much higher than the cost on missing out on someone good. In other words they're optimising for precision. I don't know how you start helping these disadvantaged groups without taking on a lot more risk and higher cost.
Yes, it’s true. Even if you remove the bad hires after six months, that’s six months of wasted mentoring effort and six months of of not being able to fill that position with someone who can do better.
That’s also six months that the bad hire’s coworkers have to put up with a bad employee on their team. They’re going to wonder if bad hires are the new norm and take it as a sign that it’s time for them to move on.
Bad hires have a lot of ripple effects. Most employees aren’t isolated islands within a company. Their coworkers suffer the most.
>because the cost of a bad hire is so much higher than the cost on missing out on someone good
The founders of WhatsApp for example applied to Facebook but got rejected. Facebook then had to acquire WhatsApp for 20 Billion, pretty expensive false negative. You can afford a lot of bad hires if a few of them hit big. That's basically the whole premise of venture capital and silicon valley, majority fail but a few unicorns pay the bills. Logically companies should be offering some sort of alternative short term "prove it" offer to people who are borderline for being hired.
I don't like this example because it assumes that the Whatsapp founders would have had the same billion $ impact at FB, or that FB would not have just acquired whichever app that would have filled the market potential otherwise.
We have to be realistic with WhatsApp founders from FB perspective when they did not hire them. They missed on good eng managers who may have grown to directors by now. There is about zero chance that they would have built WA inside FB.
The risk of hiring mediocre people who don't really care is invisible. Eventually, it becomes part of the fabric of the company, and the result, of course, is obvious. I suppose most large organizations can handle this particular risk because they've lucked onto a large cash-cow, such Google's ad-dominance.
If you want to actually empower people, just do it.
These companies have billions in cash reserves. If you don’t want to wire me that money, then at lease use it to set up
A shadowing program for ex cons to spend a month with one your engineering teams. See how software gets built, and also be a part of it asking questions and hanging out with the team.
Create programs that train adults to perform various jobs that are open. For example, many people would be willing to do any job at a tech company - it’s a booming industry. Why not have a pipeline for people to enroll to learn how to be a BDR, customer service, test engineer, etc. that results in them being placed at a job?
Or seriously give me the money and I’ll help set it up for you. All these people and companies talking about this stuff is annoying. Y’all are smart and resourceful so just do it and show us.
what's this rambling ... you go and call them up instead and tell them all about it.
and BTW, it's not about them having billions in reserves (idk why but I hate this phrase - maybe because I grew up hearing it), it's a legitimate requirement for them to hire more people if they want to expand.
When hiring for senior positions, its probably more easier to rig the system. At the level no one even thinks of checking if someone can code. I worked for someone like that to do their job for them. This person was hired on a 7+ year xp position for a job and only thing they knew is how to answer questions in an interview. I use to get the shared screen from their work computer and use to work for them.
My only guess on how they got the job was that the resume was saying so much that no one bothered to ask them to write the code. How do you get a high paying dev job when you can't write method, don't even know what return is? but you have degrees and all that fluff written in your resume. I don't understand.
It was occasional, I don't have stamina for part time regular job along with day job. Sometimes few days in a row for 1-2 hours a day. And yes, the person I was doing it for was in some corp in US.
Just a reminder that most requirements on job postings can be ignored. You can still apply and get through pretty often if you don't fit the requirements perfectly. There's almost no downside to applying.
Yup. But at the same time, in the current environment, the person who applies to 100 places will more often be better off than the person who applies to 10 places.
If you need a job, you gotta play the game. Mass applying is the current meta game.
While I don't advocate for mass applying, I have always believed that most top candidates for a position will only hit approximately 5/8 desired experience/skills points. As Carmack says in the thread, the labor force simply has a perpetually non-optimal distribution of skills.
After seeing it from the hiring side for the past 7 years, I can also say that there's usually a few extra unlisted criteria that would more than substitute for the skills you don't match on. The content of job listings is largely true to the desires of the hiring manager but also incorporates some organizational inertia. It takes a while to get new technologies incorporated into the practices of recruiting offices. Many managers are usually informally hiring for skills that have not yet achieved enough of a foothold to be a screening criteria.
That goes down with volume. If you apply to a large number of jobs then you won't worry about those who didn't call you back because you'll be too busy scheduling and attending interviews.
Of course, if you apply to a large number of jobs and don't get any callbacks then that's a strong signal that you either need to update your resume, update your credentials, or seek employment in another field.
Agree with this, but the thread doesn't really add anything to the discussion other than "hiring is a hard problem for both sides". People should upvote based on content, not the profile of the author.
I think the interesting addition is his point that adding some amount of literal randomness to stages of the process would be a good thing, if the culture around interviewing could change to accept it
I think he's specifically alluding to doing something like Bayesian exploration/exploitation -- which would be very interesting. Unfortunately, you'd need to hire at huge scale to assess the outcome of the experiment, and - as he mentions - it would be hard to get hiring departments to accept.
> interviewing prospects is a very non-trivial cost to an organization
Yet, a lot of companies would rather not give you that trivial raise to retain you, but spend that non-trivial cost to hire someone else at a higher rate.
When I was interviewing for a job, I complain about potential employers with their craziness.
When I was interviewing to fill a job, I complain about potential employees with their craziness.
Edit: I don't have a solution. I have all but given on the traditional method of applying for jobs via websites. Fortunately, I have enough network to help with my referrals and recruiters have been calling.
I too have found applying for jobs via web sites to be a complete waste of time. Every job I’ve gotten in the past 20 years was either through a personal contact or a recruiter who reached out and contacted me based on my LinkedIn.
Yeah I’ve never seen an employee recommendation not lead to at least an interview. This is one of the biggest lasting benefits of my MBA — if I’m ever out of a job, I can just find a company I want to work for and I probably know someone relatively influential there. It’s sort of a professional courtesy to recommend business school classmates even decades afterwards. These network effects are also why there’s often a bimodal distribution in outcomes between “top” schools and the rest of the pack.
I've been on both, but I also realize companies putting out a list of almost silly requirements that just about no person ever could meet has made many people 'stretch' their qualifcations too..
I have programmed against and Oracle DB becomes Oracle DBA experience, etc. Because when you do want an actual DBA that has a bit of programming background, you get so many applications for the first type.
Additionally, things like a Linux Systems Administrator can come in many different strenghts, and your going to attract a different level of skill by posting your salary range as 60-80k, than if you post 120-140k. But many employers don't want to post it at all, and then it seems you only get the low end guys applying.
One of the few actually useful functions recruiting companies can do is get the job salary range in agreement with the candidates desires before wasting anybody's time.
https://twitter.com/UnderdogDevs just links to a youtube channel. Assuming this is basically a pitch for UnderDog Devs... if you want to actually hire UnderDog Devs how do you learn more about that?
It isn't that easy to do. Anyone advertising their ex-con status is sabotaging themselves. So what signal do they use for every inbound resume?
So the company can't just trash the resume. After the interview, if things are moving forward, the candidate can inform the hiring manager of the situation. But if the company doesn't do background checks, they don't ask so you don't tell.
> Anyone advertising their ex-con status is sabotaging themselves. ... But if the company doesn't do background checks, they don't ask so you don't tell.
Not telling could be a time bomb. Perhaps proactively informing companies from the start is a strategy to weed out tepid employers?
Given some of the shenanigans Carmack himself got up to back in the day (including B&E), I'm not sure he's saying it's the right thing to do, only an easy, commonly used and widely considered unobjectionable first-level filter.
I feel like this is going to blow up into a thread with a ton of comments about peoples own personal opinions on hiring - while the actual content of this tweet thread barely flesh much out about the topic.
I think a company could do well by teaching HR about game theory: take into account what your competitors are doing for hiring and the best candidates they're skipping over when coming up with your own strategy.
>Many company leaders—nearly nine out of 10 executives surveyed by Harvard—said they know the software they use to filter applicants prevents them from seeing good candidates.
Holy shit, I was just thinking the same thing. We were talking about the various things that recruiters use to filter applicants, and they're largely untested, possibly containing unknown bias.
You know what's not biased? Random chance. Just try to get down to the bare minimum reqs, then randomly place in a queue. Then you have two options. Either truly random interviews, or the manager gets to pick out of some kind of priority queue.
There's still biases here, but we're not introducing any black magic. There are biases in whatever minimum specs you set. If you have the manager select, then you have their biases. Also, it would be hard to manage whatever the specs are, because you're probably not going to hire literally anyone, while maintaining this random strategy (without creating a new "system").
This is a brilliant thread. I recently got rejected (for a non-tech job) but at the time, I realised what potential employers were seeking. They were keen to have a round peg for their round holes without appreciating the holistic ideas I would have brought on the table.
I don't blame them. They are besotted by credentials - like everyone else. Though, from this point of failure, I have learned more about leadership than what an online course could teach me. Even though I exceed their credentials (I am qualified for the job), I didn't let a committee decide my sense of self-worth. I wished them good luck with the search process.
How does one get in touch with this UnderdogDevs group without a twitter account, or otherwise public account? I haven't seen an email address anywhere but am probably just missing it.
If enough state about a person is public and verifiable, then hiring can become algorithmic. As a bonus, if this is publicly disclosed, then the applicant can walk the path to close the gap to be hired at places they wish to work.
The catch is capturing and verifying the relevant info. It may not be tractable, to put it mildly. But it’s a useful thought exercise to think about what it would take for such an approach to be sane.
Require government ID, create an org for standardized certification, call it something dumb like "bootstrap certificate", which weeds out all the non programmers. Then you can focus on the remaining that are legitimate candidates.
There's more identity requirements and anti spam to a Facebook account than there is in hiring, and in a world of remote work that just doesn't work.
This is a particularly great story from a now defunct blog (hence the pastebin) that talks about how for free training on a technology platform you use extensively can be both good for you and for the people taking the training: https://pastebin.com/raw/QtePMR26
At least you all admit that college is a scam considering you don't hire people based on skill and education.
I have never had a job in tech because I have no idea how to communicate skill and passion outside of being good at cramming and faking my knowledge. Since I won't do that, I will most likely never get a job.
unpopular opinion most certainly but we are all part of the problem. if I apply for google right now I'm another one of their 10k applicants today. Google are never going to hire me. The solutions begins with applicants self filtering instead of blasting every company with their resume, then complaining that said companies are unable to scale their recruitment process.
Be more honest with yourself before you apply. Are you really qualified. Are you either already at or above the level of everyone they currently employ?
I literally hired a guy who was a part-time computer hobbyist but, a full time pool man. I told him "hey how would you like to spend 40 hours a week learning more about computers." Today he's working as a leader in his company's security group. He often thanks me for the job, and I always remind him "you did the work, all I did was give you the opportunity".
Sadly as stated in the thread linked, its hard when you have 10k applicants, to treat each as a potentially amazing member of the your team. I still try hard to look for that attitude and aptitude, and if a candidate demonstrates this in our dialog, I will do my best to find a path for them to connect with other opportunities if they're not a strong match for roles I'm filling on my teams.
What I know is we're born to this world knowing how to eat, breathe, cry, and a couple other things. The rest, all of it, we've learned on our way to this day. Just because the person in front of me didn't have the same path as me, doesn't mean they won't learn to have an incredible impact going forward. Searching for this potential and type of partnership at scale is hard. My heart wants to say it can be solved, but my calendar is an evil overlord that only allows me only so many hours a day to invest in growing my teams...