Blog (hiring) - Fred Wu's Tech

Tips for Job Interviews as a Junior Software Developer

ifredwu@gmail.com (Fred Wu) — Sun, 27 Sep 2020 05:56:03 +0000

As coding bootcamps such as Coder Academy and General Assembly churn out more and more software developers, and as more and more people start to realise the importance of software, companies these days are facing an increased amount of candidates applying for junior dev roles.

Recently we had to take down our job ad for a junior full stack React and Elixir role only a few days after posting it due to having received about 300 applications. Suffice to say, the competition is fierce at the entry-level end of the software engineer spectrum.

Software is eating the world. - Marc Andreessen

In the past three months alone I’ve had to sit through over a hundred interviews, many of which were for junior roles. Some candidates did really well but unfortunately the vast majority did quite poorly. In this article I am hoping to offer some tips and insights as a seasoned interviewer and hiring manager, to those who might be struggling landing an entry-level software engineer role.

I’ll break the tips into three sections: before an interview, during an interview and after an interview.

Before an Interview

This is arguably the most important stage of your interview - before it happens! Prepare yourself with enough knowledge and confidence in both software development and conversational skills in order to ace the interview and stand out amongst a sea of candidates.

Study Software Engineering Fundamentals

I get it, bootcamps and many online tutorials and courses focus on teaching the practical things to turn code into products. But just like running or even walking without correct postures, it can be incredibly dangerous over time.

My recommendation is to read on the basics of object-oriented programming, functional programming and some design patterns. For instance, build up some basic understanding of how the JavaScript prototype works or how the Ruby object model works can be extremely beneficial in progressing your technical capability on application design and architecture.

Get More Project Experience

Not having any substantial project experience on your CV is a sure way to significantly lower your chance of getting an interview.

Do junior developers really need substantial project experience, you may ask? Abso-fucking-lutely!

Build your own side projects, participate in open source projects, pick up some freelancing work - the choice is yours. These won’t be your most technically accomplished work, but they will help you accumulate experience, and more importantly to demonstrate your capability to your interviewers with real world experience.

Why Software Development?

I want you to put your hand on heart and answer this question honestly. If your answer is more money or FOMO, that’s okay, but be prepared to be disappointed with the reality - if you are not in this field because of your passion for building products or solving problems, you will find this a long and hard slog.

If you are passionate about building software, then let me tell you this - when you are starting your career you will have to give up your work life balance for a bit. That is, if you want to boost your career and progress quickly beyond being a junior developer.

My interest is in the future, because I am going to spend the rest of my life there. - Charles Kettering

Looking back at when I started my software career many moons ago, I never regretted giving up my social life early on in my career: I worked extremely hard, often did many jobs - a day job as a dev, a night job as a dev, freelancing and doing open source work all at the same time. Some would probably frown and say that I had no life, but I choose to believe that I was making sacrifices so I can become good at what I love doing in the shortest amount of time.

Research the Company You Apply For

If you are one of those who spam your CVs to every job opening, please consider changing your tactic. A well written cover letter will not only increase your chance of getting an interview, but also allow you to ask relevant questions during the interview.

Check out the company’s website and any social media pages on LinkedIn, Facebook and Instagram, etc. Do a bit of “stalking” on the people who work in the company, sometimes this will give you some insights into the type of work environment and culture the company has.

Doing enough research is not only for your own good - knowing whether you will enjoy working there should you end up getting a job offer, but also demonstrates your ability to do research and independent thinking to your interviewers.

Read, Listen and Communicate

This one might not be immediately obvious because it’s very high level and somewhat vague, bear with me.

Some people might be deep thinkers but really struggle to get their points across, and to communicate their ideas and thought process in a clear, concise and useful way. My advice is to read blogs, listen to talks and learn from other people on how they communicate. When you read and listen, pay more attention to how sentences are structured and how titbits of information are given.

The most powerful person in the world is the story teller. - Steve Jobs

