How to Hire Your First Programmer for Non-Techie People

A guide to hiring your first programmer, for the non-techie!.

Why I’m Writing This

A friend of mine is currently in the middle of hiring her first programmer for her new game studio, and I offered to help steer her towards a more suitable hire as I saw many startups struggle or downright fail after hiring the wrong person.

I decided to turn this into a blog post in case it helps someone else too.

But I must put a disclaimer: My professional development background is mainly web development, while my professional background in games development is negligible as of writing this article. As such I will be tackling this as a general programmer job, not specific to games development.

The Impact of Your First Hires

I’ve worked in multiple startups before and I can say with confidence that your first five hires will determine your entire company’s culture, or at least the development team’s, now and long after they’ve left the company.

So, before looking at their qualifications, look at their personality, and whether it fits with the culture you wish to develop.

For example: If you wish to nurture a culture with good life/work balance, then don’t hire any workaholics among your first five.

Your First Hire

Your first hire will most likely be your future team lead, assuming they stick around long enough.

For this person, they need to:

Work well in a team.
Be capable leaders (pushovers and tyrants not suitable to lead programmers).
Understand business, and experience working in a startup would be great too.
Have a high sense of integrity and work ethics (you don’t want someone who doesn’t care about the success of the team/company making important decisions or writing your game’s base code).
Love to help and teach (they will be doing lots of that to you and your other hires).
Be able to architect software well.
Be able to estimate how long a task will take reliably.
Be productive programmers.
Think of performance and other lower-level issues than simply coding.

What Questions To Ask in The Interview

You know best if the person you’re talking to will fit culturally with your company so I won’t touch on that here.

Instead, I’ll focus on the more technical questions to ask to determine those last 4 points I pointed out in the previous section.

Question #1: Show me your portfolio.

Simple: no previous work = no hire. You want someone with actual programming experience building published projects.

Preferably using the language(s)/tool(s) you’re hiring them to build in.

Question #2: Which code versioning tool do you use?

This is a trick question 😀 .

It doesn’t really matter which versioning tool they use, what matters is that they use one AT ALL.

Using one indicates that they care about their productivity (or worked with one who does, anyway).

Which tool to use depends on the project and learning new ones doesn’t take too long, roughly 15~30mins a day for one work week is enough.

Question #3: How do you document your code?

Code documentation can be done in many ways, most important are code comments.

But other forms of documentation can be necessary too depending on the project.

If they don’t write comments, don’t hire them. This should be a minimum requirement for any hire.

If they write bad undocumented code really fast they will be suitable only for building prototypes and other throwaway code.

Question #4: How do you plan and organize your projects’ code?

There’s no right or wrong answer to this question, because it will depend on the project.

The important thing is that they do have an answer.

If they stumble and stutter and are generally unable to answer this question, it means they’re not suitable as a first hire.

This refers to their ability to architect software well.

But note that simply thinking about how to organize a project is very basic and minimal, and not an indication of a capable developer.

Question #5: Which software design patterns have you used in the past?

This is a fun one :D.

I expect most to fail this question (at least here in Bahrain).

If they have used any design patterns in the past, then that indicates they’ve delved deeper into the realm of programming and software development than most around here.

If they haven’t, then they should at the very least know what a software design pattern is, be aware of them and be interested in using them in the future.

Question #6: How do you debug a problem?

They should be able to explain to you their debugging process step-by-step (Hint: Googling or asking for help should come last).

If their favorite “debugger” is Google they’re not skilled enough for this position.

Question #7: Have you followed TDD or a similar development process before? If yes, which? If not, why?

Test-Driven Development is a technique used in software development to maintain quality and make sure requirements are met in an efficient manner.

Similarly to previous questions, the actual process they like to use isn’t that important (I won’t advocate TDD over other processes, as the best depends on the project/team).

The important thing is they should employ some formal process in their development, whether it’s an internationally standardized one like TDD or something they came up with themselves.

Question #8: Do you use the same programming standards/best practices across your projects? If yes/no, why?

This is basic and if they don’t follow any standards at all they’re not a good hire, not as your first or your last.

Following standards is a very simple indication on whether they write clean code or not.

It’s also important for the team’s overall productivity, as using the same naming conventions, folder structure, etc allows team members to work well together.

Making up their own standards is ok, as is the case with development processes it doesn’t matter too much which they prefer.

Advice Going Forward

If you noticed from the questions I posted above, they all pretty much ask of the interviewee’s workflow and the way they think as a programmer, not their actual problem-solving skills.

This is important: problem-solving can always be built up through practice, as is the knowledge about a given tool or language, but workflow and thinking like a programmer takes years to develop and if they don’t have them already, they won’t develop them anytime soon.

For testing actual development skills, I would recommend a practical test in case they pass the first interview.

You should ask a senior programmer whom you know and trust to check on their code, otherwise you’ll be stuck simply checking if it works and that’s not really good enough.

PS: If you have hired a programmer already you should definitely have them interview with you. They should at the very least be able to indicate if the interviewee is better or worse than they are.

This concludes this guide and hopefully you benefit from it.

If you have any questions or concerns please comment below.

Thank you for reading! 🙂 .