Skip to content

Latest commit

 

History

History
88 lines (58 loc) · 12 KB

Hiring-and-Firing.md

File metadata and controls

88 lines (58 loc) · 12 KB

Firing, Hiring, and Interviewing Candidates

Firing

aka, “the hardest thing you’ll ever do as a manager.” First are some tips on salvaging an underperformer. Then some tips on how to fire.

  • How Do You Fire an Employee That (sic) Just Isn't Good Enough? - by Michael O. Church. Takeaway: “The best employees are multipliers who make others more productive, and next are the adders (workhorses). Subtractors are the good-faith incompetents who cost more than they bring. Dividers are the worst kind of problem employee: They bring the whole team (or company) down.” Simplified as Multipliers/Adders/Subtractors/Dividers.

  • How to Terminate an Employee without Breaking their Spirit - by Dick Grote. Includes a checklist of questions the candidate will likely ask; come prepared with answers.

  • Letting Someone Go With Dignity - by Rebekah Campbell. Takeaway: Let people save face, don't procrastinate, stick to any agreements, be clear about what happens next; announce it to the team together and let them say goodbye. Some good advice, though we're not sure you should go out for drinks with the person you just fired in every situation.

  • The Right Way to Fire Someone - by Rebecca Knight. Takeaway: Don't drag your feet; make HR your ally; keep it short; stay in the room; show compassion; talk to your team; and focus on the future.

  • Why Firing Brilliant Assholes Is Required to Build a Great Engineering Culture - by Joe Stump (transcript by First Round). Takeaway: "Do not send a recruiter to do an engineer's job. It’s the job of founders and CTOs to be personally involved in the recruiting of the first 30 to 40 team members. Once you identify a great engineer, send your very best engineering employee who's personable to go after the person (this could be you). Make sure this individual can speak the candidate’s language and pitch them on the things that actually matter." And cultivate culture through communication.

Hiring

  • 7 Practical Ways to Reduce Bias in Your Hiring Process - by Rebecca Knight. Takeaways: Identify and actively seek to reduce bias. If you aren't talking about bias, you aren't changing anything. Standardizing your interview process reduces ability for subtle biases to creep in.

  • 25 Tips for Diverse Hiring - by Model View Culture. Takeaways: Externally, know what you want and be sure to actively pursue it. Internally, keep in mind hiring bias and internal culture. Ensure that your internals are prepared, as growing diversity is ultimately more important than hiring.

  • Creating the Dream Team: Transform Your Engineering Organization to Attract New Talent - by Andrew Hao. Takeaway: Focus more on building culture than offering perks. Assess your culture, set the example, and coach.

  • Developer Survey Results - by StackOverflow. Annual survey. Takeaways: When assessing potential jobs, developers prioritize "opportunities for professional development" over any other factor by a large margin; the comp/benefits selected the most often relate to mental and physical health: vacation days, remote options, and health; 89% of devs at least "somewhat agreed" that diversity is important, up from 73% in 2016; developers generally supported "c-sat" and "being on time/budget" as the best ways to evaluate the performance of a fellow dev; there's a moderate correlation between remote work and job satisfaction.

  • The Hidden Reason You Can’t Scale Your Engineering Team - by Jack Danger. Takeaway: Hiring only "senior engineers" is a recipe for failure. "When a team advertises that they only hire senior engineers, what they’re really saying is that their people and technology infrastructure can’t support hiring beginners – a strong indication of fragile tooling and a fragile team. If you’re at all interested in growth, this should serve as a huge red flag, because it is extraordinarily difficult to scale a fragile team."

  • How to Hire - by Henry Ward, CEO at eShares. Takeaways: Hiring is largely due to lack of scaling as a business and needing outside resources. It is more important to hire someone who can grow and contribute to your culture than someone who will fit in and have the same skillset as current hires.

  • How to Hire the Best People You've Ever Worked With - by Marc Andreessen. Breaks down hiring into two categories: Criteria and Process. For criteria, keep in mind people who are interested in your problems, who are curious enough to find solutions, and who won't waste time on bullshit. For process, he highlights that a lot of companies sort of hire randomly, with interviewers doing their own thing. And so different combinations give different results. Injecting some sense of consistency should lead to evening out your interviewing process.

  • How to Interview at Amazon - Leadership - by David Anderson. Takeaway: Though framed according to the activity of interviewing at Amazon and the company's principles, this detailed and thought-provoking article also provides insights on ideas on growing a team/tech organization; building a culture of customer-focused leaders; and much more.

  • How Slack Supports Junior Engineers - by Carly, a Slack engineer. Takeaway: a detailed, in-depth, first-person account of getting hired at Slack as a junior engineer. An invigorating read that covers the author's interview process, hire, on-the-job Imposter Syndrome, mentorship experiences, and more. Offers good ideas for ramping up your own processes for hiring juniors/first-job engineers.

  • Let’s Stop Calling Them "Soft Skills" - by Seth Godin. Takeaways: Don't overemphasize so-called "vocational" skills. Real-world interpersonal skills are just as (if not more) important. Details categories of qualities like Self-Control, Productivity, Wisdom, Perception, and Influence.

  • Never, Ever Compromise: Hiring For Culture Fit - by Elad Gil. Takeaway: "Your company culture is the foundation on which everything you do rests. Your culture acts as an unwritten set of rules that drives behavior and cohesion across the company. Cohesive, insular cultures are more resilient and can withstand shocks to it..." The article does point out that homogeneity of values is the idea, not homogeneity of backgrounds or personalities; however, its suggestion to use social outing tests (going to a bar) with candidates could reinforce monoculture.

  • Recruiting Diverse Engineering Candidates: What Tech Companies Still Get Wrong - by Angie Jones. Takeaway: The author describes her experiences interviewing with heavyweight tech companies like Amazon, Google, and Twitter, and reveals some of the disconcerting behaviors she witnessed during the process while praising the good. "All tech companies need to revisit their interviewing practices. Diversify the panel of people who will decide the candidate’s fate with the company; acknowledge that diverse candidates may be concerned with more than just the specifics of the job itself; and ensure that you allocate time for them to have their questions and concerns addressed. Finally, tailor the interview questions to the job for which the candidate is being considered, and steer clear of unjustified coding challenges that only serve to intimidate and stress candidates."

  • What Managers Are Getting Wrong About the World’s Greatest Job Ad - by Blake Thorne at iDoneThis. Takeaway: A good job posting outlines the mission, the risks and the rewards.

  • Why I Never Hire Brilliant Men - by anonymous. Takeaway: Be careful with the "brilliant" word. Many brilliant people start a lot and are visionaries or charismatic, but don't finish what they started.

Interviewing Candidates

  • A Better Way to Interview Software Engineers - by Zach Millman. Takeaway: "When you spend an hour asking how to improve some code, it shows that you really care about code quality and collaborative engineering."

  • The Guerrilla Guide to Interviewing (Version 3.0) - by Joel Spolsky. Takeaway: "You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers)...If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them...The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever." And more great wisdom from the founder of Fog Creek and StackOverflow.

  • Hiring Without Whiteboards - by Lauren Tan. Lists hundreds of companies that don’t use CS whiteboarding.

  • Interviewing - by Baron Schwartz. Takeaway: Understand what you're hiring for, ask questions about past performance only, and gauge potential by "asking questions about what challenged them and how they responded to it."

  • How to Interview Engineers - by Ammon Bartram (Triplebyte). Takeaways: Ask questions similar to real work. Ask multipart questions. Avoid hard questions. Make decisions based on max skill, not average/minimum skill. Most programmers prefer interviews to trials/take-homes, even though interviews aren't the best way to evaluate people.

  • A Recipe for an Interview - by Jocelyn Goldfein. Takeaway: Offers a list of helpful questions for uncovering how candidates (product, engineering, etc.) handle situations related to their application of functional skills/competencies.

  • Screen Engineers Better with a Debugging Roleplay - by Pete Karl II. Takeaway: Using a text-based, role-playing debugging game on a phone screen, Localytics doubled their team size within six months.

  • You Suck at Technical Interviews - by Laurie Voss. Takeaways: don't hire for what candidates already know, or for what they can remember during the interview; don't hire based on elite degrees or past employers; and don't hire friends and family. Instead, interview in order to find out if the candidate can do the job, if they'll get even better at the job, if they're continuous learners who can talk intelligently about technology, and if they're aware of what they don't know. Have a conversation, not an interrogation, and ask if you actually want to work with the person.