And don’t forget to practice! Get comfortable talking to others on various topics in software development.

During an Interview

Hopefully the tips given thus far would help you secure an interview. Now it’s show time!

Turn Up On time, Have Equipment Sorted

Whether you are attending an on-location interview, or more likely during Covid, an online interview, make sure you turn up on time!

If it’s an online interview, also make sure you have whatever software needed (Zoom, etc) installed and tested. I’ve had a few occasions where the first five minutes of the interview was spent on the candidate trying to get their mic or speaker working - it’s not a huge deal, but it does show the lack of preparation and organisational skills.

A Smile Goes a Long Way

Understandably, interviewing is stressful. However, remember to put on a smile when you greet your interviewer and when you do small talks. Everything needs a balance of course, when you’re giving technical answers it’s probably not a good idea to smile.

If you know you get uncomfortable talking to strangers or when under pressure - do more practices! If you can’t find a friend or don’t have a partner to practice with, use a mirror!

Learn to Say “No, I don’t know”

When you don’t know something or can’t recall the details of something, just say it. As an interviewer, when I ask you a technical question I can see through your hmms and ahs. A “sorry, I don’t know” is a much better answer than one that doesn’t make sense.

Bonus point: “Sorry I don’t know, but I will look it up after this interview.”

Read Social Cues

This one can be extremely easy or extremely hard depending on your personality. For those who might struggle with reading social cues, try pay more attention to what type of questions you were asked.

If it was an introduction of yourself to kick off the interview, make it more than just two sentences but also under five minutes - this is usually a warm up for you to find your feet and calm your nerve, and for the interviewer to extract any interesting information as a discussion point later. It doesn’t have to be your memoir and you shouldn’t robotically talk through your entire education and work history.

If it was a technical question, always try to time-box it. Don’t drag on and repeat yourself just because you have already answered it quickly and concisely. When in doubt, ask the interviewers whether they have anything in particular they were looking for.

If it was an open ended question, try to explain your thought process as you explain it. As an interviewer, I’d hate to ask an open ended question and get a short yes/no back. At the same time, give interviewers room to interject and ask follow-up questions by pacing yourself.

Don’t Speak Too Fast

Okay, you might be very nervous, or English might not be your first language, so you tend to speak fast to “get through it”.

If that’s the case, work on your speech pattern, make it concious enough that you will recognise it when you speak too fast. If interviewers can’t get your points clearly, they might not always ask you to clarify - because if you kept doing it repeatedly, you would already be written off as a suitable candidate.

Be Humble

I totally understand that in a competitive job market you want to present yourself in the best light. Just be confident and speak the truths.

As someone who’s been doing interviews for years, I really dislike people who overstate their capability either on their CV or during the interview because these are often very obvious. Claiming to be an Elixir expert but not knowing how the supervision tree works is a sure way to score a black mark, for example.

Show Passion and Drive

To counter the point on over-selling yourself, what works better is to show interviewers your willingness and determination to learn. Remember, you are still a junior therefore we don’t expect you to know everything we know.

What we do expect, is your commitment to learning - not by saying it, but by demonstrating it. Remember the earlier tip on getting more project experience?

Ask Questions

Usually towards the end of the interview, we’d ask you if you have any questions. Don’t say “no”.

Doesn’t matter how much research you’ve done on a company, there are always insights someone who’s working at the company can give you. How do they manage the delivery? How do they support learning? What makes them enjoy working at the company?

Use this opportunity to gain insights into why you should be working at this company, and to demonstrate your interests in working at the company to the interviewers too.

After an Interview

After completing an interview, it’s an opportunity to do a little retrospective and do a follow up when necessary.

Close the Knowledge Gap

Don’t over-analyse on what you could have or should have said. Instead, spend your energy on solidifying the topics you couldn’t or didn’t provide good answers for. If you’ve said “don’t know” or “not sure” during the interview, now is your chance to make it “sure”.

Follow Up

