How to hire an iOS Developer

by David Tate on May 28, 2015.
You sat down to work today and see *Find an iOS Developer* staring back at you from the top of your todo list. This isn’t a straightforward task like “complete expense report”, “buy new coffee filters” or “fire Ralph” - this will take time, technique, and steady effort to complete.

First, the bad news: iOS developers are in high demand and have gone into hiding only coming out for interesting projects and to attend the WWDC. When you find a good one they can be very pricey.

But then the good news: Because of the obvious demand there are also thousands of people trying to join these group of talented recluses. But the challenge for you is to find members of the first group: experienced, talented, motivated and not the second group: inexperienced, looking to work on their first real project.

But first let’s talk about you.

Do you need an iOS Developer (yet)?

An iOS developer should be hired when you have a clear understanding of what you want and have decided that it should be for the Apple mobile market first (or in total / only). Do you know much about your target market - do any of them use Android? If so then hiring for iOS will not easily allow you to later support them; you might want to instead look into PhoneGap or equivalents.

Do you know exactly what you want?

Do you have an idea or a plan? You are competing for developers and one of the signals you send to people who listen to your offer is how well thought-out your project idea is. Did you just dream up something that you think would be cool or have you proven that there is a market for the product and know exactly how it will work? Do you have mockups yet of what it should look like? With tools like and Invision you need no development experience yourself to create something that looks (and acts like an app on your phone!) to validate the user interface.

A solid iOS developer will entertain multiple project offers and you want to stand out as professional, hard-working, and with a fleshed-out plan. Your project should feel that it already has momentum and its success is an inevitability.

Let’s talk about candidates again.

Vetting Candidates

Let’s assume that you post to one of the millions of free-for-all job posting boards that serve as the new age classified ads. Your inbox is then full of developers awkward cover letters and details of their experience with technologies you have never heard of.

How can you tell if you are:
- Talking to someone with experience?
- Talking to someone that can actually complete your project?
- Someone that can communicate clearly with you in regards to the details of the user interface, project status, and any problems faced during the build?
- Talking to a real person and not a dog trained by a talented prankster?

Research online presence

Developers have a number of tools with which they can show general competence in technical and non-technical areas. Look into each candidate's online activity:
- Blog
- Github or other shared code
- Twitter profile

You don’t need to do any private investigation-style research here - you are looking to see if their blog or code contributions match the general tone of a professional, match with their declared level of experience, and don’t contain any odd red flags.

Look in more detail at code contributions

Open source is a great way to vet candidates - you can look at actual projects that they have built and use them to ask questions about challenges faced and areas for improvements. Open source contributions are a clear way to tell see who is active and hustling in the developer community. Watching popular projects is a good sign, committing to projects is a better one, and being the creator of projects that are used by others is the best tell that you are dealing with a good candidate.

Components Built and Used

Not all code can be shared though - working for big companies means that some developers are quite good but simply aren’t allowed to show it publicly.

This doesn’t mean you shouldn’t ask what they would pull off the shelf for a new iOS project. After giving them a few details about your project ask them where they would start at a technical level. What components would they use for authentication, logging, UI components, caching, network handling, testing, etc.?

Feel free to also ask about specific commonly-used libraries like AFNetworking, JSONModel, DateTools, etc. as well.

Complete Lifecycle Experience

An experienced iOS developer will have some pet apps that they have developed in the app store - either to make money or simply built when they were learning the platform. Ask them to showcase some of these and talk over the challenges they faced. Compared to all other development ecosystems the app one has the lowest barrier to entry: developers can directly make money from their work by only trading their time. What challenges did they face once the app was live?

Tool Opinions

A new developer loves everything about a tool, platform, or language while an experienced developer complains about its limitations. This is part of the experience lifecycle:
- You love it but feel like you don't fully "get it"
- You learn a good deal and start to realize the limitations of the new thing
- You master all the strengths of the tool, and start to feel the weaknesses
- You are challenged by the weaknesses and they frustrate you.
In that way very experienced people sometimes come across as hating the thing they use everyday while also quietly respecting it.

A good way to detect this phenomenon is to simply ask:
- What do you not like about Objective-C itself? How about Swift or Cocoa Touch?
- If given the chance how would you change the XCode interface?
- You are king for a day - how do you change the app review and feedback process?

Are They Constantly Learning?

Ask them about their first iOS project and things that they would do differently now versus in the past. Ask them what the last technical blog post, book, or talk they consumed that changed their knowledge was. What resources do they use to stay up to date with new tools, components, and techniques? How much do they know about WatchKit or HealthKit?

A Better Path

You could do all these things, roll the dice, and hope that your developer gets the project done or you could use where your job posting will be seen by a multitude of iOS developers pre-screened and ready to work.

