But beyond repositories and commits, your profile can say a lot about you as a developer.

When used intentionally, GitHub becomes more than a code hosting platform. It becomes your CV for your codebase. It tells your story, showcases your skills, and gives people a reason to trust your work.

In this article, we'll break down the different ways to make your GitHub profile stand out. From setting up your GitHub account to engaging storytelling for your repositories, there's lots you can do.

Let's get started!

Table of Contents

• Sign Up for a Github Account

• Add a Profile Image

• Add Profile Details

• Add a Profile README File

• Tell a Story About Each Repository

Step 1: Sign Up for a Github Account

To begin, you'll need a GitHub account. If you don’t have one, you can set one up here.

Once you have your account set up and you're logged in, we can move on to the next step.

Step 2: Add a Profile Image

Your profile image is often the first thing people notice. It could be a professional photo of yourself, or an image or avatar that represents you or your interests

As long as it’s appropriate, you’re good to go.

To add a profile image, you'll need to:

• Open your profile menu/dashboard

• Click on the image icon at the left

• Click on the edit text on the image icon

• Select the image to set as your profile picture

• Click the "Set new profile picture" button

So, you should have something like this:

GitHub link to this page: https://github.com/settings/profile

And there you have it, your GitHub profile image is set.

On to the next one…

Step 3: Add Profile Details

This step is all about credibility and discoverability.

At the center of your profile settings you'll see fields like email, location, social media links and so on. We'll be adding those details so you can take advantage of the discoverability it lends to your profile.

GitHub link to this page: https://github.com/settings/profile

For this step, you'll want to add as much detail as possible (apart from your home address – I think we both know why).

For the location, you can just put in your city or country so others have a general idea of where you are in the world.

Step 4: Add a Profile README File

This is where you introduce yourself properly and tell your story.

A Profile README is a special repository named exactly the same as your GitHub username. Your README file appears directly on your profile page.

The READme should answer the following questions:

• Who are you?

• What are your project highlights?

• What are you currently working on or learning?

• Your hobbies or interests (optional)

While answering these questions, you should aim to keep it minimal and yet interesting. You don't want to overwhelm the visitor.

Here's how to create your README:

• Click New repository

• Name the repository exactly the same as your GitHub username

• Check “Add a README file”

• Make sure the repository is public

• Click Create repository

Profile README file setup:

GitHub link to this page: https://github.com/new

So if you answered the questions listed above, your README file should look something like this:

GitHub link to this page: https://github.com/chinazachisom/chinazachisom

It should also be showing directly on your GitHub profile like below:

GitHub link to this page: https://github.com/chinazachisom

Step 5: Tell a Story About Each Repository

Now, this is where you can tell a story about each of your repositories using a README file.

NB: Each repository should have its own separate README file.

What to include in a repository README:

• Project title

• What the project is

• The purpose (the “why”)

• Key features

• Challenges you faced and how you solved them

• Setup or usage instructions (or a live link if hosted)

• Technical concepts used (e.g., throttling, caching, lazy loading) (optional)

• Images or video demos

You may also include badges, charts, contribution graphs or other visual enhancements that help highlight project quality, activity and impact.

With the above structure, you can tell the stories behind your projects, show your problem-solving skills, and make your work easier to understand and evaluate.

Repository README File Sample:

GitHub link to this page: https://github.com/chinazachisom/Artsy

Conclusion

Your Github Profile is more than just a storage space for your codebase. It's your developer Identity as well.

Following these basic steps can help turn your Github into a portfolio infused with your personal brand. It makes your GitHub Profile stand out, which can help open doors for more opportunities.

Treat it like a CV for your code and let your work speak for you.

About the Author

Hi there! I'm Chinaza Chukwunweike, a Software Engineer passionate about building robust, scalable systems that make a real world impact. I'm also an advocate for continuous learning and improvement.

If you found this useful, please share it! And follow me for more Software Engineering tips, AI learning strategies, and productivity frameworks.

At DevSkiller, we are known for our detailed industry reports that assist IT recruitment professionals with their hiring decisions. And this past year has been the most diverse and data-heavy set of information ever compiled by our team.

Despite the circumstances that 2020 brought us, the show must go on. We have compiled 304,654 coding tests sent to developers in 156 countries to create the 2021 DevSkiller IT skills report.

Whilst it’s easy to point to the big tech multinationals that will indeed profit from a crisis like we’ve had, many other small businesses will have a hard time adapting to the market’s fluctuating demands.

Innovative tech can help alleviate a lot of the unforeseen burdens in this pursuit, but businesses are wary of the risks involved by relying on unfamiliar technologies.

To make it easier to process how our world in tech has changed during the past year, I will provide insights into the dataset and emphasize some of the more relevant findings from the report this year.

1) Java and JavaScript are the most in-demand IT skills for 2021

One of this year's most significant developments is that Java has rejoined JavaScript for the top spot in IT skills. The two popular languages were seen in 43% of test invites.

The remainder of the top 5 are SQL, .NET/C#, and CSS/HTML for the second year running.

With Java once again asserting its relevance, this trend indicates that despite the importance of front-end architecture in software development, many companies seek developers who are skilled in back-end technologies.

As we found in last year's report, the top 5 IT skills are commonly tested with other languages across DevSkiller’s platform. However, it goes to show that more and more companies are searching for developers competent in these IT skills.

2) 75% of companies are looking for JavaScript developers

Interestingly, the top 5 desired IT skills have remained unchanged from last year. There has been a slight shift in their overall percentages, but the list has more or less stayed the same.

This past year, 75% of companies were looking for JavaScript developers. SQL took out second place with 63%, while Java has dropped slightly to 51%. HTML/CSS and .NET/C# have both seen minimal improvements from last year registering 48% and 41%, respectively.

These numbers are also backed up in the Stack Overflow 2020 Developer Survey, where it also holds the top spot. This is enough evidence to suggest that JavaScript remains the go-to front-end IT skill.

We’d like to point out the growing shift towards TypeScript as a replacement for JavaScript. The distinction between the two is not specified in this report as we classify most TypeScript coding test invitations as JavaScript on our platform. In forthcoming years, we'll make a clearer distinction.

For another year in a row, SQL reigns supreme as the most popular database IT skill. While companies are increasingly choosing .NET/C# to solve technical issues, Java still remains the preferred option. The rise in popularity of HTML/CSS points to the ever growing need for skilled web developers.

3) Google Chrome and Windows 10 are the most popular browser and operating system on our platform

Over the past year, we decided to run an analysis on the most popular browsers and operating systems used by candidates on our system.

Rather unsurprisingly, Google Chrome (68.84%) was the preferred browser by a considerable margin. This finding mirrors data from StatCounter Global, which lists Google Chrome as the most popular web browser (63.54%) at the time of publication.

Mozilla Firefox (15.28%) came in second place on our list, followed by Edge-chromium (6.01%) and Safari (3.93%). Our supplementary source, StatCounter, has Safari in second place while Firefox sits at third.

This suggests that developers have different needs that are better met by Firefox - suggesting that developers don’t necessarily follow the same trends as the general public.

Taking the top spot for the most popular operating system was Windows 10, with 54.13% of developers using this operating system. Again unsurprisingly, this was in line with the 2020 Stack Overflow Developer Survey, where almost half of the developers surveyed used Windows as their primary operating system.

Following that was macOS (23.01%), Linux (12.64%), while Windows 7, Windows 8.1, Android OS, and iOS were all used by less than 5% of developers.

4) More candidates are taking coding tests than ever before (69%)

This past year a record 69% of tests were sat by candidates, resulting in our highest uptake rates ever. Last year, only 41% of candidates took the test. If you take into account the fact that companies sent out DevSkiller coding tests to a greater number of candidates than last year, it is an even more impressive feat.

We believe the higher uptake in this year's report is likely due to the COVID-19 pandemic. Candidates who have either been forced into unemployment or are uncertain about their job security are not ignoring their coding invitations.

5) React, MySQL, Spring, ASP.NET, Data Analysis, HTML, Laravel, and Bash are the most popular technologies in their respective tech stacks

Since our tests were created with the tech stack in mind, we are able to see what the most popular IT skills, resources, and technologies are in their respective stacks.

React is the most popular technology used in the JavaScript tech stack, present in 35% of tests.

React leads the way for the second year running as the most popular technology within the JavaScript tech stack.

Just as it did last year, React tops the Hacker News hiring trends extending its streak to 31 consecutive months at the time of publication.