If during the interview there have been things mentioned that you could provide links or more information on, be sure to act on it. You never know, maybe the clarification is just what the interviewers needed to help them make a decision.

To all the junior developers out there - enjoy the journey! You are in for an amazing ride, make every second count.

If you enjoyed this article, checkout my other tips articles:

]]>

Tips for Writing a Good CV / Résumé

ifredwu@gmail.com (Fred Wu) — Wed, 20 May 2020 08:59:24 +0000

Due to COVID-19, not many companies are hiring at the moment. The company I work for therefore is in a very fortunate position to still be thinking about growth and hiring.

As a hiring manager for almost a decade now, I’ve personally reviewed thousands of job applications and CVs, and many hiring managers would probably agree, the vast majority of CVs are terrible. Let’s change that!

During COVID-19 where more and more people are either losing jobs or having their work hours cut, we are experiencing an increased amount of applicants to our job ads. I’d say on average I spend about 30 seconds per applicant due to my busy schedule - most hiring managers are busy people, it is therefore crucial for candidates to realise the importance of having a CV that is clear, easy to read and most importantly sells yourself. And if you have a cover letter, which I highly encourage that you do, congratulations you just bought yourself another 30 seconds. ;)

I’m writing this post mostly from my own perspective - as a hiring manager in a tech company in the western culture (we’re based in Australia). Understandably, different cultural backgrounds and regions may have their own conventions, but certainly in Australia and many similar western cultures, there are things that you do and don’t do on a CV, and there are things that may help your CV stand out. Let’s talk about these things.

At the end of this post I will also share a copy of my own CV to help illustrate my points.

30 Seconds? Surely It’s Unfair to the Candidates

Yes, I agree, to think that you are only given 30 seconds for your perhaps carefully crafted CV and cover letter is definitely soul-crushing. But it is unfortunately the reality. I work for a company where I can still do the first round of vetting myself, many large corporations would use algorithms and/or HR people to reject your applications based on keywords and other things.

Knowing the reality and the constraints, there are a few things I’d like to address in the hope of improving your CV and your chance of scoring an interview, and in turn, helping myself and other hiring managers out there to have a better candidate CV screening experience.

Have a Pronounceable Name or Alias

This one surely would raise some eyebrows - you might think that your name is your identity and you should not change it for anyone. True, however, the reality is that a hard-to-pronounce name discourages your profile to be shared and spoken about. Why not add a pronounceable alias if means there’s an increased chance of getting an interview?

For clarity, I personally would never reject a candidate based on their name (or their cultural background for that matter), but I know some hiring managers might, and for some of them, they are NOT doing it on purpose. However, I have on several occasions had to ask a candidate how to correctly pronounce their name.

A Short Blurb on Who You Are

As a hiring manager, I care about who you are as a person - if you can summarise who you are as a professional in a sentence or two, it will help me determine whether you might be a good fit or not.

As an example, here’s a blurb about me:

A passionate and hands-on software executive with two decades of experience and an entrepreneurial mindset.

A long time open source developer who has created and contributed to a few dozens of projects, including Ruby on Rails.

In two sentences, I explained my industry experience as well as my open source contributions - two things that help define who I am as a working professional. It also invites more questions from hiring managers: what kind of things have I done as an entrepreneur; what other open source projects have I contributed to?

Work Rights

Many companies have restrictions or policies around who they can hire based on their residency and visa status. If you are not a resident or are on a particular visa, make it clear in your job application so you don’t end up wasting time for the employer and for yourself.

List Keywords, But Don’t Overdo It

In the tech space it is important to have keywords visible to highlight your skills. If you are a software developer, your tech stacks should be clearly stated in your CV. As a hiring manager, if I am hiring a PHP developer, I expect to see PHP mentioned in your CV. There are of course exceptions, for example when we were hiring Elixir developers I did not expect to see Elixir as a keyword simply due to the supply constraint.