Building a consultancy while living in Japan with Keith Perhac

by Jake Jorgovan on May 18, 2015.

Today I am honored to have an incredible guest on the show Keith Perhac.

Keith runs a digital marketing agency called Delfi-Net, and best of all, he runs the agency while living in Japan!

For the past 12 years Keith has been living in Japan while building up a business primarily with US based clients.

In this episode, we dive into Keith’s journey, how he got started and built the agency to the point where it is today.

There are a lot of great insights in here on building up a successful business and living a non-traditional lifestyle.

Mentioned in this episode:

APIs and Higher Level Abstraction of AWS SES

by Marcian Diamond on May 18, 2015.

Hello Fellow Developers! As we trek along deeper into the computing wilderness and climb to the higher rungs of development, we become keenly aware of the unfullfilled needs of the development community. These needs tend to be sated by brave souls who endeavor to author APIs. Some quintessential examples of this courage are jQuery, D3, and OpenLayers, just to name few.

Whats an API?

Well, we all know that it stands for Application Programming Interface. Thats easy. But...

What does it do?

APIs are a contract between the user and the API provider. Developers typically use the method signatures defined by APIs to handle program functionality without concern for the how the functionality is implemented. In Computer Science jargon, this is known as abstraction, hiding implementation details from users of the API. By authoring APIs we are creating tools for developers while taking our skills to the next level.

Why use an API?

For one, they are easy to use. Just invoke a function or method with the appropriate arguments and watch the magic unfold. Another important consideration is application configuration. APIs can save us much of our most precious resource, time, by providing well-understood and commonly-used functionality as well as encapsulating lower-level application details.

In this article, I will provide an actual scenario through which an API may arise to fulfill the needs of an application. We will examine how a simple API may be created to provide a higher level of abstraction for sending emails through AWS SES service. The purpose of this article is to demonstrate processes involved in creating developer tools.

The Problem

For over a year now, I've been developing a Flood Forecast and Warning System web application with the Santa Clara Valley Water District, located in San Jose. This application is still beta, but is to eventually allow site registrants to receive email alerts in the case of a forecasted flood event.

To implement this email alert functionality, I decided to leverage the Simple Email Service(SES) infrastructure provided by Amazon Web Services(AWS). SES offers developers several powerful solutions for sending emails.

My application simply needs to send an email that has been dynamically templated. For my purposes and from a developer standpoint, a simple sendEmail() function with arguments for recipients, sender, subject, and body is desirable, yet I couldn't find such a thing! All the available options provided by AWS require SES credentials, lower level SMTP configurations, and/or long query string formations to dispatch to the AWS SMTP endpoint. The closest thing to this ideal scenario that I could find was the Sending an Email Through Amazon SES Using an AWS SDK. The SDK does a swell job of encapsulating the lower-level details of email sending through the AmazonSimpleEmailServiceClient and SendEmailRequest objects, BUT all I want is a method with the signature:

boolean sendEmail(String[] toAddresses, String fromAddress, String subject, String body);

As you guessed, this method would send an email to the addresses in the toAddresses array and return true if successful an false if not so.

The Solution

This is an ample opportunity to create an API that is a higher level abstraction of the services already available through AWS SES. By doing so, It will allow users of the API to send emails using a sendEmail() function and they need not be concerned with the other low-level (but never dull) facets of SMTP and AWS SES. However, as the author of the API, these details must be known and understood!

Now, Amazon SES provides a simple, cost-effective way to deliver outbound-only email. There are two primary options available to developers for dispatching email messages through SES. The SES SMPT interface and the SES API. The SES SMTP interface is used with an SMTP-enabled software package, application, or programming language or to integrate SES with an existing mail server. The SES API is used to send email using raw HTTP(S) requests. The AWS SDK provides a higher level of abstraction for these raw HTTP requests, but the level of abstraction is not as high as we please.

Before we dive into hacking an API, its useful to follow some software engineering best practices. First, we should clearly understand the problem at hand. The problem is AWS SES doesn't provide us with a high enough level of abstraction for dispatching email messages. Next, we chew our pencil tips and stare blankly into space for some time to determine the best way to solve the problem. BOOM! All of a sudden, the solution is clear: we will author an API that leverages the already existing infrastructure of SES. Since we are only concerned with one thing, the API will provide just that: a single function for sending emails. Now if this API is realized, my dev team can be provided with the API and begin sending emails to their hearts content with minimal effort (most of the effort is undertaken by the API author/s)! In this context, the API author must have a working knowledge of the solutions provided by SES. Only with this knowledge (and coding experience) would an author be able to deliver an API providing a higher level of abstraction of SES.


