3 Ways to Know If A Developer Is Good

If you don’t necessarily have a technical background and you’re thinking about bringing in a developer, how do you assess them? How do you even know if they have the very particular set of skills your site or application needs?

On this Founder Friday, Mattan and Chris tackle how to win devs, and make an exciting announcement for all you geeks on the comic book side of the spectrum.

Programming is its own language. Or rather, it’s a language with lots and lots and lots of different languages that different developers speak. But as a non-speaker, there are several ways you can break through all the C++ and CSS to get an honest, accurate picture of a potential developer.

1: Master The Phrasebook

The hard truth is if you’re hiring someone to code for you, you should learn at least a little bit of code. That takes time, and some effort, but it’s worth it for a couple of reasons.

The first is that you need to know what you’re talking about, at least at the surface level, because that’s going to inspire confidence and trust in your developer that they’re working for someone who knows what they’re doing; that they’re working for someone who values their contribution.

But beyond that, you need to, at least on the surface level, know what they’re talking about, and the basics of the argument they’re making for themselves. There are many places all over the internet you can get access to an hour of code, just to start you off.

But rather than leaning only a little bit of HTML, or a little bit of Java, the best play is for you to develop (ha) a holistic sense of what code is and how it’s useful to your business/startup/site. More about that at the bottom.

2: Check The Portfolio

It’s not your job to know everything, however. The best lens into a developer’s skills and experience is through a portfolio of their work.

Whether it’s just screenshots or whether they’re able to bring in an application they worked on, actually being able to see examples of their work can give you a sense of what they’re capable of.

But you can’t just look at webpage. You need to be strategic in how you’re ask a potential developer to describe their experience, and drill down on their portfolios. Find out what their personal contributions were. Push for the reasoning behind why they make that choice and not a different one. Get them to describe how they worked on their projects, whether it was remote and freelance or leading a team.

Look not only for their expertise, but how engaged they are in telling those stories. It’s worth taking at least 5 minutes on each example to really get a candidate talking. People will reveal themselves once they’re put in the position of having to relate their experience.

You want someone who’s thoughtful and excited about what they do, not disengaged, condescending to a non-programmer, or talking over your head.

3: Ask For Recommendations — From the Candidate

The other way to get a thorough, but thoroughly non-technical, sense of a good developer is to ask for recommendations. Before you make a call or shoot off an email, ask the candidate what they think their references are going to say.

Before you actually call and contact the references, ask the candidate what they think their references will say. This will tell you a lot.

Again, pay attention to the language they use — whether they’re hesistant or dismissive or really eager to talk about their old team.

Don’t worry about the imagined imposition of reaching out to someone who’s worked with a candidate. It isn’t one.

Talking to someone on that person’s team can give you a whole other window into not only what that person’s skills are, but how effective they are in accomplishing projects and collaborating.

Whatever you need a developer for, you’re going to need them to keep you in the loop. So, just keep the “no jerks” rule in mind. No jerks. Don’t do it. You want someone on your team to be on your team.

And lastly… Should you require a developer test or not? Some specific questions to ask if you do:

There are a few additional ways to judge a developer.

A trial period, or beginning a working relationship with someone on a project basis, is almost never a bad idea. It gives you a chance to test their ability to contribute effectively to your team — and see the progress they make with their code — without the full commitment of a salary and benefits.

Ask them what their experience with and how open they are to regular check-ins. Again, good developers won’t just be able to code. They’ll also be open to feedback and willing to present their ideas to non-technical teammates.

Some specific questions that can help you gauge a developer: ask them what their favorite stack is, what language do they like to code in and why? Do they do any testing, and if so, what kind of system? Do they use version control, like Git? Just because someone’s been coding for a while, that doesn’t mean they’re good.

Look for someone who’s open to trying new things, and who seems like they can adapt to the constantly changing methods and technology.

It’s really that willingness to communicate, and the ability to explain themselves and be held accountable, which separates good developers from just developers.

Even if you only need some one-off help, you’re bringing someone into your team’s locker room. It’s not enough that they can code. They also have to communicate.

How to Get a Job at a Startup

How to get a job at a startup

People are constantly asking me how to get a job at a startup.

It’s can feel like a difficult thing to do if you’re not already involved in startups or the tech industry.

The problem with getting a job at a startup is that startups are a bit like a black box, where you have no idea what’s going on inside. There are at least two reasons for this:

  1. Startup skills (the skills that startups are looking for when they’re hiring) often aren’t university skills, they don’t necessarily align with degrees and they certainly don’t look anything like traditional roles at most bigger companies, which tend to be highly specialized and functional.
  2. Startups are usually bad at process and planning. That means they’re not good about identifying roles and jobs they need to fill, writing job descriptions for those roles, and performing a full candidate search process. It just isn’t the most important or highest priority thing at most startups, whereas bigger companies often have entire teams dedicated to hiring.