MySQL is used in more than half of SQL tests at 53%.

MySQL has increased in popularity year after year, with a near 16% increase for the database management system in 2020. SQL Server and HSQLDB placed in second and third.

Spring is the most used tool in the Java tech stack with 36% of tests.

Spring is still the most popular tool here but has lost some ground compared to last year (47%). The user-friendliness and functionality of Spring Boot placed the popular framework in second position.

ASP.NET is seen in almost half of all .NET/C# tech stack tests.

The leader from last year once again tops the list for the .NET/C# tech stack with a whopping 45.93%. SQL Server (36.90%) overtook MVC (36.35%) by a narrow margin to come in second place this year.

Data Analysis tops the Python tech stack, being used in 35.22% of tests.

Holding its place for the second year running is the popular open-source web framework Django with 20.96%.

HTML was present in 94% of all CSS tests.

As the two technologies are so interchangeable, it's little surprise that HTML featured so predominantly in the CSS tech stack.

Laravel remains the most popular resource in the PHP tech stack with 26.65% of tests.

Despite dropping slightly from last year, Laravel remains the most popular framework of the PHP tech stack. Symfony was the other clear standout seen in 17.07% of tests.

Bash is the industry leader in the DevOps tech stack, present in 70.61% of tests.

This is the first year that we've included the DevOps tech stack in this report, and it's popularity in recent years has quickly increased. Following Bash was networking (65.31%), and then Docker and System Administration tied at 54.69%.

6) Countries are looking abroad more than ever for their technical hiring needs

The COVID-19 pandemic has caused significant changes in company hiring patterns. As a result, most companies have undergone rapid transformations into remote-friendly or even remote-first workplaces, which has prompted a substantial rise in international hiring.

This year, the UK, Canada, Australia, Indonesia, Denmark, and Chile all saw increases in their international hiring percentages.

7) Australian developers scored the highest on coding tests

In previous years, we used the mean score to determine the highest scoring developers by country.

This year, we have analyzed the 90th percentile — which demonstrates the results that only the top 10% of candidates in a given country scored better than. We made this change because the mean score includes outliers that often influence averages and skew results.

Australia took the top spot for IT skills this past year, with 10% of Australian developers scoring higher than 93.56% on their coding test. Developers from the US came in second (90.91%). Rounding out the top 5 were Sweden (90.35%), Portugal (89%), and Poland (87.50%)

8) The US is driving international recruitment but has only the 5th largest labor market for overseas recruitment

The US is the global leader in international hiring but has slipped to the 5th largest labor market. In 2020, we saw the US drop from second position to fourth, forming part of a continuing downward trend.

These statistics are testament to the improving quality of developers from other markets. Brazil holds its position in the top 5, while developers from Russia and Canada are becoming increasingly popular sources for overseas recruitment.

The other trend we see is that companies are concentrating on allocating IT skills to outsourced-focused countries. This trend is likely to continue for years ahead.

Interestingly, Canada and Brazil are in first and second position for the top countries from which the US recruits its developers. As we noted last year, the proximity and the relative time difference makes them desirable for US companies to source developers from those countries.

What do these IT skills numbers mean for us moving forward?

2020 challenged us in every way possible. The consequences of its impact will undoubtedly take years to recover from, including the tech world.

Despite this sobering reality, The Bureau of Labor Statistics projects an 11% growth in the IT industry over the next ten years. An even greater uplift is forecasted in the field of software development.

We’ve also analyzed the state of the global IT market for 2020 and the outlook for 2021. As reported by CompTia, research consultancy firm IDC projected global IT revenue to be $4.8 trillion for 2020 back in August, however due to the COVID-19 pandemic it failed to reach that mark.

As expected, in 2021 the US will be the largest tech market in the world with 33% of the total revenue or $1.6 trillion. Outside of the US, Western Europe (19%) and China (14%) are the next two largest technology markets projected for 2021.

While all of our data was compiled over the past year, it holds some interesting insights for the year ahead:

• The developer labor market in the US is shrinking — whilst still the global leader for technical hiring, it now is in fifth place in regards to providing professionals with IT skills to the global market.
• Australian developers have staked their claim as some of the best developers in the world.
• JavaScript is not going anywhere, and the legacy technology’s popularity and demand only seems to be rising.
• The pandemic afforded more time for candidates to take and finish their coding tests.
• Familiarity with database languages such as SQL will go a long way and Spring Boot is also slowly rivaling Spring as the most popular resource in the Java tech stack.

These are just some of the findings in the report. Check out the full 2021 DevSkiller IT skills report if you want to get the complete picture of these insights and more.

I care about the future of work because I have always been fascinated with how people earn money and the jobs they hold.

I grew up in a family that valued household chores, so I got a job washing cars in my neighborhood when I was nine years old.

Often I am asked (by my parents no less) what the next few years will look like in the job markets. I used to work at Indeed, the employment-related search engine, and spent a lot of time thinking about how people will work together - and in companies - in the future.

Specifically I am asked: What will change?

Alas, I can’t predict the future.

But what I think is an equally interesting question – although one that is all too often overlooked – is what about the future will not change? In other words, what will look the same today as it will next month, or next year?

I believe how companies attract and retain talent will change. But some of the methods used today will remain constant.

I have observed how hundreds of firms attract new workers successfully. And I have boiled down the key learnings from their job postings and hiring pages. From them, I have extracted learnings that are useful if you are looking for a job or if you're a hiring manager looking for workers with technical skills.

I want to share these lessons with you.

#1. Companies will need to offer new and differentiated employee perks and benefits.

When looking at tech-centric job openings at companies today, it is common to see perks like “office dog” or “unlimited cold brew” or “team happy hour”. These keywords appear on many job descriptions as benefits of employment.

But in the era of COVID-19, it is painful to see job postings that are misaligned with how staff spend their time.

I have hired staff that works remotely and know that their needs are in many ways different from traditional office workers.

Welcome packages, a personal budget to optimize a home office, or a food delivery account are probably better aligned with what remote staff want.

Companies must think holistically about their benefits packages and ensure that they are relevant to today’s workforce.

As companies become more in tune with what workers care about, they're changing their hiring policies and interviewing strategies to accommodate remote talent. And the innovative companies will continue to offer differentiated benefits and perks to empower their staff.

An emerging perk that a growing number of firms are offering is in-house technical training and upskilling.

Helping staff develop and grow not only keeps ambitious workers around longer but it deepens the human capital and intellectual property possessed by the firm.

I have one friend who works at a company that is giving staff “time off” to learn how to create e-commerce sites and chatbots.

If you are a builder and creator, can you think of a better retention perk?

#2. Companies will embrace authenticity culture so that workers can bring their whole selves to work.

Mark Zuckerburg, best known for co-founding Facebook, made the hoodie popular among tech workers. While Silicon Valley has long valued a more informal culture, non-tech companies from Main Street to Wall Street are evolving as well.

Fewer people are shopping for suits and ties. Tailored Brands, the parent company of Men’s Warehouse and Jos. A. Bank, filed for Chapter 11, a form of bankruptcy that involves a reorganization of a debtor's business affairs.

When Tim Cook, the American philanthropist and Chief Executive of Apple recently made a press announcement that Apple would produce one million face shields a week, he did so in a cotton t-shirt from his home office.

Such informal attire would have been unrecognizable at Apple in years past.

In order to attract and retain technical workers, companies will need to embrace talent in a holistic manner. From how they dress to how they vote, workers will demand that companies let them bring their whole selves to work.

Many large technology firms - including Indeed, Google, and Facebook to name a few examples - have internal resource groups. Amazingly, these groups - designed to bring people with similar backgrounds together - are all too often not used in job postings or recruitment efforts.

If your firm doesn’t have resource groups, it should consider building them out. If your firm has resource groups, it should consider telling prospective staff about these communities.

If a firm wants to attract and retain technical talent, it will need to embrace authenticity culture. Companies will want to bring their culture to the forefront of why their workforce is unique and exceptional.

#3. Salary and job structure will continue to matter but so will holistic compensation and autonomy.

My parents, and many of their generation, valued jobs that had predictable compensation, simple to understand benefits packages, and structure.

It is well documented that baby boomers spent far more time in jobs and changed roles less frequently than members of today’s workforce. A pension, a once common corporate benefit, is now a rarity.

I don’t see people, or job postings, focusing less on money. Rather, I do see that job seekers want more holistic compensation packages (time off, mental health services) and increased autonomy.