Though I mentioned only a single sendEmail function for consumption by API users, there is plenty of room to develop more functionality over SES. How about this: client-side javascript that allows browser users to send email through a dashboard app? One solution is to have a javascript function that forms HTTPS query requests, using paramters from the user's input, and uses AJAX to dispatch the requests to the SMTP endpoint.

Sorry, I will not implement the API in this article (maybe a future article! Or even better: you can do it as an exercise!), I simply wish to demonstrate how the birth of an API may occur and how APIs make the lives of developers even more pleasant. By taking the next step from API consumer to API producer, developers further their skills in the field and provide assistance for fellow developers. As an author of a popular API, various opportunities to capitalize on your skills will present themselves! Happy Coding!

Charging $20k+ per week with Brennan Dunn

by Jake Jorgovan on May 12, 2015.

In this episode I am honored to have Brennan Dunn as a guest.

Brennan has built up an absolutely incredible consulting career charging rates of $20k+ for a single week of work!

In this episode, Brennan shares how he built up a consulting career to justify charging those rates.

Brennan also shares best practices for raising your rates and getting more clients.

Brennan is an absolute authority and leader in the freelancing and consulting space and his advice in this episode is absolutely invaluable.

I would highly recommend picking up one of Brennan’s books Double Your Freelance Rate. I bought a copy over a year ago and since then my rate has tripled! Brennan also offers an incredible free email course where he shares absolutely incredible insights. Sign up for it and I know you will get a love of value out of the lessons!

How to hire a JavaScript developer

by Peter DePaulo on May 7, 2015.

That Javascript, it’s so hot right now.

It’s time to hire a JavaScript expert, and that’s probably a good idea. JavaScript doesn’t just run on the front end, but has become a powerhouse for creating full-featured and full-functioning web applications. Users expect snappy, responsive sites and intuitive interfaces. If it’s on the web, JavaScript is there.

Whether you’re trying to find a front-end designer type, a full-stack generalist, or a node.js back-end engineer, I’ll cover some high-level tips that will help in your selection process.

Before the JavaScript: What do you want?

The first (and hopefully obvious) thing to consider is what you want to accomplish with this project. In a time where everyone has an idea for an app, it helps to be specific about what the app does or at least the reason for the work being done. This doesn’t mean you have to completely spec out the technical details, but the more information you put into what you are trying to do, the easier it will be for someone to put that into code. The more you hash out internally, the less time you will have to spend explaining to a developer what you want and the less money you waste on unnecessary process.

For example, instead of simply expressing “I want a menu bar” you might say “I want a dark colored menu bar at the top of the page with dropdown elements on the rightmost side.” The things that you might think are obvious might not be so transparent to someone coming to the project with fresh eyes.

The many faces of Javascript

Once you have the idea and the project sketched out in detail, it’s time to start considering which type of Javascript developer you need. There are a ton of frameworks and libraries out there, so I’ll cover important themes with examples rather than deep dive into the technical details.

Front-end Javascript Developer

If you already have a back-end engineer, then you probably don’t need someone to write the business logic. A simple website with a basic contact form is completely in the realm of a front-end developer with only a small amount of experience. The work done in Javascript will be limited to polish, and responsiveness. They should at least know the JQuery library. (People that specialize in this are often called web designers, though the definitions have become very blurred.)

A fully interactive user interface will require more experience. You’ll likely want to go with a Javascript framework. Generally speaking, the primary thing to consider is not one’s experience within a single framework, but the understanding of what problems each framework solves. If you see that someone has extensive experience in Angular, they will be able to pick up something like React or Ember.js fairly quickly.

Most of the time, you can first look for specific experience in a framework. Know that it isn’t a disqualifier as long as they know a similar framework. The contradiction is in the case that speed is your primary focus. If you need to get something done rapidly, hire for very specific framework experience to cut out the learning time. A front-end developer should understand user experience, design, and should be assumed to know html and css on top of Javascript. They should make things look good, and should be able to convert mock-ups to working interfaces.

Back-end Javascript Developer

If you have someone to build the front-face of your app, then you are looking to a Node.js developer to build the backend. This experience is harder to measure in demos, because the most impressive technical feats are invisible. This kind of specialist will surely know another server side language. If they have already built apps with Node.js, great.

A back-end person is going to be responsible for any functionality that runs on the server. They will need to be familiar with databases as well. This will be either some kind of SQL database or MongoDB. (There are other schema-less databases, but mongo is the most common.) They will be able to connect data to the front end. A back-end engineer is great for writing APIs. They should understand the strengths and weaknesses of Node.js. If starting from nothing, they should be able to choose a database based on the project requirements. Don’t ask them to draw you anything or design the look of the site.

Full Stack

