Don't disqualify yourself

Companies are looking for good developers!

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

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, this post’s content is from a developer’s perspective 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, forums, 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.

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.

Make a song of your profile

Does your GitHub profile play a song?

Public activity can give you additional points. But it’s not a requirement. Your experience and skills are more important for most positions.


Be brief

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

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

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

Keywords help quick matching candidates and positions.

Add your LinkedIn, GitHub, blog, and any other relevant links in your profile, facilitating your interviewers’ triage. Unlikely, recruiters and hiring managers will put the time to search about you on the web.

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. I suggest that besides adding those to the Websites section, there’s no harm to also adding 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

It’s easier to sympathize and create connections when we see each other.

If you are comfortable adding your photo to your profile, do it.

The same applies to video interviews, turn your camera on if possible.

View profile as

After changing your profile, try to access it as a profile viewer instead of a 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 being rejected does not mean you aren’t qualified. 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 people aren’t prepared for it, 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 equivalently 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 it. 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.