It is a balancing act however - I’ve seen CVs where candidates put 20-50 keywords on their CVs. I’m sorry but unless you are extremely gifted, you cannot possibly be good at all those things. Do not put keywords on your CV simply because you’ve read an article on the subject.

Oh, and unless you’re going for a data entry role, I honestly don’t care about your Excel skills…

Do Not Overstate Your Capability

Similarly, try to avoid overselling your capability. I once interviewed a candidate who claimed to be an “expert” on Ruby. We were actually hiring for a non-Ruby position, but given the candidate’s CV, I questioned him on some advanced Ruby subjects during our interview and he struggled all the way through and was sweating bullets. Suffice to say that he did not get the job.

Be confident, but also be honest and be humble. Lying on your CV to get an interview is a waste of everyone’s time.

Keep Things Short

As I mentioned in the beginning, I spend on average 30 seconds on each CV. Keep things short and easy to read! I really don’t care about how awesome you were in your last dozens of projects - these will get covered during interviews.

On a CV I expect short and concise blurbs on what you did in each role. Also, take recency into account too - if you’ve been working in the industry for a decade or two, what you did 20 years ago really doesn’t matter as much, so save yourself some time and cut things short.

For example, here’s the blurb for my current role:

Leading a department of 25+ engineers to make great child care and education software. As part of the leadership team and reporting to the CEO, helping building and turning the company into a market leader.

And here are the blurbs for my older roles:

Yes, the blurbs for my older roles are left empty intentionally.

Now, again there are exceptions. If something happened a while ago but is interesting and relevant, do tell! For example, here’s the blurb for my oldest “role”:

Built my first ever website using Microsoft FrontPage Express, on a Pentium 166Mhz computer, uploaded via a 33.6kbps modem.

Explain Over-Qualified Titles

There were a few times where a “CTO” or even a “CEO” applied for a developer role. In most cases it wasn’t about over-qualification, but about what the candidate wanted to achieve professionally. So, either in the CV or in the cover letter, explain what you are looking for in your next role, otherwise you run the risk of being assessed as over-qualified.

Spare the Personal Details That Are Too Personal

This is predominantly a culture thing as I’ve seen it from mostly candidates of certain cultural backgrounds. I really don’t care about your age, gender, marital status or favourite sport. These things do not define who you are as a professional - we might talk about your favourite sport and food during the interview but they are irrelevant on your CV.

Space Things Out

Look up CRAP Principles - make sure your CV has enough white spaces and contrast, and has fonts that are readable! Scrolling through walls of text is no fun and is a sure way to get your CV dismissed.

2-4 Pages

This is not scientific, for me personally I prefer to see CVs of 2-4 pages. Use the length as a constraint to cut things down. There were several occasions where I ran into CVs with 10+ pages. I guarantee you, unless a hiring manager is extremely bored, he or she does not have time to read your War and Peace.

PDF Over Word

When possible, submit your CV in PDF format instead of Word format. Now, sometimes if you use a recruiter you’ll be asked to submit your CV in Word format so they can ~~fuck it up~~ add their branding. A PDF formatted CV ensures the correct formatting and layout always get shown to the hiring managers.

Cover Letter

Always attach a cover letter when possible, but keep it short too. Given the amount of CVs a hiring manager needs to go through, having a crafted cover letter is another way to grab their attention and increase your chance of getting an interview.

Don’t repeat the same information in the cover letter though. Your CV is about the facts of your experiences, your cover letter should be about your thoughts on why the company should hire you. Focus on the value you can bring to the table.

Find A Referral

When possible, find someone who can refer you. A referral gets preferential treatment during the CV screening stage and does not suffer from the same 30-second fate.

Pleasing Design

This one is a “nice-to-have”: if your CV is really well designed, you would earn another 30 seconds of my attention. ;)

These are the main points, hopefully they are helpful. To help illustrate, here is a copy of my own CV, with contact details removed.

If you enjoyed this article, checkout my other tips articles:

]]>

On Hiring: Trial Week - Yay or Nay?