An app built from scratch will require understanding of how data is going to be stored and moved on top of pure Javascript knowledge. It will also require pretty strong front-end chops. A full-stack engineer should have a breadth of experience. This will include either knowledge of Meteor.js, or a stack that uses Node.js on its own supplemented by frameworks. Most common of these is the MEAN stack (MongoDB, Express.js, Angular.js, Node.js).

This person really needs to be able to handle any part of the application, and their experience should reflect that. Projects completed with Javascript frameworks are primary indicators of capability. Projects completed in other full-stack frameworks such as Ruby on Rails or Django are also good indicators that someone knows their way around web apps.

A full-stack developer is the most versatile, but not necessarily an expert in any one part of the stack. Perfect for prototyping, great for building apps from start to finish, but it would be unwise to hire a generalist full-stack developer for pure database architecture or for very specific design requirements.

Communication is Key!

The most common bottleneck to a project is not an ineffective developer, but a lack of communication.

Current tech culture would have you believe that an amazing developer can take the idea that you scribbled on the back of a napkin with ketchup and come back in week with the exact thing that you imagined perfectly tested and ready to scale to 10 billion people. This is a lie. There are amazing developers. They can build exactly what you ask them to build, but only what you ask them to. If they’re good, it will be ready to ship and can scale pretty well.

The thing in your head will not end up in the world exactly as you imagine it unless you can make it by yourself completely while predicting how the user will use it. You will have to communicate that to someone who understands it enough to make it.

For this reason, the most crucial part of hiring anyone (and especially one who must translate a set of ideas and drawings into a functioning tool) is that you can get what you want into their head. Communicating what you want is largely in your court, but finding that person who can grok things quickly can make a project go from frustrating-to-the-point-of-insanity to that-feeling-of-spreading-soft-butter-on-bread (ahhhh yiss).

I’ve seen many litmus tests for technical talent, but not much in the way of technical communication. The best way to test for an ability to communicate is to ask people to reiterate instructions. This often seems silly, which is maybe why people don’t do this simple test, but it is worth the time.

Another test is to ask questions on the edge of your knowledge with a focus on understanding rather than vetting. Maybe you know a little bit about JavaScript. In that case, try asking about some more complicated JavaScript specific ideas like closures or how the object model works.

If you know absolutely nothing about programming, ask something that you’ve heard about but don’t understand. If you can’t think of anything to ask, inquire about what new thing in JavaScript seems exciting. If you find that it’s easy to learn things from the person that you are asking, they are probably good at understanding and communicating abstractions.

Determining technical talent in JavaScript

Okay, this is probably what you were hoping for to begin with. At this point, being specific in what you want helps immeasurably. The question is “How can I tell if someone is good at JavaScript when I am not?” The first step is to try to find projects that the applicant has completed that are similar to yours. If they haven’t sent you anything to look at, ask them to do so.


These days, there is not necessarily a need for a static portfolio or personal website. A set of links is usually more than enough to get an idea for what people have worked on in the past. The portfolio is a great weeder to determine if pursuing more conversation with a person is valuable.

Live projects or demos are best. Look at what kind of functionality each of them has. Click around and get a feel for the style. If you like the projects overall, ask what features the applicant has built. This will give you an idea of what they are capable of.

For example, if one is built in a framework you want to work in, ask if this person created the app or started working on existing code. This is the most important factor in determining the technical skill of the person: if they can build what you want. If they have a set of projects that have parts of the functionality that you are looking to build, then they can probably build yours. It is really important to get a very clear idea of what features they are solely responsible for. People who have solved specific problems will be able to answer in pretty granular detail.


Github is the go-to for most projects. If you are building anything more robust than a basic website, you should be (or get) familiar with it.

You want to look at the projects that they have worked on by checking out the repositories that they have created or forked. If you are not already familiar with the organization of different kinds of JavaScript apps, it might be hard to figure out the file structure. At the very least you can look at their most recent commits and pull requests at the bottom of their profile page.

Inside of any given repository, you can see what languages are used by clicking the thin, colorful bar at the top. (hint: look for a lot of projects that have javascript.) You can also look at the commit logs to see what parts they have written. See if they have actually made changes to code in their commits.

If they have made meaningful contributions to open source projects, then they are golden. These projects are also a great discussion point. If they don’t have a Github ask them why and if there is another place where they push commits (like bitbucket). Something to note is that you won’t be able to see their commits to private repos. Their public profile might under represent their contributions.

Talent over trivia

If an applicant seems to have a strong grasp on the language and a lot of general experience, don’t fret if they haven’t done too much in the specific framework you want to use. People that have a deep understanding of the problems and patterns that show up in a variety of frameworks will be able to adapt to how a specific one handles them.

The projects that they have completed and how well you can communicate with them should dictate whether or not they get the gig. Good luck!

Learn and Earn!

Sign up for great tutorials, guides, rants, raves and opportunities to earn more money!