A hiring process for the 21st century

Approximately 40 minutes reading time

Table of Contents

Introduction

↩︎

This is a bold, modern, egalitarian process to hire software engineers.

In an effort to , over time,

What Facebook, Google, Amazon are looking for is not necessarily what you are looking for.

Companies are asking for more in their hiring process.

Raising the bar does not mean gatekeeping.

Relying on knowledge instead of experience. Losing out on good candidates in fear of getting bad ones.

Problem Numbers on every stage.

Who is this for

Your goal is to look for a person to join your team and do so in good faith. Be objective when and where is applicable. Be respectful of a person’s time. Show the real you. Don’t have an artificial hiring process that does not reflect how you operate. It does not do your company any justice. Draw people in by showing them how you think of software development and what work life is actually like. Instead of looking for a culture fit, open your eyes to the unique experience an individual brings and what it’s like to work together.

Doing so, will take you less time and cost less overall. It is a humane process and it’s good business. It will bring in more applications and increase your chances of a good hire. It’s important to start with the assumption that every individual has the skills, experience and expertise to do the job they are applying for. The hiring process has a higher chance of giving you great results when you are in this mindset.

Time spent, interest shown, effort put is the currency exchanging hands between you and the individual during the hiring process. This exchange should happen in batches along the way. Every time you ask for something make sure you have made an equal contribution in time, interest and effort. Early in the process you should give a little and ask for a little. Making small and fair bets instead of making demands, builds trust, is efficient and economical. As you progress, you should raise the bet.

Know the limitations of the process. It will not magically increase your brand awareness overnight. It is not enough to attract top talent. It will not improve your churn rate. You still have to play by your strengths. Your strengths as a startup are different to that of an established business. It’s safe to assume that anyone looking to join a startup, job security is not their top priority.

I have used this process in the past to hire people. It is far from perfect but it’s pretty good. In one case, months after the hiring process, I run across a junior developer who hadn’t made it. They told me how they have become a better developer since then because of what they learned during the hiring process. In another case, I had a senior developer telling me how this was an experience unlike any other that had come before and how much they had enjoyed it.

These stories are anecdotes and reveal half the truth. The truth only lies within your company. The process will not suddenly make you empathetic or fearless. It will not eliminate bias. However, it will reveal traits and make you think about what is important and what is not when looking to hire someone. Personally, as an individual looking to join a team, I have found it to be more pleasant by far than any other hiring process in the vast majority.

Not About

Blind CV.

There are so many more things that I didn’t touch upon. Like having a diverse team for the hiring process to using round tables that better capture a collaborative environment. As opposed to sitting across a table.

Accessibility and mobility.

Check list

↩︎

1. You have a job description that describes the actual tasks the person will have to perform.
2. You make it clear whether you are looking for a Junior or a Senior engineer.
3. You offer examples of work and duties.
4. You have a list of requirements for the role.
5. You put the paying salary in the job description.
6. You make the hiring process public.
7. You have assigned a dedicated person who is part of the team and a personal guide for the duration of the hiring process.
8. You can objectively measure a person’s technical knowledge for the role in a fair, transparent way that does not make them feel cheated.
9. You communicate to the individual how their technical knowledge is assessed.
10. You make a commitment clear on what it will take for the person to meet the team.
11. Any work assignment is well defined, self contained and complete with requirements explicitly stated.
12. You make everyone in the team available to meet on the day.
13. You provide an agenda for the meeting, including who the individual will be meeting with.
14. You communicate to the individual what is expected or not expected of them on the day of the meeting.
15. You demonstrate what it’s like working together.

Advertise for the role

↩︎

Your responsibility is to write the job description. Their responsibility is to read it.

We are past the point where job descriptions were a good indication for the role. This is unfortunate and does not help either side. We have to work towards overcoming it with responsible writing that is grounded in reality.

You should write a job description in a way that carries weight. Write down the skills, experience and expertise people must have. Don’t muddy the waters by adding “nice to have” and “extra points”. Remove the superfluous. To help you decide what goes into the job description you should ask yourself a question. Will you reject a candidate upon receiving their CV that does not have the skill, experience or expertise for the role? If the answer is yes, make it a must.

As an example, this is a job description calling out to a Senior iOS developer.

DESCRIPTION

