DEV Community: abhishekAthreya

How to ace your coding interview?

abhishekAthreya — Thu, 30 Sep 2021 07:22:06 +0000

If you are a new coder who wants to get his/her dream coding job or a experienced coder who wants to upgrade his/her dream coding job, read on! This post will help you.

Coding interviews may seem like a daunting task at first but there is a method to this madness, I promise. Here are a few tips to ace your coding interview -

Leetcode. Leetcode. Leetcode

If you want a one stop shop for all commonly asked coding questions leetcode is your best bet. If you can invest on the premium version, it helps. But the free one covers a wide array of problem types. Most tech companies (FAANG) included ask a lot of problems that are similar to the ones on leetcode. So practice away!

Here is a video walkthrough to one of the most fundamental question types.

Think out aloud

Most people assume that the coding interview is all about solving the problem, but nothing is further from the truth. Yes, it tests your problem solving skills but it is also a test of how well you are able to structure the solution and communicated it. Think about it - a large part of your role as developer is to structure the solution and communicate it with your peers!

Ask follow up questions

Most interviewers are impressed by inquisitive people. In a 45-60 minute interview session, the surest way to highlight your inquisitive side is to ask (relevant) questions about the problem at hand. It gives the interviewer the impression that you are trying to look at the problem holistically and covering all edge cases - all qualities of a great developer!

Most importantly, I want you all to appreciate the fact that you are qualified for your dream job! Technical interview expertise is an acquired trait which I am sure, we all can acquire if we put our minds to it.

Follow along my Youtube journey!

Buy me a coffee

Why should you build a portfolio?

abhishekAthreya — Wed, 29 Sep 2021 07:32:04 +0000

If you are a web developer and you don't have a portfolio... join the club! Many of us don't have portfolio websites. In this post I will try to convince you on why you should build a (kickass) portfolio -

Street cred

There is nothing that gives you more street cred that the fact that you can walk to talk. Knowing web development is not enough! You should be willing to do (web development)

Creativity

When are we building something on our own (especially something like a portfolio) we can open are creative wings fully! The sky is the limit for what we want to have on the site. You want a purple background with blue text? You can do it! You want an image without alternative text? Be my guest!

Enhanced learning

I personally believe that the best way to learn development is to actually get going with a project. Hands on experience is irreplaceable for us developers. So, the portfolio can be a nice way for you to pick up new technologies. If you want to learn next.js, try building a portfolio website with it! I promise you that the learnings will be immaculate.

Exposure

Personal projects such as portfolios are viewed in brighter light when it comes to hiring and contracting. Building a portfolio may open doors to more business or better job offers!

Beyond all these reasons, I think that building a portfolio is a nice way for us full-time developers to rekindle our love for building things from scratch.

Here is something to help you get started -

Buy me coffee

How to review code better?

abhishekAthreya — Fri, 24 Sep 2021 06:30:32 +0000

When I started working as a developer 5 something years ago, I was under the impression that code reviews were an unnecessary overhead from a developers time. I thought that the 'star' developers would only write code and everyone else would do the boring stuff such as reviewing! Boy, was I wrong! I realized fairly early the importance of code reviews. Hopefully this post will help you with your code reviews. Here goes -

Establish a review language with the team

I have seen that different teams have different strategies that work for them. There are teams that like to have very strict reviewing protocols while others like to keep the review conversational. One of the first things we can do as developers is establish that review language with the team. For my team, a conversational approach to the review works. We add comments on a piece that we have concerns about. The owner of the PR will then add clarifications or make the suggested changes. I have seen some teams have a formal review process. The reviewer adds comments and the comments are then converted into tasks that the owner of the PR works on/addresses. Find what works for you guys and stick to it!

Give suggestions not solutions

Code reviews are a nice way to foster technical thinking. Often times I have seen senior developers give the solutions to the problems that the find in the review. Although this might be beneficial in the short term as it is faster, it is problematic in the long term. By giving the solution you are revoking the owner's opportunity to stretch their technical muscle.
Ex - Say 'Hey! I think we are iterating over more records than we should. Is there a more efficient way to do it?' instead of 'Hey! I think we can make this more efficient by using the filter function provided in the utility package.'

Do collaborative reviews

We sometimes underestimate the value a collaboration session can have! For most complicated changes, one of the most efficient way to review is to set up a joint session with the whole team (owners and reviewers). In this session the owner of the PR can go over the change and explain the thought process that led to the change. That added context reduces review times by a huge margin. Our team usually has regular sessions in the week where we discuss new PRs. This is a fun way to add collaboration to the seemingly solo process of code review.