ifredwu@gmail.com (Fred Wu) — Tue, 29 Oct 2013 12:09:00 +0000

Today a blog post titled “Trial Week: Our Hiring Secret“ has made to the Hacker News homepage. I naively tweeted my dislike and now I feel obligated to share my thoughts in a more meaningful and constructive way.

First of all, congratulations to the Weebly team, as this trial week strategy is clearly working very well for them.

I, on the other hand, am against using a trial week for vetting candidates, and I am going to share my thoughts.

Let this serve as a reminder to the rest of us: every organisation and team is different, so think carefully before committing to a given strategy.

One Week is a Major Commitment for the Candidate

In Australia, a full time employee typically gets four weeks of annual leave, with one or two weeks of which used up for the Christmas / New year down time. We are looking at asking candidates to spend 33-50% of their vacation time to commit to a trial week for one company - a terrible ROI (Return On Investment) from the candidate’s perspective if you ask me.

Candidates who are currently employed, with multiple offers from other organisations are more likely to skip the trial week - from experience, this is often the higher quality candidate pool.

Side Effects

Increases the likelihood of burnout due to the reduced vacation time
Shrinks the candidate pool
Misses top talents who are unable to make the one-week commitment
As a result, the overall quality of the candidate pool drops
Paints an image of “not-caring (enough) about the employee’s well being”

Of course, since the trial week is paid for, the employee could always take unpaid leave from their current employer.

Side Effect

Raises alarm bells at current workplace since one week of unpaid leave is significant

One Week is a Major Commitment for the Team

Given the trial only lasts a week - we better make it count! That means one or more current developers need to be assigned to take care of the trial developer - pairing and walking through existing systems, etc. This is assuming we are going to act responsibly, and not simply just direct the trial developers to their desks and ask them to “go for it”.

Side Effects

Higher pressure for the team
More difficult to act on other priority tasks

Developer Productivity Curve (One Week is Not Enough)

From my experience of on-boarding new developers, it typically takes 4-8 weeks for a developer to become productive and effective in a new work environment.

According to Weebly, candidates are assigned with a project that is small enough to do in a week, but still resembles what the candidate would be doing if hired. It sounds great if it works, but for many organisations this is unfeasible, for instance:

There is no small projects to assign, unless invented
Navigating documentation and source code would take days, if not weeks

Either way, with one week of trial, the candidate is unlikely to have enough time to contribute as well as to be integrated into the team culture.

Side Effects

Higher chance of misjudging the candidate’s ability and productivity
Significantly higher chance of creating solutions misaligned with the team and/or the organisation
Higher maintenance cost should the team decides to keep the solutions created

66% Hire Rate Suggests Deeper Hiring Issue

Weebly at the end of their blog post writes:

Our hire rate out of trial week is around 66%, which feels like the right level.

I respectfully disagree. A 66% hire rate from the trial week is a 34% failure rate on the pre-trial week recruitment process, and this is significant.

Which brings us to…

More Effective Ways to Vet a Candidate

Where I work, we have a simple, three-step recruitment process:

Complete a small and fun code challenge, in your own time and with your own pace. The code challenge usually takes 2-4 hours to complete.
Invited to our office to chat with our developers and founders, optionally done via video chat. This usually takes an hour or so.
Pairing session, usually takes 30-60min.

Step 2 and 3 are sometimes swapped. And we also check out the candidate’s Github account if available, and their past projects if public.

In the code challenge we vet the candidate’s problem-solving ability, software design sense, code quality, code style and ethics (it’s easy to tell whether they cheated).

During the chat we vet the candidate’s project experience, depth of knowledge, breadth of knowledge, communication skill and culture fit.

In the pairing session we vet the candidate’s development practice, thought process and the ability to articulate.

By the end of the three steps we are usually pretty confident on +1 or -1 to hire the candidate. If we aren’t, it’s a -1.

But hold on, didn’t I mention one week is not enough for a candidate to be productive and effective? Yes! And that’s why most places have a three-month probation.