• Your task is to build a native app, using Swift that is unit tested, localised, designed to support multiple screen sizes and communicates over HTTP with a server.
• You will work closely with the mobile team, at the time consisting of a developer, a designer, a project manager and a product owner.
• You are expected to work on site but we do understand that there might be days you have to work from home.
• You must be able to perform the following work and duties, as an example, with very little guidance.

Describe the actual task(s) and what you expect a person will be working on. These are all part of the job. Be specific. Be transparent. It will save you time and effort evaluating applications. If you expect them to know how to write an app in the Swift language, say it. If you expect them to write tests, say it. To know how to support multiple screens sizes, say it. These are skills you expect them to have and must have. Make them clear.

Give people a sense of how they fit in and who they will be working with. Be specific. How many other developers. Is this a one man team? Who else is involved? How big is the team. People want to know the team they will be working with! It helps them build a picture. It gives them orientation and a sense of place.

Compare the above description to that of a Junior one.

DESCRIPTION

• Your task is to support the development of a native app using Swift that is unit tested, localised, designed to support multiple screen sizes and communicates over HTTP with a server.
• You will work closely with the mobile team, at the time consisting of a developer, a designer, a project manager and a product owner.
• You are expected to work on site but we do understand that there might be days you have to work from home.
• You will have a senior member assigned to you who will guide you and support you.

Notice how the role is a support one. You don’t expect a junior developer to build an app on their own. You should know and say whether you need a senior or a junior. It’s even more important to let a junior know how they will be supported. Will they have a mentor? You should know this, have a plan and make it explicit. It’s not enough to say or assume the team will provide support. It is either the responsibility of someone or nobody.

Give examples of work and duties on the job. Again, these should be specific. Neither abstract nor generalised. It communicates that you have a process, a backlog, a roadmap. It helps people familiarise and anticipate. These examples should be indicative of what you expect people to be working on or what your team has worked on in the past.

EXAMPLE WORK AND DUTIES

• Write an API to authenticate using a challenge–response protocol over HTTP.
• Implement a custom view that groups a list of transactions by date.
• Discuss what’s an appropriate design to satisfy a business requirement following the iOS Human Interface Guidelines.
• Participate in planning, make estimates, open pull requests, do code reviews and have retrospectives.
• Build, test and release code using Xcode bots.

Again, notice the differences compared to that of a junior role.

EXAMPLE WORK AND DUTIES

• Use a networking library to make an HTTP request, handle network errors, parse a JSON response, create a model and present it in a view.
• Implement an interface design using classes provided by UIKit or your team
• Discuss what UIKit classes are appropriate to satisfy a business requirement.
• Participate in planning, make estimates, open pull requests, do code reviews and have retrospectives.
• Build, test and release code using Xcode bots.

What are the requirements applicable to the role? Provide a nice overview and go beyond the technical responsibilities. Do you expect people to do code reviews? Pair programming? Communicate it. It paints a picture of what it’s like to work alongside the team and it helps people know that the team could be right for them.

REQUIREMENTS

• Have designed, developed and maintained at least 1 app, built natively for iOS with little supervision and direction.
• Have written an app that needs to communicate with a server over HTTP.
• Know how to build an app that supports the screen size of an iPhone 5S up to that of an iPhone 12 Pro Max.
• Know how to use Instruments to profile an app for memory, cpu usage and identify patterns that are potentially problematic.
• Writing unit tests is part of your workflow.
• Know how to provide estimates.
• You are comfortable doing code reviews.
• You are keen on writing apps using Swift.

For the junior equivalent, notice the re-iteration of the support function as well as the omission of the requirement to “provide estimates” and to “know how to use Instruments” while the rest remain the same:

REQUIREMENTS

• Have worked in a team that designed, developed and maintained at least 1 app, built natively for iOS.
• Have written an app that needs to communicate with a server over HTTP.
• Know how to build an app that supports the screen size of an iPhone 5S up to that of an iPhone 12 Pro Max.
• Writing unit tests is part of your workflow.
• You are comfortable doing code reviews.
• You are keen on writing apps using Swift.

Finally the benefits with first and foremost the salary. Just say how much you are paying for the role. You should know. You should have a hiring budget. Don’t ask people how much they earn in their current job. Their current salary is out of date and does not fully represent the skills, experience and what they have achieved since they were last hired.

Don’t try to shortchange people. You are looking to hire a person to join your company so pay them a good salary. You have your reservations communicating that in public? Then make sure to communicate that on your first call. It is a waste of time to go through the hiring process only to realise what you pay and what a person expects to get paid are not even in the same ballpark. Be upfront.

