1. Outline skill and culture specifics.

Write down all the "must-have's" the person needs to fill the position, and the "like to haves" that the ideal candidate will have. No one will be the perfect candidate, but you can come close. If you're hiring an iOS developer and he or she must have Objective C, story boarding and multi-threading, that must be evaluated during the initial call.

If it would be "nice" if they knew Java for back end or sockets, but it won't be required on a daily basis, don't toss out candidates because they don't have that experience. That pickiness results in a longer hiring cycle while companies look for engineering unicorns.

If you're a remote team, it may be a bad culture fit to pick someone who needs hand holding daily. It's also tough to work with some "hacker" personality types if your entire organization is extremely professional. Know your company culture and ask questions about what type of working environment the engineer prefers.

2. Know the market price.

Some entrepreneurs think they can grab great talent at a discount price. Engineers are in demand, and the demand is only going up. Freelance engineers will have a range in hourly rate for their skill. You better know the market price or you may underbid and lose them to another opportunity, or overbid because they know you aren't savvy. They may be expensive because they are the best, or maybe because they think you're naive. Have a budget, and know what skill set you'll get for that budget.

3. Look for team players.

Engineers are notorious for being lone wolves who like to work alone. This is fine when they're typing code all day but they need to respond to requests in a timely manner, and can't complain about participating in mandatory daily and weekly SCRUMs. Ensuring they will communicate daily and help team members who fall behind are important for the project.

4. Do they hit their deadlines?

Product roadmap deliverables and iteration cycles are what drive software development, and these are always tied to deadlines. Ask questions about hitting deadlines, what happens if they don't hit their deadlines, and what they'll do to alert their manager when they fall behind.

"The biggest nightmare is an engineer who tells you he's on course, only to find out on delivery day he's not even close to submitting. It sets your whole team back, and possibly your whole company," explains Taso. "Be sure to really vet the engineer's ability to not only hit deadlines, but communicate accurately when he or she might be falling behind."

I've personally noticed this problem when outsourcing some of our development work for Due to agencies. They miss deadlines and aren't ever on-time with deliverables. This caused me, and I'm sure many others, to start looking elsewhere.

5. Standards.

Determine an engineer's standards when coding to determine whether or not you'll have bugs and crashes. You'll also want to make sure they're not causing any problems for the next developer working on the code, so knowing how they comment could be vital.

6. Coachability.

One of the biggest problems that any employer faces is an employee who can't take feedback. A great employee who takes coaching, and even wants coaching, is an employee who will have long-term viability at any company.

7. Check their portfolio.

Surprisingly, some engineers will send you links to their portfolio proudly, and its a buggy product. Ask to see a demo of their portfolio and always check their references to rest assured that they actually worked on the project.

8. Rapid prototyping tests.

Rapid prototyping a feature to see if an engineer really is adept at a certain skill set isn't that uncommon these days. Some CTO's at larger organizations have been known to have developers rapid-prototype feature sets for hours to confirm their skill set, all while he sits there, looks at emails, and occasionally watches. Watching the developer code and having him or her walk you through the process, what they're doing and why, will help you understand if they will be a good fit.

9. Don't rush.

Rushing will often get you the wrong fit. Create a process that includes a phone screening, an in-person interview, a peer interview, and a rapid-prototyping test. These steps will assure you the person is skilled, a cultural fit and will reveal to your team any red flags before you hire.

10. Do they have a network?

Last but not least, does this person have access to other developers? Hiring developers is very expensive, and an engineer who can convince others to join your team down the line clearly has leadership potential, is a team player who is well liked, and a great asset.

Edited June 1, 201511 yr by teodora

I think this is a a very good overview of hiring developers although there were some good points made in the above post.

 

https://medium.com/javascript-scene/why-hiring-is-so-hard-in-tech-c462c3230017

Good to know about it.

Interested in your last point @citypaul. As I mentioned I've yet to try out TDD but I comment my code quite heavily, especially my Sass modules. I actually put in markup snippets to illustrate to other devs can see how a module is marked up, and for me to just paste in to speed up development. Example:

@if ($options__use-styled-select) {
/*------------------------------------*\
    COMPONENTS -> FORMS -> ##STYLED-SELECT
\*------------------------------------*/
/*
   Allow for a select box to appear visually styled by styling an underlying label and setting the opacity of the
   select box to zero.  Requires class of .js-select on parent element to pass the selected value into the label.
   Example:
    <div class="select-wrap js-select">
        <label class="select-wrap__label">
            Select option
            <span></span>
        </label>
        <select class="select-wrap__select">
            <option selected disabled>Select option</option>
            <option value="1">1</option>
            <option value="2">2</option>
        </select>
    </div>
*/
    $arrow-size: 6px;
    $height: 40px;
    $height-lg: 46px;
    $label-color: $beta-color;
    $border-color: #ddd;

    .select-wrap {
        position: relative;
        height: $height;
        label {
            font-weight: 400;
        }
        &__select,
        &__label {
            @[member="Include"] positioning(absolute,0,0,0,0);
            width: 100%;
        }
        &__select {
            opacity: 0;
            cursor: pointer;
        }
        &__label {
            border: 1px solid $border-color;
            border-radius: $rounded-radius;
            line-height: $height;
            padding: 0 10px;
            color: $label-color;
            background: $zeta-color;
            span {
                position: absolute;
                top: 10px;
                bottom: 10px;
                right: 45px;
                width: 1px;
                background: $border-color;
            }
            &::before,
            &::after {
                position: absolute;
                top: 50%;
                right: $spacing-unit;
                margin-top: -($arrow-size/2);
                border-left: $arrow-size solid transparent;
                border-right: $arrow-size solid transparent;
                content: " ";
            }
            &::before {                
                border-top: $arrow-size solid lighten($label-color, 10%);
                transform: translateY(1px);
            }
            &::after {
                border-top: $arrow-size solid $zeta-color;
                transform: translateY(-1px);
            }
        }
        &--lg {
            height: $height-lg;
            &__label {
                line-height: $height-lg;
            }
        }
    }
}

I guess you are more talking in terms of JavaScript, PHP, Ruby though here?

Edited June 2, 201511 yr by rbrtsmith

I don't agree with the deadlines part. Working to tight deadlines is usually a really bad thing for a project, but unfortunately most project managers (usually technically inexperienced project managers) see it the other way round, as a way to get things done.

 

The problem then is that stuff gets hacked together under the hood to meet the "deadline", and then instead of fixing the technical debt that has been created, more hacks are then applied to implement the next feature to the next short deadline. Before you know it stuff starts breaking all over the place and more and more deadlines are missed. Confidence starts to go down and people start stressing out and start pointing fingers. I've seen it happen a million times.

 

Have you been reading my emails?

 

This culture of 'timelines' is definitely creating a whole heap of trouble down the line. I'm re-writing a site from PHP4 to PHP5 ... but it's not just the site that has changed, the clients business now is a different kettle of fish vs their launch day. The issue is with their first site they we're constantly battering with timelines and a 'just get it done' attitude, testing is never in someones 'timeline' and dang I can tell through their v 1 site. So far I've found 4 major security holes, filtering that doesn't actually work although the results do 'shuffle' no one actually check the new order matched the selected order, and this is only the start.

 

The biggest problem is that if these bugs were in the system then the 'data' in the SQL is now in doubt, it could be incorrect or inaccurate. I've wasted over 3 days now in total writing weird and crazy queries to try to identify which records are incorrect in a big way. So that 3 days of code which has no actual use other than to find their errors, it'll go in the bin. Then we've the problem of who is going to correct these records? I estimate maybe 2+ weeks work for a data entry / analyst to go through and correct them.

 

So their original 'timelines', if they had extended testing time these should have been spotted. Instead they pressed on and now face an unknown bill cleaning up stuff; and the PHP5 conversion timeline is now in question because it relies on the data to be correct!

 

Maybe I should have just posted in the mumble topic

You need to read their reviews before hire them.

Thanks for the good points Paul I agree in JavaScript and other languages they should be mostly self documenting. I'd prefer a slightly verbose functiion name if it described what it did vs a cryptic one. Verbose names are unlikely if we are making our functions just fit single purposes, and I think functional programming style really helps this, along with the ability to chain (returning the object or value the function operates on).

 

CSS yeah it's a special case (in more ways than one.) I love and hate it at the same time, but requires special attention to keep it well maintained.

Another area I always tell people to comment on is magic numbers.

 

 

I really loathe magic numbers and should be avoided if at all possible, in most cases the are smarter ways to do things, like vertically centering requires no magic numbers. But occassionally they're unnavoidable so they should be commented in such case:

.some-classname {
  left: 50%;
  top: 23px; // Magic number, some reason why it's necessary
} 

Without the comment a dev has no idea what that number means. Of course in Sass if we're doing something like this then the variable self documents, and hopefully we're not re-declaring it. A single point of source in some kind of variables file is a smart thing to do in these cases.

.some-classname {
  left: 50%;
  top: $navbar-height;
}

I look forward to you going over some more TDD stuff. It seems to be a really smart way of doing things. All the experts are touting it and following what the experts preach has served me well thus far.

Edited June 5, 201511 yr by rbrtsmith