I recently heard a peer state the following about his manager: “She is great because she is entirely hands-off in her approach to how I run my book of business. I give her updates but it’s my product to take to market.”

His freedom to take the actions he deemed in the best interest of the business was a currency that made him value his role more.

Today, innovative firms are attracting and retaining staff by offering childcare stipends, monthly food or health benefits, or pet adoption policies.

One innovative startup is offering its technical workforce access to virtual games. By encouraging staff to play games and understand the mathematical models behind games like solitaire, the firm can help their teams develop new mental capacities in a fun way.

Final Thoughts

The future is yet to be written. Labor markets, like technology, are constantly evolving.

Even though there are more workers than job openings, some sectors of the labor market are seeing red-hot demand. This is particularly true in the fields of cyber-security and Information Technology.

That is why re-conceptualizing how to hire and attract staff is so important: if you can’t predict the future you need to be well equipped for anything the future holds.

The heuristics one will choose to find a great job are unlikely to change. People will want a good salary, a good manager, and a good culture.

What will change is how we work, the mediums we use to communicate, our attire, and the underlying values underpinning work culture.

Companies need to be aware of these changes to retain the best staff and to keep these workers motivated and in their roles.

Remote work is a fast emerging segment of the labor market. How to embrace this shift as an employer - and find, recruit, and empower remote staff - is a question many companies and hiring managers are grappling with.

I have hired staff that works remotely. I have been hired to work remotely. In both situations I have learned lessons along the way. I want to share these lessons with you.

Perhaps you are tasked with attracting remote talent. Maybe you are the talent. In either case, remote work requires a deliberate recruiting framework as the types of skills that remote workers need to succeed are slightly different than those skills needed to thrive in a traditional workplace environment.

First, some relevant context: I have over a decade of startup and large tech work experience and have worked from home in various capacities - as an individual contributor, company founder, and general manager.

I have also conducted scores of remote interviews, extended offer letters to remote staff, and helped employees onboard who will work from their homes.

When hiring remote workers, I look for robust interpersonal and communication skills. Oftentimes remote work requires a person to demonstrate additional maturity and focus. They need to spend their time and the company’s resources well, with limited daily guidance. From my experience remote workers who excel have high intrinsic motivation and are self-starters.

5 skills remote workers should have - and how to find them

The following framework can help you probe for behaviors that you may want your staff to possess and will enable you to more analytically recruit and evaluate talent.

This framework is useful for candidates who want to prepare for remote job interviews or think holistically about skills to develop further when seeking remote work.

High performing remote workers demonstrate a:

1. Bias towards action,
2. Strong emotional maturity,
3. Track record of driving projects or objectives to successful conclusions,
4. Communication cadence that prioritizes that the right things get done,
5. Persuasive advocacy when working with internal and external stakeholders.

If you value these attributes here are questions you can ask to better understand a candidate’s skill set.

How to confirm a bias towards action

Consider asking: explain a time when you have gone above and beyond expectations to solve a problem. How did you identify the problem? What was the outcome?

These answers can provide great insights into how deeply the candidate has thought about past problems and how they might solve issues that arise in the future.

I value diversity in thought, experience, and background. The beauty of showing a bias towards action is that such a mindset can shine through in a large array of activities.

A bias towards action need not be demonstrated just by work examples, though it can be. I once interviewed a candidate who showed a bias towards action by taking care of her sibling when her parents were unable to do so. Another candidate showed a bias towards action by suggesting solutions to a client’s operational problem which helped secure a new contract.

How to confirm ability to resolve ambiguous situations

At times working from home can be isolating and force staff to solve complex problems with limited managerial guidance.

If you want staff that can escalate work appropriately and have the self-awareness to resolve high-ambiguity situations, consider asking: What’s something you’ve achieved that you’re most proud of and why? When were you last frustrated by work, and how did you handle it? What is one thing you would like to change about your current company or role? How has our interview process been so far?

These questions probe for self-awareness. Being self-aware helps a person make informed decisions.

How to confirm ability to take ownership of projects

The social and technological foundation of collaboration has gotten incredibly good over the last decade as a result of new digital technologies and communication tools.

Yet remote work still necessitates that an individual drives projects or objectives to successful conclusions and takes full ownership of processes, tasks, and responsibilities.

To probe for these skills, consider asking: When did you exceed your management’s expectations? What happened, and why? How have you demonstrated thought leadership or engaged in projects that added value to your clients or internal stakeholders?

How to confirm excellent communication skills

Remote workers - more so than traditional office workers - need to communicate priorities that ensure the right things are getting done because informal conversations and water-cooler chats are less frequent.

Workers add value by understanding the cadence and frequency of written and verbal communication. As many Freecoders know, an engineer writes and submits code digitally. A reviewer simply needs to have access to the same Pull Request. So it is up to the remote worker to provide clarity and content since they are unable to showcase their whiteboard.

Consider asking: What would your colleagues say is your strongest communication skill? How would you go about simplifying a complex issue in order to explain it to a client or colleague? How would you persuade someone to see things your way? Why?

How to confirm relationship building skills

You will likely want your remote staff to advocate for and positively represent your team and business when working with internal and external stakeholders.

I ask: share an experience in which you successfully advocated for a client to resolve a crisis? What would you have done differently in hindsight? Please share with me an example of how you helped coach or mentor someone. What improvements did you see in the person's knowledge or skills?

Final thoughts on remote work

Like other sustained market shifts (i.e. the personal computer revolution), remote work is going to define how many of us, our firms, and our colleagues will work.

Before hiring staff you need a pipeline of candidates. Before that, you need to know what skills prospective candidates must possess to thrive in your firm. Only you will know what you need from new hires. In general it’s a good idea to understand candidates and their business fit.

Be open to candidates and answers that are diverse and varied – value can be demonstrated in many different ways.

If you use these questions as a guide and let yourself be open to new responses that demonstrate potential impact, you likely will acquire some very strong talent that will add value in the short and long term.

I’m an engineer, but I also have an MBA and for this post I’ll be wearing that hat. I was seriously considering buying an actual hat with “MBA” printed on it, but some good people talked me out of it, so unfortunately it’s a metaphorical hat instead of a real one.

I often see engineers complain about recruitment processes: They are long, they seem totally irrelevant to the job, everything is stupid. We just don’t get it. Unfortunately, we’re probably right — some employers don’t have any idea what they’re doing, but does it really have to be that way?

One of the very best courses I took during my MBA was a course about recruitment processes and the research behind them. It left a lasting impression on me and affected my perspective on recruitment processes when I was hiring and as a candidate. When I hear these rants, I often try to explain the rational behind a good hiring process, and I think this is insight which can be useful for engineers and recruiters, which is why I’m writing this post.

Hiring is hard. Mistakes are expensive. We have no idea what we’re doing.

Of course we are excellent at it. It’s always someone else who has no idea what they’re doing.

So, What Can We Do?

First, let’s look at some common tools you have at your disposal, describe them and check how good they actually are, based on the latest academic research in the field:

The validity numbers given here are “predictive validity”. This means that the validity of the result on a specific test is the correlation with success on the job. A 0 validity score means there is no correlation and the test is worthless (you might as well toss a coin), 1 would mean the test perfectly predicts success on the job.

Intelligence Tests: IQ tests, SATs etc.
Validity: 0.51
Even if you don’t ask for the scores on these tests directly, you usually try to get them by proxy by checking the school they went to and their GPA. I know this seems unfair to many candidates who are excellent engineers even though they didn’t do very well at higher education (or didn’t go at all, i.e. bootcamps etc.) but it is a quick and cheap way of getting through a lot of CVs.

Work Sample Tests: Requires you complete a task related directly to the job.
Validity: 0.54
When done well and at home, this saves time for everyone . It also allows the candidate to display their best work with a minimal amount of pressure. However, the time it takes is often underestimated, and if it’s done at home candidates may “miss” something and get stuck without answers, while potential employers are missing valuable signals.

I’ve seen many engineers who seem to think that work samples are THE BEST AND ONLY way to really show their worth. For the life of me, I don’t get it. Many work sample tests are just a way for the employer to get you to put in time with close to no cost for them. As a candidate I really don’t see how they’re better than a coding interview — the task is either just as synthetic and unrepresentative of the actual work, or too complicated and time consuming.

Employment Interview: I’m sure I don’t have to explain what an interview is.
Validity (Structured): 0.51
Validity (Unstructured): 0.36
Ah, we’re finally getting to something here. What’s the difference between a “structured” interview and an “unstructured” interview?
Well, a structured interview has repeatable questions and clear and objective criteria for answers. An unstructured interview, ummm, doesn’t. Ultimately, an unstructured interview comes down to a “gut feeling” about the candidate. I’ve often felt thankful for having clear and objective criteria specified in advance, because it’s so easy to skew the interview result according to your first (entirely biased) impression of someone.

Job Knowledge Tests: Direct questions on the subject matter.
Validity: 0.48
Usually this is carried out by giving the candidate a questionnaire asking them domain knowledge specific questions. Things like “How does web routing work in technology stack A”, “What would happen if you tried to assign this value to a string in technology stack B” etc.

Not bad so far. Now I’m getting to the “good stuff”:

Assessment Center: When you pay a whole lot of money to send candidates to spend their day doing group dynamics with a bunch of strangers.
Validity: 0.37
Can you tell I think these are stupid? And not only me, their validity is relatively low and their repeatability (i.e. getting the same score on repeat tests) is also extremely low. If you’re recruiting — don’t do this, please. If you’re a candidate and you have the privilege of refusing — just say no.

Reference Checks: Asking past employers about the candidate.
Validity: 0.26
I know many employers insist on reference checks. But their validity is not so great and they should be used with caution.

Graphology: Sending a writing sample to a hand writing ״specialist״ who can tell if you’re a good match for the job. Usually used for integrity testing.
Validity: 0.02
Graphology is NOT a good recruitment tool. DO NOT use it. Have I stressed that enough?

The coding interview

Even though I already know these statistics, it still hit me hard while writing this post: even the best tests have only 0.51–0.54 validity, and that is far from amazing. Is this best we can do? What can we do with the tools we have to get better results?

Enter the dreaded “coding interview”. Whether done on a whiteboard or an online editor, it allows employers to pack a work sample, structured interview, and job knowledge test into a single session. By giving many such coding interviews, conducted by several different people, you can achieve better results, improve reliability and reduce bias (“gut feeling”). That’s why recruitment processes are so long and exhausting (for everyone involved).

I know I don’t have you convinced yet, but I’ll talk a bit more about how to assess the quality of this process later on.

Ok then, let’s see how it’s done.

Is this a good question?

You are given three containers.

• One box contains all white balls, one all black balls, and one a mix of black and white balls.
• Each box is labeled, but all the labels are wrong.

How many balls would you need to pull out to determine which box is which?

What about this one?

The count-and-say sequence is the sequence of integers beginning as follows:

1, 11, 21, 1211, 111221, ...

1 is read off as one 1 or 11.

11 is read off as two 1s or 21.

21 is read off as one 2, then one 1 or 1211.

Given an integer n, generate the nth sequence.

Or this question?

Are you pregnant or are you planning to become pregnant in the next year?

You’re wrong.

It doesn’t matter if you answered “yes” or “no”.

Questions are neither good nor bad.

Now, I’m not recommending asking someone if she is pregnant, because that’s illegal and usually quite irrelevant. But if the job is in a factory with dangerous chemicals and hard physical labor, that question might actually be an important question to ask!

Questions should be the last thing you do when you build your process.

First, ask the right questions

• What is the actual job definition?
• Which technical skills does one need in order to perform the job well?
• Which soft skills and personality traits do you value as an organization?
• How much time, effort and money are you willing to spend in order to find the right person?
• How much time and effort will the candidate be willing to spend in order to pass your process?

Only after you have the answers to these questions can you begin to create a concrete process. You can’t copy the answers to these questions from another organization. You have to figure them out for yourselves.

Create the right process

• Decide what your screening parameters are and screen ruthlessly. Do not waste your or your candidates’ time.
• Use structured interviews for technical and for soft skills interviews.
• If you feel the candidate will be willing and it saves you a lot of time an effort, you can also use a work sample.
• Call references and perform background checks only as needed.

Measure, refine, repeat

Every time I mention the validity of some process or other I’m asked how the validity was measured. I’ve actually read the articles and I can tell you the methods they used, but to be honest — it doesn’t really matter. What matters is what works for your organization. You may find that the “coding interview” doesn’t match your values or doesn’t give you the signals you need to decide who to hire. You may find your candidates love doing long work samples in the office and it allows you to get to know them better.

The point is that once you have your process in place, you must make sure it is working!

• How many candidates who passed your initial screening made it through the interview process?
• How many candidates who passed the entire process accepted the offer?
• How long do employees stay with you?
• How are their performance reviews?

Gather your data and refine your process accordingly. This is a continuous challenge!

Avoiding bias

Now you’ve built a process and have statistics on the candidates hired. How can you make sure you’re not testing for “rich white male” instead of “good programmer”? How do you verify you’re not hiring “people like us” instead of checking actual “culture fit”?

My personal pet peeve is open source contribution or other “after hour” projects as a requirement. If you’re an excellent programmer but have other hobbies, or if you god forbid have a family and actually want to spend time with them — that’s it, you’re out. That, to me, is an example of screening on irrelevant traits.

Unfortunately, some common quick fixes don’t seem to work. Implicit bias training doesn’t (usually) affect outcomes, it often makes things worse. Diverse interviewers do not necessarily make less biased decisions either, as they often show the same biases as anyone else.

You should remember that this is an entirely subconscious effect — you don’t have to be overtly racist or a bad person to be biased. It’s a natural part of how our brain works, so it’s up to the process to help us fight our biases actively.

The best way to tackle this issue is to add diversity measures and use the “measure, refine, repeat” cycle to check how you’re doing.

If you measure diversity and refine your process accordingly — you’re going to find where the problems are and take appropriate actions. If it’s a real pipeline issue — read Moran Weber’s excellent article. If it’s not really a pipeline issue, look at how you treat diverse CVs, how well they pass your process, how often they accept your offers, etc.

Aside: Integrity

This is a bit off topic, but it’s just too good to skip. You could skip it anyway, I won’t hold it against you.

I mentioned graphology as a bit of a joke, it’s validity is so low that it’s an absolute waste of money. So why do some employers still use it? You’d be surprised: to some of them it’s a way for someone else to decide what they feel they can’t! But some of them actually believe it’s accurate, how can that be?

Let me tell you a story: When I was taking this course, during one of the classes we were asked to give a writing sample. When the next class started, we each got a graphological assessment of our personality and were asked to rate how accurate it was. Most of the class graded it 4 or 5 for accuracy. Turns out we all got the same analysis… How could we be fooled like that?

This is called the Barnum effect, and basically what it means is that when we read a generic text like astrology or graphology, we will believe the parts that are true and dismiss/forget the parts that are wrong! The final impression we’re left with is that the text was very accurate.

Turns out the best way to measure integrity is by asking directly! There are pen & paper tests with a series of questions about integrity. The irony is that dishonest people believe they are normal people in a dishonest world, so they have no problem telling the truth! They will say “sure, I take boxes of pens home with me” or “why shouldn’t I lie about being sick?”, and expose themselves as less than worthy of trust.

If you are recruiting, I hope this gave you some insight into how to build a good process. If you’re a candidate, I hope this helped you understand what’s broken in recruiting and what actually works. For me — I’ll finally have a ready made answer for all the frustrated candidates out there. Good luck!

Twelve questions to ask at tech interviews

I’ve just come off six weeks’ of interviewing for medior software developer roles, in a market that is desperate for talent (Amsterdam). That means I went on a lot of interviews. In order to tease out which companies might be right for me, I wanted to ask many questions. You’ll have to find the right balance for you and the person(s) interviewing you.

If you’re job-hunting as a junior, you may find that you don’t actually care about the answers to any of these — you just want a job. Even if that’s the case, consider what would be a red flag for you and ask questions that will tease that information out of your interviewers. If there’s a deal-breaker, you want to know about it before you accept a job offer.

The typical process

Based on my experience, here’s how the process of interviewing generally goes:

1. Screening call / potentially on-site interview. Typically done by someone in HR. If done by someone technical, it’s normally quite short (not a good time to fire all your questions).
2. Technical interview. You’ll have another round of interviews with actual developers and they’ll dig into your knowledge.
3. Technical assessment / homework / pair programming. Huge bonus points for companies doing pair programming, in my opinion. I understand why they assign homework, but for the most part it’s a waste of everyone’s time and does not assess the right skills.
4. Final interview, meeting the rest of the team. Sometimes this interview is replaced with meeting the founder(s), if it’s a small company.
5. Offer.