BENEFITS

• Annual Gross Salary of ΧΧΧ payable on the 20th of each month.
• Stock option of XXX over a 4 year vesting period with 1 year cliff.
• Working Week: 40h.
• 25 days of holiday + 8 days of public holidays.
• Medical Insurance: 50% cover + extending coverage for spouse/partner/family.
• Pension Plan: 5% + Death/illness/disability benefit.
• Sickness Injury Benefit: 18 weeks full pay. (over 3 years 26 weeks full pay + 26 weeks half pay).
• Dental Insurance.

Stop asking people for their GitHub profile, open-source contributions, apps on the App Store, portfolios etc. Not every piece of work can be made publicly available. Not everyone has the time to contribute to open-source or is interested in a GitHub profile. They want to spend time with their partner, friends, kids. They don’t have the privilege nor can afford the luxury. They need to look after their elderly parents. They work on white label apps that never made it to the market. The flashy app of the startup the used to work is now defunct.

Stop requiring people to tell you why they want to work for you. People have plenty of reasons to resign but joining your company is not on the top of that list. They are proud of their work and believe they can make a contribution in their role as a software engineer. Don’t expect people to know your team, company or product. Unless you are Apple. Then people want to work for you because you are Apple. The world is vast and chances are they have not come across you before. Don’t ask them to study and know your company’s mission, values, product, market, clients. Don’t ask them to share stories, write a paragraph on a technical decision they where involved in, give you examples of their work etc. You don’t need them to make a decision at this stage.

The person has read your job description and they think they are a good fit for the role. You have a match. Their CV is the proof for now. By sending a CV, they have expressed an interest in working for you. They have now clicked through your advertisement. They don’t necessarily want to work for you yet. You have spent time writing a job description. They have spent time writing a CV. Given the job description, you should know whether a CV is a good match for the role at a glance. Asking people to spend more time and put more effort in their application at this stage is repugnant. That’s what the hiring process is for.

Ideally you should strive to make your hiring process public. If you don’t feel comfortable making it public, at the very least communicate it when you get in touch next. Your hiring process should not be a secret. The unknown is nerve wracking. By letting people know what the hiring process entails, you make it inviting and you put people at ease. You want people to feel at ease.

Get in touch

↩︎

A person has now expressed an interest in working for your company and is currently considering joining the team. Your first order of business is to introduce yourself. Not HR but you or someone from the hiring team. Your responsibility is to take them through the entirety of the hiring process. From this point onward, you are the face of the company. As such, your interactions cast light on the company. Good or bad. You are the first person they get to hear from and thus you should be the last.

This is the moment where you make a good first impression for the team. You demonstrate that you care enough by being present in that first interaction. You have spent some time looking into the person’s profile. Send a message and arrange for a call. Introduce yourself, let them know what the call is about and how long it will last.

This is a great opportunity to explain the hiring process if you haven’t done so publicly.

You need to come prepared and have answers to questions like these:

• What is the salary for this role?
• Do you offer sponsorship for VISA?
• Do you help with relocation?
• When do you expect me to start?

Ideally you should answer them in the job description. If not, now is the time.

You can use this early stage to set the hiring bar. That bar should measure, objectively, whether the individual possesses enough technical knowledge and will not feel handicapped as part of the team. This goes both ways. For you to make sure the person coming in has a certain level of technical knowledge that you know it is required or you expect for the role. For the individual to know what is expected of them and to feel comfortable knowing they can do the job. Make sure to communicate that intent clearly. One way to do it is to ask a series of technical questions.

To be clear. These questions are meant to be answered briefly, be complete and precise enough to demonstrate basic understanding. They are not in depth, not tricky, not to have a debate and definitely don’t prove much on senior status. - We need to raise the bar on software development

The 40 questions in the post above can take anywhere between 25’ and 40’ minutes to answer. This can feel intimidating at first. Recognise, acknowledge and communicate it. It gives people comfort and helps them relax. While asking the questions, share progress, encourage and support.

You should make clear to the individual how their technical knowledge is assessed and what is the bar they need to clear. In this case, to answer most questions correctly. Do you expect 51% of the questions to be answered correctly? 75%? 90%? The level that you set the bar at, is for you and the team to decide and may change over time. Including what the questions are. If you are looking for experts, then make them specific to the subject matter at hand.