The difference between the long probation period and the short trial period, is not only in duration, but more importantly in commitment. In my opinion, only when both parties are committed can you achieve great result.

So, let’s hear your say, what do you think? :)

Poll: Trial Week, Yay or Nay?

]]>

On Hiring: Use Kanban for Managing Candidates and the Hiring Process

ifredwu@gmail.com (Fred Wu) — Tue, 21 Feb 2012 04:20:00 +0000

Hiring is usually a long and difficult process - in order to streamline and simply it, I use Kanban to manage the whole process. I believe, hiring should be as lean and agile as our development process.

My Kanban board for hiring (we just started hiring at SitePoint!):

Using a Kanban board offers a number of advantages:

a clear picture of the candidates with their feedback from code tests and interviews
a straightforward view of where a candidate is at in the hiring process
limited number of candidates in some stages to prevent chaos
visual reminders to get in touch with the candidates, it’s always a good idea to keep them in the loop
a tight WIP limit for shortlisted candidates, there’s no point to shortlist too many candidates

What do you think?

]]>

On Hiring: How To Be a Non-Technical Co-Founder

ifredwu@gmail.com (Fred Wu) — Sat, 28 Jan 2012 06:16:00 +0000

If you are looking at hiring developers, check out my article on this subject.

The goal or the dream of working on your own startup is always full of excitement. And apart from some rare cases such as Dropbox, you probably need one or more co-founders to work with you on The Next Big Thing ™.

Problem is, how do you (as a non-technical co-founder) find us? Or more specifically, how do you talk us into working with you instead of some other billion-dollar ideas?

To answer this question, we need to first ask, is there a billion-dollar idea? The short answer is: NO.

Idea is worthless.

Well, that’s not entirely true. I believe - idea, by itself, is worthless.

You will be surprised by the number of people contacting us and wanting to build a better Paypal or a better Amazon, without a concrete plan.

A more worthwhile idea should contain not only the end goal of the project, but also a plan to reach the goal. What should we ship in the Minimal Viable Product? What are our marketing channels? What metrics should we look at? How do we use social media to our advantage? etc, etc.

We Are Not Just Wozniak, Are You Like Steve Jobs?

Apple is pretty much started by Wozniak as the technical co-founder and Steve Jobs as the idea/business co-founder.

Let’s think about this for a second.

Steve Jobs did not just have ideas. Very early on, he persuaded Wozniak to produce and sell Apple I so they have some capital. Jobs was building the foundation. Without the foundation, there will be no failure or success to come.

On the other hand, Wozniak had no intention to become an entrepreneur, he was happy to stay as an engineer even after the early Apple success. Nowadays though, most of us techies are much more ambitious than that.

Ideally, as the technical co-founder, I would be doing most of Wozniak’s work, and both you and I would be doing Steve Job’s work.

Drawing from my personal experience, as a technical person, there are a few key attributes I look for in a co-founder (technical or otherwise).

Technical Ability

“Excuse me? Aren’t you the technical co-founder? Why are you looking for my technical ability?” You ask.

That is right. Even if you are not a developer by trade, having a certain degree of understanding of technologies is still crucial to most modern, web-based projects.

There has never been a better time to start learning to code. Why not give CodeYear and Khan Academy a try?

We all learnt physics and chemistry in high school even though most of us don’t require the knowledge in our day to day life. Let’s treat coding the same. Learn how to code will not only give you insights to how we solve problems, but will also close the communication gap between you and your technical co-founder.

Obsession

Wozniak is obsessed with electrical engineering and gadgets, Steve Jobs was obsessed with computer typefaces, good user experience and beautiful hardware.

What are you obsessed with?

Only when you are obsessed with something, can you answer questions like “what annoys you so much?”

As I wrote in an ealier article:

Inventions and innovations aren’t born out of happiness, they are born out of frustration, anger and sometimes, curiosity.

Curiosity

