DEV Community: Aman Gautam

9 blunders I found in 90% LinkedIn resumes

Aman Gautam — Fri, 31 May 2024 07:16:02 +0000

When I recently posted a job role for entry-level developers for a project, Time Budd, I found some common mistakes which made me immediately reject the candidate.

I acknowledge that most people improve on these mistakes as they progress in their career — which thankfully is great!

Not everyone who is rejected is rejected because of the things they control. For instance, if the employer is looking for 2 years experience and you are graduating in 2 years — your application may be rejected even if it is a perfect fit otherwise.

Disclaimer: I must have made mistakes!

I have also applied for roles in the past where I felt like I am a perfect match — just to receive a rejection email later. When you apply for a role online, the chances of you getting a call are always slim.

The person reviewing the resume is operating out of their own biases (I reject resumes that are using Comic Sans without second thoughts).

Also, the company is itself trying to go from point A to point B and looking for people to help with that. If the company needs a JavaScript developer — you can be great at Python and still not get a call.

Mistake 1: Diluted Expertise

All humans are multi-dimensional. They can be good at writing code, playing guitar, coming up with great pickup lines… All at the same time!

A person is going to be reading that resume to see if you can help them with a ONE outcome — could be engineering a solution, creating social media presence, handle customer support requests, etc.

Anything that isn’t directly or indirectly related to that outcome is a distraction and more likely to work against you. When I am looking for a community manager — I care about the fests you have organized. When I am looking for a backend developer — I don’t care.

Mistake 2: BS Claims

So, you made a landing page that increased the company revenue by 40%? Nice! I also fixed a bug in Samsung S3's contact app that led the model to 80 million sales across the world and made it the most successful galaxy series phone, ever. Nice to meet you!

It is always great to mention the impact you created. Exaggerating the impact a bit isn’t a deal-breaker either. But when you take credit of other people’s work, it may be interpreted as

You don’t value other people’s work in the team, or
You are not aware of what impact other people had

So, if you made an API that could handle 50K requests/second — mention that. Don’t try attributing it as the sole reason for the success of the project.

Mistake 3: Nothing Original

[This advise may not be applicable for all the employers]

If you’ve also made a Netflix clone, a YouTube clone and XYZ clone… Congratulations! You just solved what is already solved.

If you have solved 300 Leetcode problems — Congratulations! You just spent months solving problems that have been solved successfully millions of times.

Creating clones and solving DSA problems are good projects to learn the basics — but what is the point of those basics if you are not applying them in solving something for yourself or people around you.

There are plenty of problems to be solved around you. Solve them using the knowledge that you have. If you create a simple time table creator that is used by your college, it is way better than an end-to-end Netflix clone that doesn’t serve any purpose.

Build for people around you! Build for yourself. Nothing else prepares you better for what’s coming…

Mistake 4: Nothing Deployed

There are plenty of ways to deploy your code and allow people to use it. If you have worked on 5 projects and none of them is live — it is sad.

A GitHub repo with the whole project pushed in 5 commits or less isn’t going to help either. If you expect someone to:

Clone your repo
Install dependencies (or pull docker images)
Set environment variables
Debug and test your work (sometimes behind a signup)

Ain’t nobody got time for that! Just push it to a free live server and make it easy for people to trust your work.

Mistake 5: Crappy Typeface

I know why I still need to add this… but bad typefaces are more common that I expect.

I understand that developers take pride in building ugly stuff, but please make your resume an exception, at least! If you don’t understand how to choose typefaces — just pick up some clean resume template off-the-internet and customize it with your content.

Mistake 6: Still Sending .docx

Just because you can, doesn’t mean you should.

Thankfully most people now send PDF, but still some candidates are sending docx file. Here are the problems with this approach:

The hiring manager needs to download your resume before they can review it. [At least on LinkedIn] — Don’t make it harder for us than it already is.
You probably made the docx on MS Word — it will likely look different on Pages app in Mac. All your work to format the docx is down the drain.

Always export your docx to pdf before sending.

Mistake 7: Adding Your Picture

Everything in your resume should ideally increase your chances of getting a call. Add your photo only and only if:

It is required by the employer or
Your picture increases your chances of selection

Of course, If you’re a famous person in your industry and more people know you by face than by your name — add your photo.

It is way easier to discriminate against you, if your face is visible. [Most hiring managers don’t want to — they can’t control their internal biases]

Mistake 8: Using Hyperlinks

Most people are not aware of this. LinkedIn resume preview doesn’t support hyperlinks.

So instead of saying: Made my personal website
Try something like: Made my personal website (https://aman.pro)

Yes, it will add more characters, but it makes it far easier for hiring managers to visit the links you have shared (since they can copy paste the link).

Mistake 9: Positioning Yourself as Generalists

In the context of a early stage engineer trying to break into the industry — generalist here means someone with good grasp over the DSA and System Design basics. These candidates can be trained on most technologies.

In the current economy, things are changing rapidly and there is a race to move faster. Which is putting people who are only good at DSA or System Design at disadvantage.

On one hand we have Person A who is a generalist who can be trained on Angular in 1 month v/s another person, B, who has already showcased their Angular expertise and they can be pushing things to production in week 1. In the current conditions, B will have more demand.

PS: Yes, when the hiring scene gets better, more generalists will be hired.

Closing Remarks

It was heartbreaking to see some not-so-recent graduates who are still looking for entry-level jobs!

Economy is a hard and we are going through an important transition in the way software is built and maintained. Please continue upskilling and solving real problems…

The ones who will stick around and evolve during this period will have great rewards once things are better at the macro level.

I have done my bit of hiring in the past decade, but I am not a resume expert. If something in the post doesn’t sound right, follow your gut feeling.

Soft(er) skills that make you a better programmer

Aman Gautam — Thu, 08 Feb 2018 08:04:17 +0000

I’ve been writing code for almost 11 years now. One thing I am completely sure of is that for being a really good programmer, you have to do a lot more than write code. Being great is simple (not easy!).

Here are some important practices that can make anyone a better programmer.

Write it for other humans

Write code for a junior developer who will come to fix issues in your code 2 years from now. This means:

Choose better variable and function names
Explain why(not what) the code does what it does using inline comments
Write better commit messages
Have a README with installation guidelines and coding guidelines
Treat documentation as an integral part of code base that needs constant review and refactoring

Write your codebase as it will be managed by an idiot in future, because eventually, it may be.

PS: Optimising code for machines is important too, but try to abstract that from fellow homo-sapiens.

Write test cases

The best products I’ve worked with have had test coverages between 85–95%. It clearly looks like a big commitment, specially when you’re an indie developer.

It’s not possible to test everything, but at least write test cases for the parts that are likely to fail or change over time.

Writing unit or integration test sometime seems like an expensive affair, but at the end of the day they are always cheaper than fixing issues making it to production.

Stick with your tools

It takes considerable work before you get comfortable with your tools (ex IDE). It takes even more work to make a tool part of your subconscious.

Surprisingly large number of developers change their tools, languages, frameworks on a very frequent basis. I am not against getting the experience of working with all these tools, but I am surely against switching these on a very regular basis.

It’s doesn’t have to be a marriage between you and your tools, but you shouldn’t be having too many one night stands as well. Settle down for some time, kid!

Deploy it!

I’ve lost count of projects that never saw daylight. Most developers have two amazing personality traits:

Perfectionist: The part that doesn’t let you launch anything short of perfect
Procrastinator: That doesn’t let you make anything perfect Don’t let these traits take over and stop you from launching even if you don’t have a good product. Don’t let your dream app die in a private git repo!

Defend your best practices

If the doctor washes his hands before doing your examination, that is considered normal (in fact, a good practice).

But if a developer wants to write test cases before writing actual code, many employers/clients find it weird.

Each trade have some good practices that should be followed religiously. Sometimes being a great salesman is the pathway for being a great programmer. Sell your best practices!

Your client/employer may not know about the best practices in tech. It’s YOUR responsibility to educate them and, if required, even tell them what may happen if you don’t follow the best practices. (It’s ok to scare them with an historical example or two).

Learn a new programming language

Learn a new language every year. If you can use it for work, Awesome! If not, that’s ok. A new language won’t just give you an additional skill, it will also give you new ways to think.

For example, coming from Java and C++ background, it took me some time to digest the fact that we can run a program in PHP without a main function.

After working on PHP-Apache based urls (e.g. home.php), Python’s way of implementing routes and URIs was almost a shock for me.

Learning a new language will help you question the standards in your current language.

Call to action

If you could change one thing about your programming practices, what will it be? Change that. NOW.

PS: The article was originally published here