Naturally, this all differs quite a bit per company, but it’s a general outline for what you might expect during the hiring process.

Questions for your screener

It’s very common to have someone non-technical do the first interview. It’s not appropriate to ask them stack questions, because they often have no idea what you’re talking about — even in small companies.

Most of this call should be you talking about you. They already have your CV, but they’ll expect an introduction — make sure you have a good and concise story to tell about your work history. You’ll be repeating this story ad nauseum while interviewing.

What is the hiring process?

It’s likely they’ll go through this with you anyway, but if they don’t, be sure to find out what all the specific steps are with this company. If you’re just testing the waters here and they expect you to build a complete app next, it’s probably best to move along.

Tell me a little about the tech team.

How many members, makeup junior vs. senior, and any hierarchies (is there a CTO? Product owner?) should be easy for the HR person to explain. If not, particularly at large companies, that’s fine too.

Make sure you know the next step before you get off the phone with your screener.

Questions for the technical interview

Here’s where the bulk of my questions come out. They’re assessing you, but you’re also assessing them. Let your interviewers drive the conversation, but it’s fine to jump in with a question or two along the way. At the end of the meeting, they should ask if you have any questions and you can ask as many of these as feels right for the moment.

If you don’t care about the answer to a question, don’t ask it. There’s no point in wasting everyone’s time talking about a thing unless it will help you decide whether or not to work there.

I put these in order of relevance to me. If we’re having a nice chat, I probably don’t get to the ones at the end. If it’s a little painful and hard to talk to my interviewer, I might get to ask all of them, and hope that I have better rapport with the rest of the team.

Who is your ideal candidate for this role?

I really like this question because it gives you a better idea of what is expected of you, by framing it in a new way. If your interviewer(s) could create a person out of thin air to fill this role, who would that person be? Sometimes they will describe you to a T and other times you’ll hear a lot that doesn’t align with your background / skills / preferences. It’s a good way to see if you’d be a good fit at the company.

For instance, one company said they wanted someone who “doesn’t need a lot of help”. To me, that’s a red flag. Anyone coming into a new code base needs help to understand the business logic, even if they’re experts in the tech the code is built on. Developers who are hostile to a learning environment are a big turn-off for me.

On the other hand, I frequently heard that their ideal candidate would work “independently” and be “self-motivated”. These are great signs for me, as I see myself as both of them and don’t want a lot of nit-picking and forced structure in my own work. The two answers might mean exactly the same thing, but how they’re framed makes a big difference for your work environment.

What are the biggest challenges for this role?

The answer to this questions depends very much on what you’ll be doing. In all cases, it’s a great way to see behind some of the sunny information you’ll get from the rest of your chat. Pay close attention to what they think will be difficult in this role, and evaluate if you’re the right person to meet those challenges.

Who sets the vision for this company?

I’m looking here for the long-term plan, and hopefully to talk some about goals for growth. The only answer that strikes me as a red flag is if they don’t know how to answer the question. “The founder” seems like a fine answer for me for a small company, and “the board” and “management” as you get into larger companies. Major bonuses if everyone feels that they have input into creating a larger vision and roadmap. Blank stares would be bad here — you want to work at a company that knows where it’s going.

How do you measure the success of the development team / individuals / the company?

Again, a process question. I want to know how my work and my team’s work will be evaluated. If they have trouble with this one, I switch it around and ask how they know if they’ve done a bad job. In my opinion, if there’s no way to know if you’ve done well, but they’re clear about what “messing up” looks like, that’s a red flag. How can you be successful at your job if you don’t know what being successful looks like?

What is the most enjoyable / frustrating thing about working here?

This question is great to re-use on multiple people. Ask it as two questions, back-to-back (I prefer asking the positive one first). You’ll often see patterns come up — everyone is annoyed about the same things. Getting people to talk about a negative is always hard in interviews, but I find this one is difficult for people to side-step.

They probably won’t tell you the big systemic problems of the company (they might) but at least you’ll get a feel for some of the process / personality / bureaucracy challenges of working there

Describe the code review process.

The answer to this one tends to be fairly short — they do PRs, a colleague reviews on GitHub / wherever. Dig a little further to find out what kinds of reviews, the average time to merge after submission, etc. Are they going to be super nit-picky about everything? Let massive errors through? Do they actually care or are they just showing off their own knowledge? What about testing? How often do they release?

How does an idea go from “out in the world” into the backlog and finally to code and production — walk me through your feature development process.

I want to know where new ideas come from. Are they looking at the data and then building based on an informed worldview? Or does the founder get an idea and then everyone jumps to meet his expectations?

This question is a lot like the “vision” one, and can be asked as a follow-up. Once you have the vision, how does an actual feature get described and then coded? I consider this the closest to “what is it like to work here?” without needing to ask in those words and get a trite answer.

Explain a technical challenge you’ve recently faced.

If they struggle with the question above, this one should be easier — I’m asking for a concrete example of recent work they’ve done. Was there collaboration among team members or did one person just figure it out themselves? Were external resources brought in? Was the feature dropped? Again, this question is good for getting an idea of the day-to-day operations.

Bonus: What are the plans for onboarding new hires? How do you incorporate new developers into the team?

I consider this one fairly low-priority unless you are junior. Juniors should be looking for significant plans for onboarding and even training. Mediors and seniors can ask this question to see if they have an answer. I’d like to know that they have considered what it is like for new developers to start. Have they thought about how to make the transition into the company easier? It’s not necessarily a deal-breaker if they haven’t — because lots of companies have not.

Related, I like to ask if they hire juniors and how they work with them, but only if we are already solid that I am not a junior. I’m nearly three years into my career, but I don’t want to give anyone ideas. More senior engineers could ask this without fear of being mistaken for a junior, and get good information about how employees are valued.

Questions for the final interview

In this last interview, you might already be talking salaries and start dates. If they make you an offer, get really clear on what is on the table — bonuses, pension, equity, vacation days, starting date, etc.

Here’s a question you might consider asking but need to tread lightly and read the room:

Are there any internal politics I need to watch out for?

In a bigger company, they can put this on “sales” and let you know that they are the gods around here and not to piss them off. In a smaller company, they are liable to tell you there are no problems. What you’re going for is some first-day-on-the-job knowledge — who actually calls the shots? Is there a project on the table that some people think is not worth doing but others love? If they’re willing to give up a little dirt here, it can help you in your first weeks. It also shows that you care about fitting into the company and properly negotiating all the personalities floating around.

Final notes

All of these questions can lead into some great discussions. Don’t feel like you need to jump into each one. Start with the most important or most informative ones and go from there. It’s much better to have a back-and-forth than fire off each question.

In my assessment of a company, I’m trying to find out would I enjoy working here? and would they want me as a colleague / employee? Whatever conversation we can have that leads me closer to an answer to either of those questions is best. These prompts are just helpers to get there.

Good luck in your job search!

A how-to guide on finding hidden gems in the crowd