The technical questions should aim to pinpoint the level of skills, knowledge and experience an individual has. You should be able to tell whether the individual can merely write code and use the tools or can explain how everything works under the hood. In simplistic terms, are they a coder or a software engineer? This will force you to think who you want for the role, regardless of seniority. It will also help you and the individual understand what’s required for the role. The questions you ask and answers you expect should make that obvious.

A list of technical questions is a small bet and makes this stage easy to understand, straight forward and reasonable enough to come to an agreement. If people fail to pass this stage, it should be obvious to them why without the need to provide much feedback or feel they’ve been mistreated or cheated.

Don’t automate the questions in order to save time. You want to hire someone. Get on a call, talk to them and get to know them. Your presence is important as it demonstrates you value their time by spending yours with them. With the questions above, you also get a feel first hand about their personality and ability to communicate effectively as you become familiar.

Don’t send an automated email in response to receiving a CV that asks people for more. That person has just expressed an interest in knowing more about your company and you make them jump through hoops.

Don’t leave time for questions till the very end of the call only to turn around and say “I have 5 minutes left for questions”. It is rude. A person is showing respect to your process they have little control over. You should at least respect their time taking part in that process in equal measure. It helps if you don’t schedule meetings back to back. Leave ample time for the individual to ask any questions they have.

Don’t be distracted. Don’t be on Slack talking to the rest of the team. Don’t check your phone. If you need to direct your attention to take notes, let the person know that’s why you are typing away.

Make a commitment

↩︎

You are now at a stage where you know the person has the required level of technical knowledge to join your team and they know what to expect. The next step is to make a commitment to meet the team. The conditions under which the commitment is made should be clear to both. At this stage, you should ask people for any prior work they would like to share. This acknowledgement of previous work, relinquishes control you have in return for nurturing trust, treating a person as equal and allowing them play an active role. It’s an invitation to showcase their skills and take pride in their work. The work could be open-source code they have made public, an app they have worked on, a side project, even code they have sitting on their personal computer they have never shared before.

If they don’t have anything to share, ask them whether they want to work on something they can decide or they would like for you to come up with a piece of work. Out of respect and in recognition of the effort they will put in that work, you make a promise to meet. You must fulfil that promise. As soon as you have the work, they get to meet you and the team. This should not be treated as a test to assess technical knowledge. Instead, this work will lead, in part, to a discussion you will have when you meet. Regardless of whether the work is aimed for a junior or a senior, the discussion will be mostly around architecture, design decisions, thought process, technical challenges.

This isn’t about matching your expectations on how things should be done. Not matching your expectations should not be a reason for rejection, it should create room for discussion. To treat it otherwise would violate the trust placed and openness shown by the person sharing their work. This isn’t a work review. Make the intent clear. You should think of this work as a precursor to your meeting. Work that would otherwise take place during your meeting. By having the work done outside the meeting, you afford people the space to not have someone looking over their shoulder. This is work a person will do in their home, with their setup, outside of the conditions that tend to occur during an “interview”. You want that to avoid judgement and keep the focus on the work itself.

If people opt in to have you give them some work to do instead, the work should not take more than an hour or two. If the role warrants more substantial work, that will take more than a couple of hours or days even, pay them for their time. Not a single feature exists that can be done in 1 to 2 hours. Asking people to build an app, however small, will take more than a couple of hours. The work can be domain specific if you are looking for experts.

In the case of substantial work, make sure it is bounded, well defined, self contained and complete. Make sure the requirements are explicitly stated. Anything else is out of scope. An omission in the work provided by the individual that falls outside the requirements stated should not be ground for rejection. The bigger the problem space you create, the greater the invitation for biases, assumptions and fear to kick in. Don’t ask people to spend 3 hours on a work assignment when clearly this is not possible. Not only it makes you and your team look bad, it is confusing and puts unnecessary and artificial constraints.

Don’t expect anything outside the requirements you have provided. This shouldn’t feel like a GOTCHA or a minefield. The work done is not necessarily indicative of work they would do within your company. Don’t expect test coverage when you don’t ask for tests. Don’t expect someone to write a README when you didn’t ask for one. Don’t expect someone to use lint on a sample project. You do yourself and your team a disservice to reject a person on these grounds. If you find yourself having doubts after seeing the work, address them when they come in to meet the team. The work should leave ample room for discussion.

Here is an example of work as a coding exercise:

CODING EXERCISE
Given a list of transactions, implement a UITableView that groups these transactions by date, ordered descending.

Each group of transactions should be shown as a UITableView section. The title of each section should be the month the transactions fall under.

You can find a JSON with the transactions under ’transactions.json’. Use the sample code to parse the given JSON.

In the case above, the JSON with the list of transactions is provided. The code to parse the JSON to a list of transactions is provided. Wording is important and the clue is in the description. “Given a list of transactions, implement a UITableView that groups these transactions by date, ordered descending.” The focus of the coding exercise depends on what the emphasis for the role is and can vary. Other examples could be to implement a custom UI, networking code, an SDK design. Each of them is perfectly valid as long as you ensure it is bounded, well defined, self contained and complete.

Don’t ask people to use a 3rd party service which forces them to spend time becoming familiar with. On top of doing the work you have asked, they now have to deal with poor documentation, discover implementation details, deal with rate limits, access, downtime etc. This is punishing, leads to frustration and is irrelevant in the discussion you will have later.

Don’t ask for or give a deadline. Let people take their time and come back to you on their own time as soon as they are ready. If your hiring process has a hiring window or is time constrained for business reasons then communicate the deadline in that context. Ultimately, how long it takes isn’t indicative of anything and irrelevant in the discussion you will have later.

Don’t artificially create a process that looks for technical culture fit. This will lead to a monoculture and create space for your biases to kick in. Insisting on conformity neither makes the work fair nor is guaranteed to hold everyone up to the same standard. Quite the opposite. Using a standardised work assignment that you use to assess people’s skills, experience and expertise carries a greater risk for your biases to trigger and your expectations of what’s acceptable to accrue over time. Instead you should make sure you keep everyone up to the same standards and your assessment is fair, irrespective of the work.

This is indeed harder and expects you to have a certain level of understanding, insight and dedication but you will reap the benefits of a less biased, kind, considerate, respectful process that leads to a more engineering diverse team.

Meet

↩︎

It is now time to meet in person. This is an opportunity to get to know each other both as individuals and professionals. The format should be conversational, explorational in an effort to become familiar, understand where you are both coming from and be forthcoming in what you are looking for. You should aim to clarify and confirm the work and duties for the role as well as to gauge how you work together.

Ideally you want everyone in the team to be present on the day. If a team is too big, make sure there is at least one representative for each role. Not just developers. The product owner/manager, the designer, a business analyst. This is the team that the person will be part of and interact on a regular basis. Not everyone needs to be available for the whole duration of the meeting but they should be there when required.

Send a message to let the person know how long the meeting will last and give an agenda. A good practice would be to break it down to 45-50 minute sessions to allow for 10-15 minute breaks in between. It allows people to take bathroom breaks, stretch their legs, clear their head and gives you time to coordinate with your team members. Here is an outline of what an agenda can be like. Make sure to include the people who will be present in every session and highlight their roles. At this stage of the hiring process you can have someone from HR take part.

AGENDA
This meeting will last between 09:00 and 13:00. Please be there at least 15 minutes prior.

• 09:00 - 09:45 Talk about the work you shared/did.
• 10:00 - 10:45 Learn more about your past work experience.
• 11:00 - 11:45 Discuss the requirements for the role.
• 12:00 - 12:45 What it’s like working together.

Give the person a heads up of what is expected or not expected of them, e.g. no dress code. Ask them if they have any needs or requirements that you need to cater for. Ask them if they want to use their laptop to showcase their work. This breakdown and communication makes you look organised, shows you are well prepared and have a clear structure. Structure gives people a sense of place and identity in the meeting.

You need to be present in every session. You have been the public face, a guide to the hiring process thus you should act like an anchor that provides stability and confidence in the uncertain situation ahead. You have a guest in-house therefore you should be a courteous host. Welcome people as they arrive, thank them for taking the time to come in and spend their morning with you. Offer them water to drink. Do not just leave them alone in a room, waiting, without any acknowledgment or a heads up. It can be nerve wracking.

Talk about the work the individual has shared/did.

Allow for the individual to take the lead, starting with the work they shared or did for you which is what lead to this meeting. Give them the space and time to talk about it. Don’t make people feel uncomfortable by making snarky remarks or by rolling your eyes. This is the time to ask questions and put to rest any doubts you may have about the work they did. Do it with an inquisitive mind. You can talk as little or as much about the work. Just make sure the individual is given enough time to talk about it and are happy to move on.

