# How to Hire Your First Developer (Avoid These 7 COSTLY Mistakes)

Channel: Rob Walling
Video: https://www.youtube.com/watch?v=3LDd-ZLNMGA
Duration: 10 min
Language: English
Words: 1978
Transcript page: https://viewrankai.com/tools/youtube-transcript/3LDd-ZLNMGA

---

[0:00] So, you're finally ready to hire your first developer. It's a huge step, but let's be honest, it's a little terrifying, too. Because if you get this wrong, you're not just burning your money, you're risking your time, your energy, and maybe even a bit of your sanity. In this video, I'll break down the seven mistakes I've made myself and seen happen over and over across my more than 220 startup investments. These are the most common mistakes folks make when hiring your first developer, and I'm going to present them here so you can avoid them and keep yourself moving forward. And make sure you watch till the end. The final mistake is one I've

[0:31] had to learn the hard way more than once. Mistake number one is casting a net that's too narrow. So, a lot of founders whip up a job post, drop it in a few generic job boards like Upwork and Indeed, and they think that's the best they can do. But if you want the best applicants, you need to do more. You have to go on the hunt. Make sure you're sharing your job posts with your personal network and reaching out to folks who you think might be a fit or if they might know someone that fits the bill. So, if you know a great developer, see if they know of anyone who might be

[1:01] interested in your role. You almost need to think about it as a light outbound sales approach. And this definitely takes time. I get it. It's a lot of energy and some folks don't have much of a network to rely on. In that case, you might consider a talent platform like G2I, the sponsor of today's video. G2I doesn't just give you access to over 8,000 prevetted engineers. They clear away the chaos and clutter when it comes to hiring. There's no AI generated resumes and no time wasters, just solid candidates with at least 5 years of proven experience. G2I does the vetting for you with customized live technical

[1:35] interviews so you can actually see how a candidate might work with your team. Companies like Meta, Microsoft, and ShopMonkey trust G2I. And so do firsttime founders who just need to get this hire right the first time. If you need a prevetted engineer to join your team quickly, head to g2i.co/microcom to start your 7-day free trial. And if you mention microcom, you'll get $1,500 off your first invoice. That's

[1:59] g2i.co/microcom. All right. So, if you're putting up job postings and not getting much response, it either means you're not putting in enough leg work to find candidates or you're making mistake number two, where your job description lacks clarity. It's a little too appealing to throw a handful of generic buzzwords and throw some bullets into a doc and think that that's a good job description. If you don't define specific problems, tasks, and one month and three month goals for your new hire before starting your search, odds are you don't have enough clarity around the role. These days, Chat GPT, Claude, and other AI tools can be helpful with this. Certainly,

[2:39] creating a job description from scratch, just using AI, can be pretty dangerous because it's going to pull the average of all the job descriptions on the internet, and that includes really good ones and really crappy ones. So, I like to be pretty opinionated in my job descriptions and be very focused and clear and actually have shorter job descriptions than you might think. Just throwing in a bunch of buzzwords and bullets that you pull out of chat GPT

[3:04] doesn't make your role any more clear. And if you find yourself just adding to it because you feel like it's insufficient, instead try being more specific and thinking about the specific problems, tasks, and near-term goals for the role. The third mistake I've seen founders make and have made myself is hiring solely for technical skill. If you focus only on technical skills and you fail to assess if the candidates's personality, their communication style, their work ethic are compatible with you, the founder and the company values, you're going to have a problem. In addition, seeking a developer who only has corporate or big tech experience where they've worked on 100 person teams

[3:43] for 5,000 person companies is going to be a problem. A startup requires a scrappy generalist mindset and I don't want to hire and try to train for these soft skills if I'm hiring a developer. You can obviously do some coaching in your role as a manager or founder. But especially as a first hire, you don't have the time as a founder to do extensive coaching of a candidate. And so if you are solely looking at technical skill and you're not looking at how they fit into your company's culture, work ethic, communication style, and you're not paying attention to their past employers, meaning, hey, they worked for this 10,000 person

[4:23] company. Surely they'll fit into this role as employee number three, it's going to be a problem. You're going to have a bit of a rude awakening. In addition, I mean, this is kind of a side thing, but if you're hiring solely for technical skill and not thinking about time zones and how often you might need to collaborate with this person in real time, that can create problems for you down the line. If there's only 2 hours or 3 hours a day of overlap and everything's asynchronous, it makes it really hard if you need to collaborate with this candidate. The fourth mistake I see folks making is setting the wrong