_Courtesy: [Mike Shannon](http://michaelshannon.tumblr.com/post/118468127504" rel="noopener" target="blank" title=")

Finding the right person for a startup can be hard, but finding the first product designer to strengthen your product in terms of aesthetics and usability may be even harder. From the very beginning, you want someone who is capable of leading the design process. You want someone who will do everything they can to solve the problems of your users and will make the product lovable and easy to use.

We had this hiring challenge recently at Kepler, because we were trying to find a design rockstar for our new product. While we were interviewing a bunch of product designers, I came up with a list of questions that now helps us scan potential hires like an X-Ray.

As Facebook’s Director of Product Design Julie Zhuo once said,

At a startup, you need your first one or two designers to be versatile — great jacks-of-all-trades… Not only do they need to deeply understand and think through product strategy, they also need to have good interaction chops and decent visual sense, since they’ll be doing everything from designing the UX to thinking about the brand to designing icons — they need to have a diverse skill set.

Pro Tip: Always remember that you should judge an artist by their work. Don’t just blindly rely on a simple conversation to reveal their true personality and skillset.

However, the information you’ll get out of asking the below questions will help you understand whether you are interested in seeing this potential hire’s work.

Afterwards, some form of test task relating to your product design challenges would be a perfect next step.

Here are my favorite questions to ask. I’ll discuss why you want to ask them, and what kinds of information you’d hope to hear in response.

1. In your opinion, what is a product design?

Why you should ask: Product Design is an extremely interdisciplinary domain connecting business, psychology, technical skills, and so on. Not only do you want a potential hire to understand that, but you also want them to explain how they’ve applied this knowledge in their previous work.

What you want to hear: One of the candidates I interviewed delivered a good answer:

Product design is a mix of business needs, visual appearance, and leadership. That’s why it is so hard, because you have to be good at all three things at the same time if you want your product to be successful…

This showed he really knew what he was doing.

Courtesy: Information Architects, Inc.

2. Tell us about the newest thing you’ve learned that has improved your design work. What was it? Why did you decide to invest time in it? How did you apply it afterwards?

Why you should ask: Product Design is a constantly evolving field. Learning how to learn is a must for everyone striving for success in this domain. A practical approach is what distinguishes a good product designer from a mediocre one.

You want someone who’s been there and gotten their hands dirty many times before they truly learned how it really works. Moreover, you need a balance. You don’t want someone conducting endless user research without any visible value for the product.

What you want to hear: Try to spot good cause-effect relationships. If a designer has learned something new to excel at their work, has carefully evaluated the time-effort ratio, and then applied this knowledge practically, they’re a rock star of learning.

Here is an example of what I’d consider a major red flag in this area:

Candidate: Recently, I got myself on good terms with [name of software] that helps you create those beautifully designed icons.
Me: Could you show us them?
Candidate: My superior decided that we didn’t need them…

3. In your opinion, how should a good design process start? Why?

Why you should ask: As Simon Sinek notes, everything we do should start with “why?” Despite the type of methodology a potential hire uses, design is a human-oriented type of job. Thus, having a decent level of empathy and a willingness to relate to the problems of others are indispensable skills in this creative field.

What you want to hear: Prick up your ears for any signs/behaviors that would help you describe this person as caring about the needs of others. A good answer might include something like this:

I start with the problem of a user first and then frame it as a design challenge. A good challenge is not too broad but leaves you enough ground for a creative approach to solutions…

_Courtesy: [Brian Pagán](https://twitter.com/brianpagan" rel="noopener" target="blank" title=")

4. What’s the most important aspect of your job?

Why you should ask: It’s basically a self-awareness test. Folks must understand why they decided to be designers for life. In my opinion, designers and product designers are problem-solvers who thrive on the balance between what the user wants and what the business needs.

What you want to hear: There’s no one answer fits all. In my hiring experience, one of the candidates responded as follows:

The empowerment of people is what drives me here. Helping them to do their job better, be more productive and happy at the end of the day. It was amazing when users wrote stories how [product name] has helped them get promotion or increase income. That’s something definitely worth working for…

5. What should come first — product or style-guide?

Why you should ask: It’s one of those chicken and egg problems. In 99% of cases, the answer shows whether a person is capable of defending their point of view. Designers, like entrepreneurs, should have strong convictions, loosely held.

What you want to hear: There’s no correct answer to this one either. Look for a reasonable explanation on both sides.

Generally speaking, if you have some sort of brand already, then a style-guide will definitely help to preserve consistency in its visual communication and image.

On the other hand, if you hire someone to start from a blank page, then trying to standardize visuals is like cleaning your shoes right before getting into the mud.

6. Tell us about a time when you simplified a complex situation or problem. What made you seek out a simpler approach?

Why you should ask: I borrowed this one from Dmytro Voloshyn, a good friend of mine. He uses it to test whether a candidate fits his company’s values. And I think it just works perfectly with the whole startup theme.

Good work today is better than a great work tomorrow. So look for any compromises a candidate made for the sake of time and resources. We live in a world of overwhelming uncertainty where time becomes the most expensive currency. Therefore, sometimes making quick mistakes is what makes great products in the long-run.

What you want to hear:

When I started working at [company name], there was a really complex and long user flow requiring a lot of steps from a user to accomplish the task and even more development work to launch the product. I suggested prioritizing one of the customer segments and building a user flow that suited those customers first, realeasing new features for the rest of the segments in cycles afterward. It helped to launch the product faster and avoid high development costs… Finding a simple solution is what design is all about…

Courtesy: SCM World

7. Recall a situation in which you were asked to do something you did not like or knew was wrong. How did you react?

Why you should ask: Everybody has disagreements from time to time with colleagues, friends, their spouse, and so on. It’s not about who’s wrong or right, it’s all about the right communication.

What you want to hear: The answer that really stood out to me was something as follows:

I have to understand what is the purpose behind a demand first. Once I get to know it, I can offer the solutions that he or she was not even able to realize before asking [about something I personally did not like/thought was wrong]

8. What is your favorite product in terms of design? What do you like and what don’t you like? How would you improve it?

Why you should ask: Good candidates always get prepared for this one beforehand. And that’s a good thing. Product thinking is a skill that gets mastered with constant and deliberate practice. A good product designer won’t have a problem tackling this one.

What you want to hear: One of the candidates I interviewed answered that Medium is her favorite product. I dug a little deeper and asked what she thought of the introduction of the clapping mechanism instead of a simple ‘like,’ which lots of folks considered quite controversial. She said every publication or story published here is a performance, and a good performance should be recognized with a million claps. Such a response is a perfect example of someone with a knack for good product thinking.

9. You start working on a new desktop/mobile/web app. What are your first steps?

Why you should ask: It’s sort of a dual check. People get better in everything they do once they have some systems set up. This is your chance to see whether a candidate is able to own and lead the product design process in your team. On the other side of the spectrum, look for questions rather than answers. Good product design folks always ask a lot of questions that help them deal with uncertainty.

What you want to hear: Who is the user? What is the desired platform? Can those users be found on this platform? An exceptional product designer will definitely ask questions like these.

Once you’ve given some answers, look for a decent explanation of how they’d handle the design process for your type of product. In our case, we’re building a desktop app primarily for macOS. Thus, being familiar with interface guidelines is a crucial element here.

Courtesy: Giphy

10. How do you keep up with the latest design trends? What resources do you use to inspire yourself?

Why you should ask: This is a rather simple one. Nonetheless, in my experience a lot of people got knocked out here. Either they don’t follow English-speaking resources (which is a huge miss in today’s globalized world), or they simply won’t be able to call any resources to mind. This would be a red flag.

What you want to hear: You just want to hear notable names that produce high-quality content (like Nielsen Norman Group, Invision Blog, UX Pin, IDEO and so on). They should also show a desire to experiment.

One candidate showed me the result of the button colors experiment he did after reading an article in one of the aforementioned blogs. Thus, feel free to prompt candidates if they don’t volunteer to show some examples themselves. At the end of the day, discovering a practical mind is always useful.

Courtesy: Giphy

I hope this helps you on your next hiring marathon and that you find someone to lead great design in your product.

If you found this story useful, please click the ? button and share to help others find it! You can also follow me on Twitter. Got thoughts or feedback? Please feel free to leave your comments below. I’d love to hear them!

We’ve all been there. Hunched over a desk. Scrolling through job boards. Looking for some trace of hope that you’ll ever work again.

At some point you enlist help. And that’s how you end up across the table from a recruiter.

By virtue of their relationships with employers, recruiters hold a lot of power over your job search. They can decide whether you end up at a rising startup or a fading conglomerate.

Whether they’ll flip you to the first company that comes along — or take time to groom you for a better one — often down to one thing: personal narrative.

I sat down with a recruiter to learn more about how they view recent grads, and what grads can do to get an edge in the job market.

Matt’s a recruiter at a sizable design startup in New York. He couldn’t resist kicking off the conversation with a “How’s the job going? Are you happy in your current position?”

We quickly moved on to what he said is the most overlooked part of the job hunt: shaping your personal narrative.

First Impressions and Narratives

Contrary to what most people assume, an interview — and your narrative — really starts the moment you walk into the office. Everything shapes the first impression you make with your interviewers — from whether you’re early to how you talk to the receptionist.

Psychologist Nicholas Rule described the science of first impressions as a situation that happens almost instantly.

“This happens so quickly — just a small fraction of a second — that what we see can sometimes dominate what we know.” — Nicholas Rule

Once you’re in the office, the time to plan out your talking points has passed. By the time you walk into the office, your focus should be on the people in the room instead of the anxiety in your head.

One tip that’s always helped me is to visualize the interview before I go to the company’s office. Think over the papers you’ll have in your hand, the clothes you’ll be wearing, how you want to introduce yourself.

If you practice this simple visualization trick before you walk into the office, you’ll better-anticipate their questions and be better-prepared to react.

Will it blend?

Don’t try so hard to blend in.

People often assume that a personal story means how you stand out or what makes you different. That’s certainly part of it.

But an often overlooked part of a your story is how you fit into the hiring manager’s narrative for their team, and where the company’s going.

This is where blending comes into the picture.

Before we dive into what blending means from a psychological standpoint, let’s look at it from the physical. Blending really starts with how you look.

Matt the Recruiter says he’s immediately put off when an applicant goes to a developer interview at a tech company dressed in a suit.

Not a good look

He says such an outfit instantly creates an awkward air for the rest of the interview, because such a professional getup lacks the intimacy factor he’s looking for in a potential team member.

Unless a suit is the common attire for the rest of the staff, I would opt against wearing your nicest tie to that next interview.

Blending in Culturally

How you look is far from the only aspect of blending, though. Matt the Recruiter talks about the need to fit in from a psychological standpoint as well. He says you need to create a mental image.

Within the time allotted for the interview, you have to convince the recruiter that you’re the ideal candidate for them to work alongside them 40 hours a week for the next several years.

Let’s dive more into what that means.

“Your brand is a story, it’s a story that helps people tell themselves about you. Most of the stories are unfair, prejudice, lack of information and fear… They are never true, nobody knows you as well as you do.” — Seth Godin

It’s up to you to shape that story. Seem like someone your interviewer would hang out with. Whatever it is they’re looking for, the story you present should blend into the atmosphere and be vaguely familiar.

For example, I’ve found appealing to an interviewer’s sense of nostalgia works well to quickly build a bond.

I can recall numerous times this technique helped me during various job searches — most critically while hunting for my first job out of college.

As a recent college grad, I lacked much in the way of work experience. But I still wanted a prestigious job. So I applied for the World Bank.

I told myself that if things didn’t go well with this “stretch” position, I could always take the assembly line approach and send out hundreds of emails to less desirable positions and pray for the best.

Before arriving at the World Bank for the interview, I did my homework. I knew that most of the staff was international, with experience on overseas projects, and that it was a largely European crowd.

Everything I’d heard from people who knew the place was that there was this cavalier adventurous spirit to the people who worked in the World Bank, akin to the Peace Corps or the Foreign Service.

Illustration by Peter and Maria Hoey

I knew that in order to stand out, even as an engineer, I needed to mold my story closely to theirs.

Unfortunately, I hadn’t taught English in Chile, built houses in Uganda, or made myself useful on any other adventures. But I had lived overseas in England as a kid, and had the chance to travel. So I made sure throughout my interview to sprinkle that in and to speak on my plans to travel in the future.

I’m convinced to this day that’s what separated me from the many other engineers who applied for the same project.

Less is more

By this point, you’ve done the visualization technique where you envision yourself in the interview. You’ve done the research to understand the culture and mood of the office. You’re a qualified candidate, so you know how to dress. You’re probably pretty qualified to tell your story, too.

If you stopped here, you’d be ahead of most candidates. But if you want to really have mastery over your narrative, you must remember: less is more.

A study recently done by Michael Norton at Harvard School of Business drove this point home to me.

Before they started the study — which involved rating other people — participants were asked whether having more information about a person would make them more open to liking someone new.

Unsurprisingly, 88% of people suggested that the more information they had prior, the more likely they would like someone new.

But the data showed something very different. The more the participants knew of these perspective people, the lower they rated them.

The researchers tried this same study over and over again, even conducting a similar one where the participants were allowed to write down traits about themselves. They took this pool of traits — which were overwhelmingly positive — and divided them up into groups describing hypothetical people.

Even in this circumstance where the traits used to describe people were almost all positive ones, people who had a shorter list were generally better liked.

What the results of this study seem to imply is that when you leave something up to people’s imagination — and leave more mystery in your story — you’re more likely to leave a positive impression.

So figure out how to tell your story in as few talking points as necessary. By leaving more to your interviewer’s imagination, you’ll find that employers are more likely to feel the need to call you back.

Much of the advice surrounding the process of getting a job is in the form of a series of disparate tips about formatting your cover letter, making the right amount of eye contact, and other pieces of advice that seem to wax and wane with the times.

But preparing a strong personal narrative is the closest thing that Matt the Recruiter has found to timeless career advice. And it’s certainly worked for me.

If you liked this article, click the heart below to recommend it so more people will see it here on Medium. And check out Habits and Design my online publication interested in the intersection of data and culture.

The “D” word

We have a diversity problem in the community, and that’s been talked about quite a lot when it comes to tangible things like gender and race. A diversity of skill — an intangible thing — is also something we talk about struggling with.

While I haven’t been a different gender or a different race, I have been someone who has been a junior Ruby on Rails developer.

When I started out as a Rails developer, I was tinkering around with the framework in my spare time, which I had a lot of because I was single and working casually at Coles and doing the odd spot of PHP/Rails freelancing.

I heard that there was a Ruby meetup happening in Adelaide and I caught the train into town and ran to the meetup because I was running very late.

When I got there, people asked what I did and I told them about Coles, PHP and Rails. They said “you don’t need to work for Coles anymore” and three people gave me their business cards and said I should apply for a job. I applied for a job at SeaLink and was accepted.

At SeaLink, I got mentored by a team of “senior” Rails developers who had a whole bunch of patience for my 19-year-old antics. I am very thankful to them for the time that they spent mentoring me, as I believe it helped provide a foundation for a career that I’ve been doing for very close to 10 years.

There are plenty of juniors at the Melbourne Ruby Meetup. I know because I help run the Hack Night where a lot of them attend also. If a junior from this meetup was to tell you that they were actively looking for a job right now, would you hire them? Probably not. There seems to be quite an aversion to hiring juniors, and the main aversion is that juniors take up valuable shipping time with mentoring time instead.

In the early days, there was a lack of available talent and so companies had to hire whoever they could find. That’s why I found it easy to get a Rails job back then. I think we have once again reached that point where there just isn’t any talent to hire.

I’ve been having a lot of discussions recently in the Ruby community about why companies seem to be shying away from hiring juniors. Instead, these companies want to hire mid-to-senior developers and do not want to have apprentices who are learning alongside those mid-to-senior developers.

Lawyers, mechanics and plenty of other professions have apprenticeships, so why don’t programmers? It’s pretty strange. I think it’s because those professions have had turnover in their companies enough to learn the lesson about training for the future. This is still a young community where most people have been doing it for less than 15 years. We need to think long term about this: who will look after our code when we’re gone?

Hiring seniors

Let’s look at why companies want to hire mid-seniors in the first place. At the companies I’ve worked at, we’ve wanted to hire a new mid-to-senior person because our workload has gotten to the point where it’s exceeding our capacity. I figure that this is the same at other companies too. Like where I’ve worked — and currently work — you’ll have people breathing down your neck asking when bugs are going to be fixed or new features are going to be developed.

To address this problem, you hire a new developer or rather: you try to hire a new developer. You want a mid-to-senior developer because they have the skills to instantly dive straight into your application with little-to-no guidance and they can start shipping code.

However: the trick is finding someone who’s available at the moment. In this current climate, it’s nearly impossible to hire a mid-to-senior Ruby developer to come work for your company. What typically happens is that developers get aggressively poached between companies.

Companies spend thousands of dollars on recruiters and lots of time posting to job boards, for often very little good return. Companies spend this money to hunt the elusive 10x Developer Rockstar Unicorns, but the Unicorns are no longer out grazing in the sunny meadows, readily available for capture. They’re already working somewhere else and the conditions of where they work are extremely good.

We, as a community, have drained the talent pool dry.

We’re out of freely available Rockstar Unicorns and so it’s time that we started to grow our own.

Companies are addicted to hiring the top 5% or 10% of developers and ignoring the rest. There is a lot of great talent in the remaining group of developers, just waiting to be mentored. If they got that mentorship, we would be able to bolster our community’s best and brightest. What if the next person your company mentored went on to become your next CTO? What if they went on to be that “10x engineer” who can help out anyone on the team with anything? I really believe companies are missing out on great talent by completely ignoring it when it is non-obvious.

Too many companies are focusing on the short-term goals of shipping code, rather than the long-term growth of their teams.

Companies hiring the best-of-the-best — the people with proven great track records — and getting them to build what is essentially CRUD applications which do, at best, a fancy version of string concatenation.

If we speak in terms of hiring piano players: you’re hiring the Chopins, Bachs, Liszts, and getting them to play Mary Had A Little Lamb.

You do not need to hire senior developers. You need to hire developers of any skill level, mentor them and grow them into the next great bunch of developers. Give these people a chance and train them on real world applications that real people are using. These could be the next great people that your company needs and you are not giving them the opportunity.

Contributing back

You might be thinking: what do we (as a company) get out of this? I think that’s backwards. The thinking should be “we have earned so much from the community, and now it’s time to give back”. If you invest in the long term health of the community, it will pay dividends. In the long run, you will have an active talent pool of developers who will be able to maintain your application. In the short term, you’ll be bolstering your team’s productivity with fresh talent.

You may think that you need to hire these best-of-the-best badasses because your application is a large unmaintainable behemoth monolith and only the badasses can understand it. That you need seniors to navigate the spaghetti that is your legacy code. That may indeed be the case. But in every monolith, there is a tiny bit of functionality that a non-senior developer can work on improving along with their skills, when that non-senior is paired with a senior developer.

It’s OK to hire non-senior developers to work on real live production code. We’ve done it at Marketplacer and we’re still in business. Your company will not go down in flames because you hire a junior.

Yes, it’s risky. Initially the cost of the employee is greater than what they provide for the company. But with the right fostering, they can grow into the best asset your company has ever had.

Julia Claven has a great graph for this:

When the junior is initially hired, their dollar value to the company is less than the output they produce. With good mentoring, they can get the other end of the graph where their value to the company outweighs their salary.

There is an initial productivity hit — that’s true — but that plateaus out within 6 months if you do it right. At the end of it, rather than having one developer, you have two developers. Even if the junior is half as productive as the senior, then it’s still a 1.5x growth in the productivity of your team.

At Marketplacer we’ve hired juniors within the last year that I would consider to be very productive members of the team,and they’re great people to work with to boot. We would’ve missed out on these people if we didn’t invest the time in hiring and mentoring them and instead focused on only hiring seniors who had existing Rails app development experience.

You might be thinking, “but what if they leave?” That’s a risk you take with any hire of any skill level. If people are leaving your company, you should be reflecting on why they’re leaving in the first place. Was it really them, or was it your company? Does your company have a culture that someone would want to leave? Is your company focused on building a culture that people want to stay in, or are they only interested in shipping code?

Finding Juniors

Where can you find those juniors to start with? Well, let’s start with Code Academies. Not any particular one — although Turing is my favorite. Code Academies solve part of this lack of mentoring problem.

Code academies get new programmers to pay thousands of dollars to learn the tricks of the trade. Sometimes, these new programmers even get a “guarantee” from the code academy that they’ll get a job at the end of the course. The code academies teach these newbies a range of programming skills. At the end of this, the newbie programmers have enough skills to know the basics of things like HTML, CSS, JavaScript and Ruby and can usually find their way around a Rails app easily enough. These people are very “green” and then they’re thrust out into the community to work at companies.

Unfortunately, due to our senior hiring addiction, we’re not hiring these fresh faces. The code academies produce great talent, and we’re not picking it up. These people are left to struggle for months at a time in developing their skills before they can even get a look in at a company. I’ve spoken to many juniors in that position.

Not all of these graduates have the time to spend doing that skill development, as they often have full time jobs or other responsibilities to take care of. Thankfully, they get a lot of assistance from their code academies after they’ve graduated. Well, at least the good code academies do that.

I would love to see companies breaking their addiction to seniors and more actively hiring from these code academies. More companies need to make mentorship / apprenticeship a part of what they do. The students that graduate from code academies are eager to learn and are, in my experience, very highly motivated.

There are definitely juniors who have that same kind of eagerness-to-learn and motivation who have never been to a code academy. These people have learned by themselves and by being mentored by people in the community. I can think of at least 5, perhaps even 10, of these people who would make great hires in a company’s mentorship / apprenticeship program.

If I were in charge of hiring at Marketplacer, I would hire a motivated junior, pay them a wage well enough to live off and mentor them.

Asim Aslam (@chuhnk) had a good tweet about this too:

There’s a great book I encourage you all to read: it’s called The Talent Code. As the subtitle says “Greatness isn’t born. It’s grown.” The book covers how skills of all varieties are grown in sports, music and plenty of other areas. All the industries that are covered in the book have active mentorship and apprenticeship programs. Yet, this is not cared about in the programming community for reasons mentioned earlier: we’re still quite a young community.

I’ll let you in on the secret that’s in that book: for anyone to get better at anything, they need to practice the hell out of it. How do we expect to have seniors to hire if we’re not hiring juniors and letting them improve their skills by practicing on real world applications?

So many people are talking about mentoring and hiring juniors. Let’s start doing it.

Mentorship

Now that I’ve (hopefully) convinced you to hire a junior developer, you might be wondering what you do once you have one.

I help run the Melbourne Ruby Hack Night and it’s a judgement-free environment where anyone and everyone can bring along a Ruby project and work on it. Some people are even there for the first time learning about Ruby itself, which is great to see. These Hack Nights work because these new developers feel safe and welcome and that no question is too “dumb” to ask.

You can start mentoring at your company by fostering that Hack Night-esque environment. It should be OK to put up your hand and ask a question about anything. If the questioner is getting eye rolls, sighs, or other passive aggressive signals from someone else, then that’s not the kind of environment where a junior is going to learn.

A great way to build that kind of fostering environment is to encourage pair programming. Pairing with juniors on small tasks initially is a great way to build up their confidence. When I’ve been mentoring juniors, the number one thing that I find that they’re lacking isn’t the skill, but the confidence. They know the answer, but they aren’t sure if it’s the _right_answer. They question if they’re using the right syntax or even if they should be writing the code that particular way. When a senior pairs with a junior, they can encourage them to try out things and learn from the things that they try. If the junior gets it wrong, the senior can ensure them that it’s OK to get things wrong and to guide them back on track. Pairing is the quickest way to upskill a junior and I can highly, highly recommend it.

I paired daily with some developers when I worked at GetUp and in a few months time they were confident Rails developers who could find their way easily around that Rails application. I’ve done the same at other companies too and each time I’ve seen great professional growth in the juniors that I’ve mentored. One of the best feelings in the world is when a junior says “Ahhh, I understand!”.

Pairing also helps reinforce your own knowledge. If you can’t explain something to someone clearly, then you do not understand it well enough yourself. Pairing is helpful to the junior because they get knowledge out of it, but it’s also helpful to the senior: they learn how to share what’s in their brain with other people in a clearer fashion.

What should you pair with your junior on? Well, Lydia Guarino has some good tweets about that.

I agree with both of these. Juniors thrive best when they’re given quick wins. You want that nice tight feedback loop to keep their confidence growing. Every time they “win” at code, their confidence gets that little bit more boosted.

Once they’ve built up a bit of confidence, you can let them go solo on a task. There isn’t a set timeframe for when this happens; it’s all about how confident the junior is with their own abilities.

Let them loose on something small and make it clear that they can ask any questions about what they’re doing and that there is no wrong way of doing it. Once they’re done, get them to submit their work in a pull request — you might have to teach them what one is first — and then sit together and review it.

Sitting together is important here because “why are you doing this?” written in text has no emotion, compared to it spoken with body language. Juniors may interpret a “why are you doing this?” comment as aggressive like “UGH! Why are you doing this?”.

Focusing on in-person communication helps establish a rapport between the developers much better than text-based communication ever will.

If a junior has made a mistake in the pull request then you can discuss it with them and correct the mistake. This way, that mistake will never make it to a live production environment.

Code review also allows the senior to assess how well the junior has been doing on the tasks they’ve been given. If they’re doing well on a 2-day task, then it’s probably going to be OK to give them a 4-day task too. If not, then some more mentoring may be required.

Ultimately, your mentorship should be about making the junior feel welcome and safe within your team. In fact, this should be what’s happening with everyone in your team. Google ran a project that they called “Project Aristotle”, wherein they attempted to find how to build effective teams. They interviewed hundreds of their own employees and they came up with 5 things:

The #1 item on this list is “Psychological safety”: “Team members feel safe to take risks and be vulnerable in front of each other.”

Google is not special. They’re made up of people just like your company is made up of people. You should keep this in mind when mentoring your juniors, and working with other people in your team.

Thanks for reading! If you found this article helpful, click the green heart below.

This was originally published on my blog.