John Carmack on Hiring
twitter.com
twitter.com
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...
I am not sure exactly what you meant to say, but this came off as a bit snide (to me).
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.
I did not make the top-level comment.
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".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.
CTRL+F for "WHO COOKS" and read the whole section to see a professional chef say exactly the same thing you said about programming.
https://joeandjin.files.wordpress.com/2011/10/anthony-bourda...
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?
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)
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..
Staff (personal) motivation is the key I think..
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.
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 :)
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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Everyone's a humanitarian when the sun is shining.
Currently our suspicion is that he is related to some higher up.
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.
1: http://braythwayt.com/posterous/2014/10/04/i-dont-hire-unluc...
This means you either get people who have good attention to detail, or people who have had plenty of failed iterations to polish their approach.
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.
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!).
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf (downloads a PDF)
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.
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.
The trouble is the cohort that would be ideal candidates now go to university as those roles are now degree entry.
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.
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.
Of course some don't answer, but it's not a big number
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.
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.
If a good employee vouches for someone, there is big chance we will give it a try. :)
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.
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.
How do you know that your style of tea leaf reading is effective?
ngl, the way you describe it makes it sound super cargo-culty, but if there is something more to it I'd love to hear it.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Is this true? Organizations I've been a part of the best hires were game changing for the company, and the worst hires just got fired after 6 months.
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.
So those people not leaving is a good thing.
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.
We've all heard this enough that we don't need to keep repeating it. It's fast becoming a cliche, if it isn't already.
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.
Companies that have these kind of resources and aren't hamstrung are ripe with fraud and abuses.
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.
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.
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.
If you need a job, you gotta play the game. Mass applying is the current meta game.
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.
Here a hiring process was adjusted so that good current employees could actually pass the hiring process.
Of course that doesn't solve the issue on how to get the first few hires.
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 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 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.
Sending an application using a recruitment website is like buying a lottery ticket with the same poor chance of winning.
And the easiest way to get a job offer is to know someone within the company that can recommend you.
“Thinking about this while considering the challenges that @UnderdogDevs face in trying to help the previously incarcerated into software jobs.”
Here’s a link to the Underdog Devs organization: https://www.underdogdevs.org/
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.
Not telling could be a time bomb. Perhaps proactively informing companies from the start is a strategy to weed out tepid employers?
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.
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").
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.
The first doppelganger first critted a disintegrate spell and killed the rogue 200hp dammage
The second doppelganger one shoted my character.
50% party kills in one round.
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.
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.
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.
What a waste of time
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?