If you’re not really a technical person, interviewing a web developer for the first time can feel a bit intimidating. The first thing to do is just relax. We’re real people just like you are, and we really do want to help you out. We already know you’re not technical and the best people in this business will know how to communicate technology to you in ways you can understand and integrate into your business.

This article is designed to help you ask the right questions for your kind of business, and to find just the right person or people who can not just build what you need, but help make your business more successful in the process.

Sifting Through the Haystack

I’m going to assume that you’ve found perhaps 10 to 20 candidates who you would like to talk to who can build your project. You’ve searched the various places where web developers like to hang out (see: How To Find A Great Web Developer if you’re not there yet.) and now you perhaps have a sales proposal either in hand or on the way from an agency and maybe a couple of resumes on your desk with all kinds of technical jargon that makes absolutely no sense to you whatsoever. Thats fine. You don’t need to know it. That’s not your job.

Look through all of your resumes and find the ones that “look” the best, like they were DESIGNED, and not just a bunch of information that was slapped onto a Word document.

Why?

Because this individual will have at least some level of care about their work and how it looks. That care in how their resume looks will translate into a much more professional looking product for you later on. I’m not talking about cutesy little flower graphics and line art images, although a nicely laid out color resume with screenshots of their work can be a very good sign.

Take note that if you’ve talked with an agency at this point, they will send you a proposal and that proposal will be laid out professionally in full-color and beautiful in how it looks. (If it’s not, run.) Your individual developer resumes should be no less. Most of them won’t be. Most engineer resumes look like a 5-year old wrote them. This is another reason to set it aside. Your developer needs to have very good communication skills. More on this in a moment …

Once you have the nice looking resumes in hand, set aside all of them with less than 10 years of experience. No, I’m dead serious. The further away you move away from the 10-year mark toward less and less experience actually building web applications, the greater and greater the danger that your project will have failure points.

Yes, the hourly rates of the people with 10 or more years of experience will be higher, no doubt. But since you’re not technical enough to know who to choose or not choose based on technical knowledge, you’re going to need to hire very knowledgable people. You need to make a decision as to whether you’re willing to risk your budget on failure or hire people with the skill and experience to deliver a functional project.

There is a time and a place to hire cheaper novice and mid-level developers. YOU and your business are not that place, and since you are not technical, now is not that time. You need as much experience on your side as you can afford if your project is to succeed.

The other thing to look for is a variety of clients. The more clients you see, the wider the range of experience with different technologies and differing business needs. If you see a resume where the person has worked only at one or two companies for the past ten years, this is not really a good sign; their skills will most likely be “siloed” and not in a good way. They may be very rigid in the technologies they know how to use.

A developer with a good string of past clients as a contractor is actually a better sign. Look for people who were on contracts for between 6 months to a few years. Most of my gigs have been around 6 months to 5 years on the same contract. Short contracts is not necessarily a bad sign, but a lot of short contracts can be a warning sign that this person isn’t someone teams like to keep around for very long.

At this point, your resume count should be down to 2 or 3 and no more than 4 or 5. You can have others waiting in the wings, but you need to select just the top 2 to 3 for your first go around.

Now it’s time to look at their Website

Every developer who is looking for short-term (temporary) gig work is going to have a professional website that talks about who they are and what they do for clients who need web application development, just like any agency will have.

Look at their site. Is it professional? Because this is likely the kind of work your web app is going to look like. If their site looks like crap, move on. You don’t want your project looking like junk.

The developer’s site should have a portfolio of other projects they’ve done and also a short list of what I call visible clients that almost anyone might recognize. If the developer has any kind of work with Fortune 500 companies as clients, that’s a huge gold star in my book. You typically don’t get hired by Fortune 500 enterprises if you don’t know what you’re doing.

Any Industry Participation?

Next, look to see if they have any kind of tech industry participation, like tech articles they’ve written, open-source projects they support, open-source projects they’ve personally written. These will tell you that this person is willing to put their skills out into the open for other peers to scrutinize and utilize.

I personally support a number of open-source projects and have written small libraries that help developers create smooth animations. (See: How to Be a Goddamned UI Rock Star, the title is a bit over the top, but it got people’s attention, which was my intention.)

Once you’re satisfied that their professional website is top-notch, move on to contacting them. And yes, I know what you’re thinking: “I don’t know what I’m doing. I don’t have a technical background!” Fine. You don’t need one.

Forget the Technical Interview. It’s a Waste of Time.

Engineer resumes are rife with technical jargon because that typically is the audience of people who are looking at our resumes—other engineers or tech-savvy recruiters. Since you’re not an engineer or a tech-savvy recruiter, you can ignore the technical aspects of our resume.

No, seriously, don’t worry about it. In a moment, you’ll understand why.

The truth is most engineers suck as an interviewer. All most of us know how to do is code, it’s what we’ve been trained to do, and if you put us in front of someone who is another software engineer all we know how to do is ask questions about what we already know, namely stupid stuff like: “What’s a closure?” or “How do I stop event bubbling?” or “What’s dependency injection?”.

Questions like these really tell you nothing other than the person knows how to code and understands coding and programming concepts, all things we already know and learned in college, bootcamp or as self-taught engineers. While it gives hiring managers and other engineers the warm-fuzzies lording their oh so superior knowledge over newbie to mid-level hires, it doesn’t help you as a client get your application off the ground from start to finish.

The point here is a technical interview is almost always a complete and total waste of time. Even for other engineers. We do it because we don’t know how to do anything else. And we often end up hiring people who can code really well, but not much else.

EVERYONE you will talk to during this process can code. So just forget about the technical interview. The point here is coding is not the only skill you need as a client. The REAL skills you are going to need are NOT learned in any school or bootcamp. They are only learned through extensive experience working in the field building what businesses need us to build.

Contacting Us

Believe it or not, about half the people you contact, will ignore you. We’re already working full-time on contract with Disney, Universal, Accentue, or some other big recruiter and our resume is still stuck on ZipRecruiter or LinkedIn or wherever you found us as “available”. Some of us leave our resumes up because we’re always looking for a bigger, better, more interesting new gig.

Most engineers will not leave a full-time job to work for you and your project. You’re considered “temporary” work. But you will find a number of us who do nothing but gig (temp) work and/or we are looking to fill gaps between jobs. We may have just left a job, or were downsized, we were fired because the new CTO is a first-class jerk, whatever. Everyone gets “termed” for various reasons at some point in their careers. It’s going to happen. Just don’t be surprised if you get ignored.

Once you do get a response from a potential developer, send them a SHORT description of what you are doing and what you think you need. You don’t need to give away your project’s secret sauce, but you do need to give the developer a 10,000-foot view of what your project entails and is all about.

You need to SELL the developer on your project. Devs like me need to be interested in what it is you are doing.

Agencies are different. These sharks don’t care what you are doing. They will yes, yes, yes, you all the way to signing a contract and taking your money no matter how crazy or far-fetched the idea. And they will bleed you until you run out of money and then they will deliver a failed project that never had a chance in hell of getting completed within your stated time or budget. They don’t care. And you can find these agency people literally everywhere: Google ads, LinkedIn, ZipRecruiter, spam in your email, and especially on Upwork.

Once you have a developer who is interested in your project, it’s time for a phone call or even a face-to-face conference call with video. Most people use Zoom, but I find that GoogleMeet actually has better video and features. Whatever makes you most comfortable for a first-time contact.

Setup a time—don’t just call the person out of the blue. This is an interview. We like to have these scheduled.

Forget the NDA on your first call. It’s supposed to be an interview, none of us is going to sign your NDA out of the gate. We want to know who you are first. When I interview with a Fortune 500 company, they have tons of proprietary stuff we talk about during the interview—there’s no NDA.

Once you hire us, sure, fire off the NDA and it will get signed. Everything at the right time and the right place.

Alright, time to start talking …

In this first interview the only thing you want to be doing is talking to someone you’d like better to get to know. Is this person easy to talk to? Are they jovial or even funny? Is this someone you would like to have lunch with? Do they sound knowledgable?

Ask them to walk you though how they would approach building your project? What technologies would they use? Where would the web application live (who would be hosting it)?

You’re not really looking or caring about their answers, people at this level are not going to be wrong; opinionated maybe, but not wrong.

What you are really looking for is: Do they sound like someone you would want to work with?

And that really is the bottom line here.

You can find the most experienced engineer on the planet, but if they are difficult to communicate with, all they do is talk in lofty jargon you don’t know or understand, if they cannot bring it into business terms you need to understand, don’t hire them.