You can also use this opportunity to discuss a range of related topics, not hypotheticals, that you and the team have had debates on in the past or still have. A few examples:

• What do you think of 80% test coverage?
• In order of importance, how would you order the following: documentation, clean code, testing.
• How do you deliver software to your product owner or to a customer?
• Do a code review of this sample code.
• Given a requirement, when and how do you know your work as a software engineer is done?

Learn more about the individual’s past work experience.

This is an opportunity to go through the CV and talk about past work experience. This includes roles and responsibilities, team structure, work relationships and a learning experience on what people enjoy and what they don’t. Share what it’s like to work within the team and the wider organisation. Be honest and forthcoming as it will save you both time and reveal any major disagreements. It also helps people open up and creates a space where people can be candid.

As an example, if the individual has a background in organisations with a lot of structure, where most things are already figured out, it might be frustrating to deal with your company that has a more ad-hoc style of doing business. This should be an exercise on finding the nuances, a discussion to narrow down the work details and zero in on a fit as described on the job description and hinted at the work and duties section.

Requirements for the role.

You should reinforce the requirements for the role and what is expected of them. Include details of how the individual fits within the team and the larger organisation. Describe what a typical day looks like, what a work week looks like.

Now is the chance to touch on things you have described in the advertisement for the role; e.g. unit tests, estimates, code reviews and pull requests. Share how you practice software development and have a discussion on the overarching process. That should lead into a broad discussion around what it’s like working together.

What it’s like working together.

This should mimic a real world scenario. As an example, how you go on about implementing a user requirement. You should treat this as if this was an actual use case.

What’s like to work together.

Have the product owner kick off the discussion with a requirement. Have the designer work with the individual to produce a wireframe that captures the requirement. As a team discuss a potential implementation.

Encourage people to create a collaborative environment.

Don’t be faceless. Don’t make people feel uncomftable. Not everyone feels comfortable talking about their achievements, strengths and weaknesses.

You want people to succeed, support an individual to be themselves instead of trying to fit them into a box that will lead to failure.

have an open debate

• You are given an app to evaluate. You find that is uses too much memory, consumes too much CPU and has very little test coverage. You have to make a presentation to the CEO who has very little technical knowledge.

Don’t make this an interrogation by asking rapid fire questions. People have enough stress going through an interview process. Seeing how they people react under pressure is undignified and not a requirement for the role. Leave room for discussion, take pauses and encourage a conversational style.

Don’t expect from an individual to come up with responses. Especially when you can’t live up. Formulaic.

Don’t be full of yourself. Being a smart-ass

S

Software engineering is a creative profession, it requires pacing and clear thinking.

When people want to avoid having a conflict, people tend to be agreeable. During a hiring process you might find that this is more common as people want to see it through.

You might find that people stay silent during a debate. Don’t mistake silence for junior status. It might be a sign that a person fails to engage and can’t have a good debate.

Decision

↩︎

Do you see yourself working alongside the individual? Yes / No Do you have any main concerns?

Make sure the decision is on the public record and visible for everyone in the team to see.

What might look off to one, might be reasonable for another.

Had a guy that I was frank and told him I don’t believe he will enjoy working with us. He agreed and valued the feedback. I’m sure he was let down and disheartened but at least he didn’t waste any more time.

Ideally the whole team can come to a consensus. Make a decision that involves the team.

Tie break? Simple majority? Unanimous?

Limitations

↩︎

Questions are meant to be objective but in practice they are not. Unless you expect people to hit every nail on the head, they will be paraphrasing, use their own terminology, . Of course a well verse, solid grasp candidate will tell you exactly what you want to hear but unless you want to lose out on a number of candidates, you should be prepared to have some leeway. The main thing is your biases that will kick in.

For all, it still takes considerable time and effort for your team and the individual.

You should already be looking for the way forward.

People tend to be agreeable.

Look at Apple and their developer relations. They build it over time. Commitment honesty.

One way would be to train your developers and create a pool.

The other way would be to find a way to be involved. One model is open-source. Another could be a developer API.

Whatever you choose, you should be able to reach into that pool at any moment, speak to a developer and smoothly integrate them as long as it takes to write up a contract and have it signed.

Technology is spreading like wildfire, software is eating the world, the digital transformation lies ahead of us while you compete for talent.

You should be looking for solid, base understanding, great education. Technology moves so fast, your existing employees are not even the same ones you hired back in the day. Yet their ability to learn, evolve, adapt is moving the company forward.

Skills based approach when you want drive.

Because an individual has probably very little saying in the process, it sucks.

You should have an academy to train your developers in a way that a football club has a training academy for its rising stars.

Look at Apple, Microsoft and how they nurture, rally and build a developer community. Look at sports and how they scout.

You should be involved in the community. You should be able to make offers. You should have scouts. You should learn to evaluate, value and recognise the contributions that an individual can bring to your team.

You should be building long lasting relationships that have merit and carry weight.

It’s harder and will carry cost to maintain that relationship. In return you have access to a pool of talent.

Not every company can afford and has that need.

Having said all that, it’s possible you the person might not be a good fit. Some things you just can’t tell from an interview.

People project their expectations and tend to reflect their needs in what you are saying.

Language is broken. I had an interview where I thought we were speaking on the same terms only to realise we where communicating opposing views.

This is why a probation period is good. For both ways. People are not keen on getting a job only to leave.

Not real world conditions. * Duress * Artificial

It sucks. Please are unfamiliar. They are like deer in lights.

There is an inherent power dynamic between a company and an individual looking to join.

It feels like a right of passage for a person looking to be accepted.

Conclusion

↩︎

Questions really shine on personality types.

Grounds them. You level with them.

The hiring process described here should be an easy substitute to the existing one you as long as you are willing to embrace it.

Might have to change the order on how you do things, change your perspective and let go of control.

The hiring process should be objective, fair.

You can still have a hiring process falling short in some areas and conpensate as a character by showing interest, moving fast, respectful. There are hard tacts that remain. Pay people, know ehat you want people to do and have a plan.

The hiring process should be about Work relationship, alignment (not technical expertise)

How you give feedback to a person that was rejected.

Ask people if there is something else they want to bring your attention to based on their past work experience.

Someone might be able to pick up on soft skills. Another one on technical.

Your time as an organisation isn’t more precious that that of an individual.

What makes you think that you deserve the attention, admiration of a person? Think how draining it is for a person to go through application processes.

Should be a tango. An investment in good faith. You give some of your time and you get some of the persons’s in return.

There should be a thread connecting and flowing through the hiring process to make it less jarring.

Your hiring process can be a competitive advantage.

It’s draining for people to interview. #Ref on people being reluctant to move because of hiring sucks?

The hiring process describe here show people how to contribute. This is very powerful even though it’s rudimentary. It’s programming. But this is the way you should treat see them and treat them as such.

Your role is to capitalise on their idea they can contribute to your company’s success and increase their motivation.

Your goal is to hire people that you can work with and alongside.

How your hiring evolves will depend on the needs of your business.

Try it. It can be kind, praise,

The way you describe the code challenge and how you expect me to work on it sounds very artificial and not at all how I typically think or work on an app. Building an app in 8 hours this way sounds more like a “technical culture fit” and less than a way to see how we work together. I find that with these code challenges the odds are stacked against the individual. It is an easy way to reject a candidate but very one sided and easily blind siding a company while being unfair to me as an individual looking to join the team.

Refine the hiring process.

Try it and see how your hiring improves, what feedback you start to get from people and how much time you spend. Let a person know that how compliant you are to this hiring process.

If a company has a hiring process that is outdated, biased, elitist and wrong, forward them this article.

Related

• Hiring for diversity - “A 2015 study followed up on this, and found that candidates with black-sounding names from elite universities did only as well as those with white-sounding names from less-selective schools.”
• Thinking of quitting the software industry - “FWIW, this is what it’s like to hire for a Lead iOS developer. Worse than the worse customer acquisition strategy.”
• Reasons I have resigned, quit or was let go of a job - “I believe it’s inappropriate to ask this question, it won’t get you any meaningful answers and it may lead to awkward conversations and I do mean as part of an interview.”
• Coding challenges as part of an interview - “There’s a huge difference between “solve this performance problem with a binary search” and “pass this test so you can feed your family.””
• In Head-Hunting, Big Data May Not Be Such a Big Deal - “Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship.”
• How we pay people at Basecamp - “There are no negotiated salaries or raises at Basecamp. Everyone in the same role at the same level is paid the same. Equal work, equal pay. Our target is to pay everyone at the company in the 90th percentile, or top 10%, of the San Francisco market rates, regardless of their role or where they live.”