[4:51] budget. So if you are just defaulting to the cheapest option, it's going to lead you to hiring someone really junior or maybe someone who can't hold a job at other companies. So especially when non-technical founders are hiring folks, you really should be paying at least market rate for strategic experience and sometimes you need to pay a premium in

[5:11] order to bring the best candidates. Mistake number five is not vetting skills properly. So this is skipping practical realworld tests like a paid trial project or even doing pair programming alongside them to not only see what the end result is like but to see their thought process. And you can do this remotely or in person. I have hired I believe more than 50 developers in my career as a tech lead, an engineering manager and of course as a founder. And I found that if you don't have a real world test and you only go off of conversations, resume, and references, if you're hiring a developer, that's a problem. You need to

[5:48] see their code. You need to see their thought process. In addition, I see folks failing to conduct thorough reference checks. And there's a couple tricks to this. If you get references from the candidate, sure, you can call them. Consider having more of a casual conversation with their references, asking, "Would you hire this person again?" uh look, we think we're going to hire them, but can you help me coach them? What are their minuses, their strengths, their weaknesses? Talk it through. And don't just ask one or two reference questions that allow people to kind of skate by. In addition, instead of just taking the candidates's references, if you have any shared

[6:24] connections on LinkedIn, for example, if you know someone who used to work with them, that's a great way to check references. It's more of a warm reference check because you know someone who worked with them. That can be a big advantage as well. Mistake number six is giving inaccurate or inflated job titles. So giving a title like CTO to your first hire to make the offer more attractive creates significant organizational problems later on. I did a full Micro talk on hiring and team building. I talk a lot about titles and title structure in that talk. If you

[6:53] haven't seen it, you should go watch it. But avoiding title inflation early on is something you're really going to want to focus on. And the seventh mistake I see folks making is not onboarding properly. So, it's forgetting IP protection, right? It's failing to have a proper intellectual property assignment agreement signed on day one, which can put you and your company's ownership of your code at risk. Second thing is not being clear about expectations. Here's how we work. We work with urgency. We work 40 hours a week, give or take, sometimes more if needed, but I expect you to work 40 hours a week. And if you

[7:24] run out of work, ask for more work so we can keep moving forward. And communication norms. Hey, typically we communicate in Slack or we like to do mostly via email. Only do Slack if you want to interrupt. We don't have a lot of meetings. Whatever your work culture is is probably slightly different than this candidate has had in the past. And another way I've seen folks not onboard properly is not helping them learn your codebase and dev practices. Again, even if they're a senior dev, the last place they worked at probably had slightly different development practices and norms on the team. In a minute, I'm going to get to the last mistake. It's

[7:58] the one that almost every founder makes. But first, I want to invite you to join Microcom Connect. MicroCom Connect is the best community in the world for SAS founders. It has grown to hundreds of members. We have lively conversations in our forums and we have monthly live sessions with SAS experts to help you solve the hardest parts of your business, whether it's sales, marketing, copywriting, or getting that first customer. So, if you want to be part of an incredible community of founders, you

[8:26] can head to micro.com/connect. And if you sign up this week, you can get your questions answered by me in a live AMA I'm doing on October 15th. It's always a good time. I hope to see you in there. For full info about connect, head to microconf.com/connect to apply. All right, the bonus mistake I mentioned before is number eight, not firing quickly. If someone's not working

[8:47] out, you might have heard this before. Hire slowly, fire quickly. It's said frequently. Why is it so hard to follow this advice? Because it's never as clear as you want it to be. This is a startup. You're going to have to make hard decisions with incomplete information. And when there are other humans on the line and you're generally a nice person, you want to give folks the benefit of the doubt. We've been taught growing up to be nice, to not be judgmental, and you know, again, to give folks the benefit of the doubt. Plus, it's an uncomfortable conversation. It sucks. It sucks to think about rehiring, finding a

[9:18] new candidate, retraining. It sucks to think about having that conversation where you have to let someone go. So that's why it's so hard to follow this advice. There's this internal resistance that each of us have. Bottom line is I've never heard a single founder say that they fired someone too quickly. It's always I should have done that months ago. If you're overwhelmed and you're just not sure which role you should hire next, you should check out this next video. This was a talk I gave at Micro Comp a couple years ago and I referenced it a few minutes ago. In this talk, I lay out the exact hiring

[9:47] structure I see working for most successful early stage startups. Make sure you like and subscribe. Thanks for watching.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt