Don't disqualify yourself

Companies are looking for good developers!

But sometimes due to the lack of experience in interviews or for never having been on the other side (as an interviewer), some good developers get disqualified.

The intent of this post is to give some tips to help developers to present themselves better.

I’m a developer, I’m not a recruiter or HR person. Therefore, the content of this post is from a perspective of a developer interviewing and filtering developer candidates to work with.


Make a good first impression

Try to make the README of your projects as clear and objective as possible, it’s the first content that people see when they access a repository.

A well-written README can tell how good you are at sharing knowledge and explaining problems. Like a good team player should be.

Usually, good writing skills don’t happen naturally, you have to practice them. You can use READMEs, Wiki pages, and blog posts to exercise these skills.

Not so proud of some of your code?

So you have some code that you aren’t super proud of? Don’t worry, everyone has.

But if an interviewer asks you something like: “Is there something that would you like to have done differently in this code?”. Take this as an opportunity to impress him by acknowledging the code weaknesses and explaining how you could have done it differently with the knowledge you have now, it can cause a huge good impression.

As a good practice, I suggest to review your projects from time to time. Do you know that boring Sunday, in which you don’t have anything to do? Well, why not spend some time practicing code refactor in old projects?

Make a song of your profile

Does your profile play a song?

If you don’t have any public project or activity (or a GitHub profile). You may lose some points compared with candidates who have, but it’s something you can overcome while telling about your experience.

P-l-e-a-s-e, don’t say that you don’t have public projects or activity because the company that you work for doesn’t support open source. IMO open source is much more an individual initiative than a company one. If your company uses open source, it supports open source, but it doesn’t mean that your boss will tell you to spend working hours in open source, just to make you a better GitHub profile.

Engage users

It’s very positive when a candidate has projects with stars on GitHub, it shows that he’s doing projects with impact in the open source community.

People can’t use, what they don’t know. If you developed something that can be useful for other people, share it. A blog post, Reddit, Stack Overflow and Twitter can help you with that.

On a side note, remember to star (like) the projects that you use and like on GitHub, it motivates the project owners and also gives credibility to the projects.

Why so many forks?

If you aren’t contributing to a project, you don’t need to fork it. If you only want to play with it locally, you can clone it from the original repository.

A profile full of forks without contributions to them can pollute your real activity, hiding your own code. And at least for me, it commonly raises a question: “Why is this person doing so many forks? Does he know how it works?”.


Be brief

Detail your mission and achievements for each one of your experiences, as very other article will suggest. But there’s no need to write a letter for each one of them, be brief on the details. If an interviewer gets interested on a specific experience, he will ask you during the interview. And I also recommend to use something like “Main technologies”:

Full stack developer lorem ipsum dolor sit amet, consectetur adipiscing elit.

Main technologies:
Ruby, Rails, MongoDB, EC2 and SQS.

It helps for a quick matching between candidates and position requirements.

Add your GitHub, Blog and other relevant links in your profile, facilitate your interviewers’ life. Don’t make them to Google you to find your GitHub.

LinkedIn has a specific section in which you can add links, but as a profile viewer, you need to click on Contact Info to access them. Did you know it? Maybe some interviewers don’t. My suggestion is to besides adding those to the Websites section, there’s no harm to also add them to your Summary.

My summary lorem ipsum dolor sit amet, consectetur adipiscing elit.

* GitHub
* LinkedIn
* Blog https://your-name

Try to get a when possible, that helps when googling you and sharing your links:

Hey Pablo,

Could you have a look at these two candidates:



Which one makes a better first impression, John Something or 123456?

Don’t be a default avatar person

You need to show your face out, interviewers want to see you. It’s hard to sympathize when there’s no face.

The same applies for video interviews, remember to turn your camera on.

View profile as

After changing your profile, try to access it as a profile viewer instead of profile owner. LinkedIn has a “View profile as” button for that.

Before the interview

Compatibility matching

If the position is for a “Full stack Ruby developer”, candidates with this title, will be prioritized over “iOS and web developer” ones.

A (brief) cover letter (our a LinkedIn summary) is also a good place to expose the matches between you and the position expectations.

Be organized

Make some notes on what you would like to bring during the interview, whether telling about you or asking about the company.

You don’t need to use your notes as a teleprompter. But you can create some clues for frequently asked questions, such as:

Prepare yourself in advance to answer them well.

Research the company

Visit the company website, check the about page, mission, and values.

If they have a public list of values, try to match with yours and expose it during the interview.

Research your interviewers

Interviewers research and talk about candidates to work colleagues. They spend a reasonable amount of time preparing themselves for an interview.

I strongly recommend to all candidates to give it back by also researching on them before the interview.

Once when I was participating in an interview process as a candidate, and I found a presentation from my next interviewer, in which he was talking about why the code in Node.js often gets rejected in coding challenge submissions. How lucky was I?! I had a chance to review my code challenging, which coincidently was written in Node.js, and also bring some topics during the interview that I knew he was interested in.

It’s also nice to say something to your interviewer like: “I saw your blog and I found your post about X interesting” or a mention of a project that he’s working on GitHub. You don’t need to lie if you didn’t like what you saw, feel free to keep that yourself or to consider if he’s the type of professional you want to work with.

During the interview

Remote interviews

Close IMs and everything else not related to the interview that might distract you. Give all your attention to your interviewer. It’s terrible to interview someone and see or hear that he’s typing to someone else.

If you like to make notes during the interview, use a psychical notepad, and handwrite, otherwise he may think you are typing to someone else.

On making notes, if your interviewer likes to talk, let him talk, but make notes on the topics he’s talking about. So when it’s your time to talk, you can return to all relevant topics he mentioned during his “speech”. Showing that you are a good listener and organized.

Rejection notice

No one likes to be rejected. But I would say that in most cases being rejected, does not mean that you aren’t qualified enough. Hiring is complex, it involves people and subjective perceptions, you can get rejected for various reasons.

What can I do better?

Feel free to ask for feedback to do better next time. But don’t get disappointed if the company can’t give you one.

Although some feedback can be constructive, most of the people aren’t prepared for, and some rejections can be because of details: “He seems to be an experienced developer, but he was typing to someone else during the interview. The next candidate I interviewed is equivalent experienced and gave me his total attention”.

It’s hard to give feedback on subjective perceptions.

Final thoughts

As a friend of mine used to say: “Doing well at interviews, only proves that you do well at interviews”, you need to practice it, the more you do, the more you get good at. There are a ton of people that do much better at interviews than at work. If you are a good professional, don’t let them disqualify you.