Too many engineers are introverted trolls who can code very well, but little else. You need someone with communications skills, design skills, people who can write and document the code they’ve written, people with business acumen who understand how your application fits into the sales cycle. If your application accepts payments, do they have the business knowledge to know what invoices, subscriptions, PCI security, etc. are?

Once you find someone you really like to talk to, ask them, “Does this sound like a project you’d really like to work on?” Most will say “yes” but the truth will be if they give you a call back. You want someone who is enthusiastic about your project and not just “ho-hum” about it. Because in a month or two, when they get bored or another more sexy project comes along, they will drop you like old laundry, jump ship, and you’ll be stuck finding a new dev to come in mid-stream to complete what they started.

TIP: If you did your homework and had them develop your application using a very common technology stack, finding a new developer will be much easier and less expensive. (See: Choosing the Right Technology Stack for Your Web Application)

You should know within the first 10 minutes of a call whether this person is going to be right for your job. There is something to be said for “hiring intuition” and here is where that needs to kick-in for you as a business owner or the person responsible (the “stakeholder”) for running the project.

After the Calls

By now you should have at least one or two resumes of people you really like. Pick the one who gave you the most communication about how the project will enhance your business, NOT the guy who talked on and on about what a great language Java is. Getting a bit technical during a discussion is fine. Droning on and on about technical stuff you have no idea about is not.

The person you’re looking for is not just a coder, not just a developer, but someone who has a business mind, and an interest in your business, and how they can assist you with your project to make your business better.

THAT person will be like gold to you later on, even if all you have is the budget to hire them temporarily for a short project. Yes, people like us will be expensive in the short team as opposed to less experienced developers or offshore people. It depends on your comfort level with rolling the dice and having your project fail in any number of ways.

When to Talk About Rate.
What you’re willing to pay them.

Out of the gate, don’t waste yours or our time trying to hire a seasoned software engineer with a decade or more experience for half of what they typically bill. They’ll just hang up on you and that gets all of us no where. If your budget is only $50 per hour or less, you can find offshore people in Eastern Europe, South America, or India willing to take your money and it will be a roll of the dice whether or not you actually see completed software.

Again, 50% to 80% of all software projects fail to deliver because people hired inexperienced and/or offshore developers, or a shark agency using novice talent, but they billed you an expert rate.

Once you find the person you know you’re going to love working with, ask them what their rate is. They’ll tell you. If it’s too much, you can negotiate, that’s perfectly fine, I do that all the time, but only if the project is going to be longer than 3 months. A short-term project is going to be billed at my full rate. You only get the discount if you need me for 6-months to a year. Even then, don’t expect a huge discount. After all, you can fire me at any time and then you got my discount too? Yea, that’s not fair either.

Also, a major metro rate is going to be a helluva lot higher than someone living in Bozeman, Montana. It costs a lot more to live in New York or San Francisco. As such you can expect rates to vary widely.

The type of technology you are building will also determine the rate. PCI or HIPAA compliant e-commerce apps using 3rd-party payment API’s within an AWS VPC requiring an elastic infrastructure with multiple load-balanced servers will run you more than just a simple low-traffic business app running on your cPanel website somewhere inside of BlueHost. (Was that enough technical jargon for you?)

In my previous article, How To Hire A Web Developer, I discusses rates and what people like us typically cost. Be sure to read this article so you know what to expect for ballpark rates for differing levels of experience.

Once the two of you agree on the rate, then you can fire off your NDA, agree on terms of payment, whatever. It’s just good for you to know the ballpark costs before even picking up the phone.

Conclusion

Once you locate and screen just the right person for you project, the best way to see if someone is right for your project is just to talk to them, look at who they’ve worked for in the past, how many years of experience do they have, look at their portfolio of projects and websites they’ve done.

The best people will be the ones who are easy to talk to, who can communicate the technology of your project in business terms you know and can understand. If the candidate doesn’t speak your language, doesn’t know how to translate tech-speak into simple business terms that make you comfortable, move on. Sometimes it takes a few interviews before you find someone who gives you confidence that they are the right person for your kind of project.

Feel free to check out some of my other articles on how to hire your next developer or selecting the right technologies for your project.

---

Up Next …

---