So if you really want to work at a startup, what can you do? I have three pieces of advice:

1. Specialize in one or two things that startups often need

In a previous post, I’ve described the 20 skills I think a Full-Stack Entrepreneur could work on to be successful. Those areas are true for people looking to work at startups as well.

Areas of expertise that you could develop that most startups are looking for include (in no particular order):

  • Product Design
  • UX/UI
  • Customer Support
  • Data & Analytics
  • Customer Development
  • Project Management
  • Product Management
  • Growth Hacking
  • Business Development
  • Enterprise Sales

Marc Andreessen has a great blog post series on career planning in which he quotes Scott Adams (the guy who created Dilbert):

If you want something extraordinary, you have two paths:

1. Become the best at one specific thing.
2. Become very good (top 25%) at two or more things.

The first strategy is difficult to the point of near impossibility. Few people will ever play in the NBA or make a platinum album. I don’t recommend anyone even try.

The second strategy is fairly easy. Everyone has at least a few areas in which they could be in the top 25% with some effort.

If you want to become really good at something quickly, the key is to narrow down the focus to as small of a thing as possible. Doing this lets you consume and exhaust most of the existing resources around that topic fairly quickly and gain a lot of the knowledge.

Here’s an example: Rather than trying to learn everything about product design, pick one area — like user onboarding — that you’d really like to focus on, and learn everything you can about that thing.

If you want to get really knowledgeable about user onboarding, I would read through all the onboarding teardowns on, I would read all the questions on Quora and topics on related to user onboarding. I would study the onboarding flows of some of my favorite products. And I might even reach out to a few product designers through Twitter or over email and ask them their thoughts. I’d probably also do some reading on UX/UI and landing page optimization and build out a few onboarding flows myself.

Following these steps, you could get pretty knowledgeable about user onboarding in a matter of weeks.

The best products don’t try to do everything for their users — they focus on doing one thing really well — and you shouldn’t try to be a swiss-army knife for everything a startup needs. It’s easier to get a job if you’re good at something that would be very useful to a small number of startups rather than not be very good at something that a larger number of startups want.

2. Rock the interview

As a person new to startups, try to avoid allowing the interviewer to focus on your past experience, because most of it probably won’t be relevant to the new role.

Instead, recognize that every startup has a problem. In order to get the job, you need to convince the interviewer that you can solve the problem, because you know what they’re doing wrong and you know specifically what you would try to fix it.

When you interview at a startup, make it very clear what you know versus what you don’t. If you don’t know something, don’t pretend you do. It will become blatantly obvious very quickly.

Something that really makes you stand out is walking them through specific examples of how they think they could improve their product or process. Give them your ideas for free. The ideas are not your secret sauce. What they’ll hire you for is executing those ideas.

3. Flip the tables

My biggest piece of advise that few people actually follow is to put yourself in situations where companies can fight over you rather than the other way around.

When applying for a job at a startup, you’re just one applicant out of dozens. That puts you in a pretty bad position.

I accidentally stumbled onto a solution to this problem when I started teaching classes about coding and growth hacking at places like Udemy, Skillshare, and General Assembly. People at startups (often the founders) paid money to sit in a room with me for an hour while I taught them everything I had studied and knew about coding and growth hacking.

Every time I taught, there were 30–40 people in the room. Each one of them needed someone like me (otherwise why else would they be there?). And so people often came up to me afterwards asking if I was looking for a job or doing consulting work. “This was great stuff,” they’d say, “but it’s a lot of work and you’re really good at it. Could we just pay you to do it instead?”

Even if you don’t think you’re an expert in something, you can become fairly knowledgable about something small very quickly (see point #1).

Also, I learned that you don’t have to be an expert in order to teach a class about something and have it still be valuable for people. When I first started teaching about my experience learning how to code or growth hacking, I wasn’t an expert in either. I was fairly up-front about this (I used to say “I’m just a beginner, but I can tell you everything I’ve learned and read from these experts, and hopefully you’ll get something valuable out of this class.”)

It turns out beginners who are a few steps ahead can actually be really good teachers (sometimes better than experts), because they’re easier to connect with, and they have a better understanding of what a beginner doesn’t know.

So hopefully these three tips can help you get a job at a startup. Have any additional advice or tips for snagging that interview or getting that job? Or have you seen anything really work (like this guy who got a job by running $6 worth of Google Adwords for people searching their own names)? I’d like to hear about it! Post your thoughts in the comments below.

Founder Friday

I’m doing a series of short, candid, quick videos and blog posts — I call it Founder Friday.

If you want to see more of these, share a note in the comments and let me know what you think.