In web-based projects, it is surprisingly easy to have “what if …?” scenarios. Not sure which sign up form will have a higher conversion rate? Easy, just make two or more of them and run A/B tests.

Sometimes, as developers, we are so in the zone that we would keep on building stuff the way we envisioned. You will need to step in, pull us out, and say “hey, have you thought about …? What if …?”

Flickr as it is today would never have existed if the founders didn’t raise the question of “hey, how about doing just the photo uploading and sharing features?”

High Expectation

“This is shit!” “We can’t ship this!” If the product stinks, say so, and find ways to improve it. An MVP should always be half-polished, not half-arsed.

The original iPhone was shipped without 3rd party native apps support, or multi-tasking - it wasn’t ideal, but they didn’t effect the core user experience. Now look at PlayBook, it has the features most Android devices have, but the core user experience is so bad that the product never took off. If someone at RIM’s top management had the same obsession on user experience as Steve Job’s, PlayBook would never have shipped in such a bad shape.

Passion

Are you in this for the money? Or for something else? Wealth is rarely a good motivation for creating great products.

“It can potentially generate massive revenue and profit” is a big red flag to me when someone pitches their projects.

These are the key attributes I look for. Things like people connections and experience are also important but not essential. What about you? Do you look for any particular attributes in your potential co-founder(s)?

]]>

On Hiring: How Not to Annoy Developers

ifredwu@gmail.com (Fred Wu) — Thu, 26 Jan 2012 05:42:00 +0000

If you are looking at finding technical co-founders, check out my article on this subject.

In recent years developers become hotter and hotter - especially the good ones - they are hard to find, and they have plenty of employment options to choose from.

Some companies (or individuals who are seeking freelancers) go the extra miles to impress developers with attractive salary/rate and perks, which is nice. But surprisingly, many companies and individuals seem to have a habit of keep doing things that will annoy developers.

Over the years, I have personally encountered many situations that annoyed me as a developer. If you are looking for developers, here are a few things that I think you should be aware of.

Budget Gap

Find out what the developer’s salary/rate expectation is, there is no point if the developer is looking for $120k when you could only afford $80k. It’s absurd to think that you might be able to persuade them with a significant pay cut.

Timing of Hiring

Don’t advertise the position until you are fully ready to hire. Put a job ad up then go on holidays immediately after is a bizarre thing to do.

Recruiters

If you use recruitment agencies, please make sure you know them well enough and if not, do your fair share of research on them. Bad recruitment practices will cost you and damage your reputation. I once dealt with a recruiter who did not even bother to pass along my response to the offer back to the employer.

Technical Assessment

Unless you are Google or Facebook who have a huge pool of candidates to filter, it is probably a bad idea to test your candidate’s technical skills with brainfuck coding questions on paper or on whiteboards.

I am in favour of having candidates to do one or two coding tests (on their own, not during the interview) that will demonstrate their technical abilities without spending too much time or be under interview pressure. If a question is going to take a candidate more than a couple of hours to do, it is too much.

The technical questions should focus on the logic behind a candidate’s solutions, not what functions or libraries a candidate may or may not remember from the API documentation.

Also, pair programming is an excellent way for both parties to get a sense of what it is like to work together.

Communication Channel

This applies more to hiring remote workers and freelancers. If you are pitching your project to a developer, please at the very least write a sentence or two to explain what your project is.

“Would you have time to have a quick chat?” is simply not good enough - good developers are all very busy and are likely to have many projects or potential projects to work on. Even if the developers have the time to chat to you (without knowing what your project is), it is still better to have the conversation via emails so the developers can keep track of things.

Developer Relationship

Recently there is a company in Melbourne who burnt a huge bridge with some of the most respected and talented local developers. Now they are having trouble finding talents even with inflated salary/rate. Moral of the story is, please always treat developers properly.

So, these are the few things I can think of for now. How about you? I would love to hear your thoughts and stories on hiring developers.

Hacker News comments here.

]]>