DEV Community: Jordan Burroughs

6 Tips That Will Fix Your Interview Anxiety

Jordan Burroughs — Tue, 19 Oct 2021 15:44:28 +0000

Interviewer: "What are your strengths?"

Me: "...I'm hard-working I guess?"

Ever since I first started interviewing for part-time jobs, I dreaded the behavioral interview.

But years since then, I have grown to usually enjoy the interview. The enjoyment comes from experience and by implementing a few simple techniques to help guide you through the process.

My goal is to explain the methods that helped me grow more comfortable in interviews (as well as land a few jobs 😏). After all, the more comfortable and confident you are in the interviews, the more likely you will clearly articulate your points and come off as the perfect person for the job.

First I will explain the impact of the behavioral interview, then I will describe six ways to level up your interview skills.

Impact of the Behavioral Interview

If you have not already jumped straight to the tips below, I think it is best to explain just how important the behavioral interview is.

I value the behavioral interview higher than the technical. Granted I am not the greatest in technical interviews, but behavioral skills will have the greatest impact on the team and company you are joining.

At some point the value of technical skills fade because it is usually comes down to "either know something, or you don't". Once you do, however, you can adapt to new patterns and practices easily.

For example, in my current role everyone knows Java to some extent. I may not be as advanced as one of my teammates, but it won't be too hard to catch up given that I have a firm grasp on the fundamentals. It mainly comes down to how good I am at learning something, which is a behavioral skill.

Technical skills are necessary to excel in any profession, but behavioral skills are the foundation of who you are as a professional.

Now that you see the importance of the behavioral interview, let's jump into the tips. 😁

⒈ Relax, View it as a Conversation

Early on I thought of the interview as a test the interviewer puts upon me. It is actually a test for both you and the interviewer.

They are "testing" you to see if you fit the role and you are "testing" them to see if you want to work for them!

Although, in reality it is just a conversation. This changed my perception about interviews. Have you ever watched a celebrity interview where there is no connection between the celebrity and the host? It comes across as inauthentic and even painful to watch at times.

When you notice that there is a connection between the host and celebrity everyone is having a great time! The host is thrilled and going off-script, the celebrity guest is relieved that "this isn't the usual interview, and the audience is loving the authenticity and personality of the guest.

Wouldn't you rather have a job interview like the second scenario?

Removing the idea that this is supposed to be testing you immediately eases the pressure you face in the interview.

⒉ Smile 😁

Seriously, smile 😀. It is amazing that doing something this simple provides such a great benefit. You will come off as more excited, cheerful, and personable. Who wouldn't want that in a worker?

Why do we love dogs and babies so much? Because of that irresistible smile that infects us even when we may be in the worst mood.

One of my favorite books "How to Win Friends and Influence People" by Dale Carnegie covers just how important putting on a happy face is. Check it out, it's a classic 🔥

What if my interviewer is all business, and doesn't even hint at a smile?

Don't get intimidated! Smiling eases tension and eventually they will give in. I have had countless cold-mannered people crack by just staying positive and continuing to smile. Deep down we all want to.

Smiling makes us all feel good and will even put you in a wonderful mood. Even when you are talking on the phone, smile. Trust me, it is easy and can make all the difference.

⒊ Have Points-of-Conversation Prepared

Early on, one of the biggest issues that made interviews hard for me was not having much practical experience to talk about. That is why you should have points-of-conversation prepared ahead of time. These should be 3-4 projects or instances that demonstrate different skills you have applied to achieve certain results.

For example, using Java and Spring Boot to develop a user service on a small team or the process of initializing, planning, and executing a presentation to incorporate a new technology in an existing application. Find points to discuss from your résumé; instances that you can discuss in fairly strong detail and comfortably answer questions about.

In behavioral interviews, questions are usually the same (minus the weird outliers about the company itself or "how many windows are there in NYC"). Typical questions will revolve around your strengths, weaknesses, problem solving skills, and communication/team skills. When looking at the list of points you can discuss, you will be able to extract these skills from them.

⒋ Use SAR

Once you have your points-of-conversation, you will quickly find out that you need a way to organize and articulate your thoughts. We all know the feeling where we are excited to know all the information, but it comes out as a jumbled mess (like the first drafts of my blogs) because we did not take our time and organize our thoughts.

That is why it is crucial to use a procedure like SAR to formulate a good response. SAR stands for:

Situation - outline the situation by providing general background information to help set the scene. This includes the project name, what kind of group you were in, what you were assigned to do, etc.
Action - explain the actions you took. This should be an easy to follow, step-by-step process that begins to address the question the interviewer asked.
Result - describe the result. Tie everything together and clearly answer the posed question.

Note: SAR is sometimes called STAR where the "T" means "Task" (which extends "S" is SAR)

SAR is analogous to writing - introduction, body, and conclusion.

One book I highly recommend is "Cracking the Coding Interview" by Gayle Laakmann McDowell. (I talk more about it here. In the "Behavioral Questions" chapter, Gayle goes more in depth about how to approach the interview and explains SAR with with great examples.

⒌ Focus on Yourself and Highlight Successes

This is a pretty quick one. Interviewers are not there to hear what specific thing your partner did on the project. You are the one being interviewed, not your past teammates!

Also, the interviewer wants tangible, quantitative evidence of success. It is easy for anyone to say that they updated an existing REST API, but it will put them over the top if they add that "efficiency increased by 30% and load in the database decreased by 15%".

Lastly, if you received some kind of recognition, awards, or certifications, let them know! You are selling yourself. They want to hear that stuff and will put you over the edge 😎.

⒍ Ask Good, Open-Ended Questions

I wanted to end with this tip because it is how every interview finishes: the Q&A section. After all that stress they put on you, the tables have turned - you are interviewing them 😈.

Take advantage of this part! The interview is not over. You should expect 5-15 minutes for your questions to be answered and try to use as much of that time as possible.

This part is crucial because you can now steer the conversation in whatever direction you want and leave a lasting impression with the interviewer. You can Google for an endless number of great questions to ask, but just make sure they are open-ended and can lead to follow-up questions. Thus adding to the conversation and increasing the rapport between you and the interviewer.

Final thoughts about the Q&A:

If you know who your interviewer is ahead of time, ask questions related to their role or personal career.
Instead of asking "Is something...?", ask "How is something...?" to make it open-ended.
Know basic facts about the company you are interviewing for. Don't ask something that can be answered by Google.
Keep a long list of questions to ask ahead of time. You can also add to that list during the interview.
Have fun and take advantage of the opportunity.

Conclusion

Take the tips explained above and try them in your interviews. If you have a tip, leave it as a comment below.

Also, don't totally disregard the technical side! It is easy be focused on either just the behavioral or just the technical side, and not both! Make sure to give yourself enough time prior to interview day to properly prepare for both portions.

Maybe, once I get better at technical interviews, I will blog some tips for those... 🤔. Until then, see ya.

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Stay in the L(OOP) with Object-Oriented Programming Basics

Jordan Burroughs — Sat, 09 Oct 2021 13:22:01 +0000

"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
-Edsger Dijkstra

Whether you love it or hate it object-orientated programming (OOP) is one of the dominant models in the field. In college, the meaning and concepts of OOP were constantly drilled into my mind. Even in some job interviews I was expected to know these fundamentals off the top of the head. That's why I think it's important to discuss them now.

Presenting these concepts will allow me to introduce a newbie to crucial high level knowledge, and provide a quick refresher to anyone who is already aware of these ideas (and even help myself achieve a deeper degree of understanding).

In this blog I will briefly describe OOP and broadly explain its 4 main concepts: abstraction, encapsulation, inheritance, and polymorphism. I come from a Java background so I will sprinkle some Java in to expand on some points.

Note: My aim is for the following explanations to be general. Rather than showing the same examples and code that everyone uses, I'm going to present from a different perspective.😁

What is Object-Oriented Programming?

OOP is a computer programming model that organizes software design through the use of objects and classes.

Objects are the basic units of OOP. They can emulate real-world entities, like a dog, table, or car. That means they can hold data and perform behaviors.

An object's data is implemented using fields, and behaviors are implemented using methods.

Classes are simply blueprints for an object. They define the state and behavior that the objects can invoke.

Objects are instances of classes

Here is a quick example to show these relationships:

1. Abstraction

The process of abstraction hides unnecessary details from an object and shows only essential attributes. Therefore, a limited amount of information is exposed to the user for interaction.

For example, when driving a car, you don't worry about inner workings of the engine or understanding how the tires steer your car. All of that is behind the scenes.

You simply interact with the basic mechanisms (provided by the interface) to do what the car is supposed to do, like pressing the gas and turning the wheel. You don't care how these operations are carried out.

It is the same in OOP. For example, if you instantiate an Airplane object and invoke its function to prepareForTakeoff(), all you know is that the Airplane will prepare for takeoff. However, in the code, other things could be happening as well, such as testing the wings and running diagnostics on the engines.

Abstraction is achieved through the use of abstract classes and interfaces in Java.

Abstraction == Implementation Hiding

2. Encapsulation

Encapsulation protects object data by wrapping it in a single unit, allowing for modification and visibility to be controlled. Rather than directly accessing the data, you must invoke a function that modifies or retrieves it for you. This adds a crucial layer of security for the object.

For example, if you have a table object with public fields, you would be able to set the fields any time you want. You may think that it wouldn't matter, but what if you set table.legs = null somewhere accidentally? That could break the entire object and application (because it's no longer a table).

However, if you encapsulate that field in a setter (setLegs(null)), you can add a check that ignores setting "legs" to null, thus hardening the application.

Encapsulation is achieved through the use of access modifiers (i.e. public, private, protected) and getters/setters in Java.

Encapsulation == Information Hiding

3. Inheritance

Inheritance allows one class to derive data and behaviors from another class. The main benefit of this is for reusability, thus saving time and effort while making the code more readable.

For example, a Student class and a Teacher class can be children of a Person class. The Student and Teacher inherit fields (firstName, lastName, dateOfBirth) and methods (doWork(), goToSchool()) from the Person class.

The Student or Teacher classes now have access to the Person data and methods. So any objects that instantiate these two classes can invoke them as well (if they are public).

In Java, inheritance is achieved by "extending" the parent class.

4. Polymorphism

Poly-what?? Honestly, it sounds cooler than it actually is.

Polymorphism is the condition of occurring in several different forms.

In OOP, polymorphism allows data or methods with the same name mean different things in different contexts. But what does that even mean?

Take a look at the inheritance example once again. Since both Student and Teacher inherit doWork() from the Person class, they can both call it. We can also have them implement their own way to "doWork".

A Teacher can grade papers
A Student can study

This is known as overriding the method from the parent class. Now whenever a Teacher object is created and the doWork() function is called, the Teacher will "grade papers". And if a Person object was created and calls doWork(), it would just "read a book".

Another case where you will see polymorphism at work is through overloading a method. Overloading is achieved by changing the number of arguments and/or changing the type of arguments in a method.

For example, in a class called House you can have the following methods:

paint()
paint(String color)
paint(String color1, String color2)
paint(boolean usePrimer)

Conclusion

The explanations for these four concepts are very general because I wanted to make these as simple as possible. Leave a comment below with any other words of wisdom regarding these topics, or OOP as a whole. Thanks!

If you want a deeper insight on how these ideas are implemented programmatically check out these links from "GeeksforGeeks":

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Don't Use Create React App Until You Know This

Jordan Burroughs — Sun, 03 Oct 2021 15:10:36 +0000

The other day a co-worker noticed something interesting about our production code: You could view our original, perfectly formatted code in the browser. At first I was like, "But I built it for production, and therefore it should be minified and unreadable, right?"

I always thought Create React App (CRA) handled that for me. Have I been lied to the entire time?

Source maps.

Yes, source maps were the reason. So I learned about them and thought it would be nice to shed some light on them so others, like myself, become aware of them and make more informed decisions.

What are source maps?

When building React apps with CRA, you are basically using webpack and babel to transpile, minify, and bundle the JavaScript/TypeScript code you wrote for deployment. During this process your files are manipulated in a way that they need a mapping to be put back together in the original form. That's where source maps come into play.

Source maps are just JSON files that essentially rebuild what the bundlers and transpilers changed. Their main purpose is to help debug your built, optimized code.

It makes sense that if you have a bug and view the stack trace, you want to see your code and not the gibberish that webpack and babel spit out.

Why Does The Browser Show Everything?

The environment variable GENERATE_SOURCEMAP=true by default in CRA. That means once you build, the generated folder there will be extra ".map" files generated. It will look something like this:

The browser can then use the .map files to reconstruct the original code, and become viewable in browser dev tools.

When GENERATE_SOURCEMAP=false, the same code would look like this:

Here's what the CRA docs say:

Should I Generate The Source Maps?

In the end, what am I going to do? Leave the source maps in or take them out.

Personally, I believe it depends on your requirements, but mostly yes. I think CRA has it correct (as in by default, they are generated, but can be overwritten).

Below I've identified some points about generating source maps to help make your choice:

For not having them:

A savvy user could see your source code 😬

For having them:

So what if they see your code? What are they gonna do with it? 🤷🏽‍♂️
It helps debug in production.

Yep, that's basically it. It seems to come down to whether you care if users see your source code and if you want to have the ability to debug in production.

Important Note: If you generate source maps, there are going to be extra .map files created. Although, these do **not* add to the bundle size because these files are only requested by the client when dev tools are open 😏*

Conclusion

Let me know how you feel about generating source maps for production. Do you disable them, or leave them be?

Also, if you want to fact check me, I'm all ears to understand more about source maps.

Check out these resources I used to get learn about source maps:

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Bookmark These 8 Front-End Websites Now!

Jordan Burroughs — Wed, 29 Sep 2021 12:46:07 +0000

Now that I've been working with front-end web frameworks professionally for over 2 years, I can confidently say that I mostly know what I'm doing.

Through this journey I've come across many useful resources and websites that have been extremely valuable to my success.
Here is a list of useful resources that I recommend every front-end developer has bookmarked (especially for those new in the space 😊):

⒈ CSS-Tricks

This website has all things CSS, including articles, videos, and my favorite, the guides. Every time I'm designing UI, and forget how flexbox or grid works, I regularly come back to the guides on the subjects that provide fantastic visuals and simple explanations.

Always comes in handy.

⒉ cssreference.io

The name says what it is, but ccsreference.io isn't your old, boring documentation. They get straight to the point by showing many CSS properties in a neat and clean format that's easy on the eyes.

Each CSS property is given numerous examples right beside them to help you efficiently get the information you came for.

What else do you need from reference docs?

⒊ Coolors

Liven up your personal website with a unique and alluring color scheme. This website has grown ever since I started using it, but the main feature I use is creating your own palette (see above).

Experiment with random colors to find the combination that you like best and then use the provided hex colors to implement them in your own projects. Not only is this useful when working with front-end apps, but any time you're designing and styling anything.

⒋ Unsplash

We've all been there. You got to the point where you have all the scaffolding done for your app and you need to start adding content. It's easy to add "Lorem ipsum..." for text, but for images, you have to go through the process of Googling for images ensuring they're the correct size, free, ecetera.

Unsplash helps you by providing high-quality, "freely-usable" images that are easy to add to any project or blog (like this one 😀). When downloading images you can also choose the size (small, medium, large) to fit your need.

Amazing resource for every front-end app 💯.

⒌ Alligator.io

Alligator.io was a recent find for me. It's like a front-end technical blog with many contributors. The topics include React, Angular, Vue, CSS, JavaScript, etc.

Stay up-to-date on current technology trends along with guides and tutorials to level-up your front-end skills. Definitely worth a bookmark.

⒍ Awesome

What? A Github repo? Okay, calm down and explore the rest of the README to see the priceless resources this repo provides.

This is the end-all-be-all in resource lists. Basically, it is an endless, community-curated list of resources. And it isn't just one repo.

Here you can find other repos where people have their own topical "awesome" lists ranging from Nodejs and Python to ones about interview questions and design.

I shouldn't say this, but rather than searching through blogs like this (which I greatly appreciate btw 🙂), check out "awesome" because it has been curated over for years by many, many kind and knowledgable people

⒎ Brand Palettes

Brand Palettes is a database of brands and their colors. That's pretty much it. Nonetheless, it is an cool resource to have in your back pocket.

⒏ Documentation! 📄📄📄

To be honest, from all of the online material I have cycled through, there is (usually) no substitute for the actual documentation of whatever technology you're using.

For any technology you use (i.e. a framework, library, etc.), take some time and actually read their documentation. It's usually not too extensive and you will discover things about the product that you've never noticed before. Doing this will help you re-think your current, future, and past projects because of the ability to leverage a feature you never knew existed.

I've read through React, Angular, and React-Query docs (just to name a few) and continue to do so with other tools. Just trust me. You won't regret it.

Note: Some docs are great and some are terrible. Some are too complex and some are too simple. But, it is usually the most up-to-date and accurate information you can get.

It's very easy to read the docs and still not understand a topic. That's why I like using the docs as a roadmap for learning. Once I hit a topic I don't fully comprehend, I use other online resources like videos and articles to fill in the gaps. Then when I return to the docs, I get that "aha" moment we all love.

Conclusion

There are endless amounts of useful resources out there, so if you have any recommendations, let everyone know in the comments. I would love to add a few more bookmarks myself.

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

1 Tip to Double Your Productivity in Postman

Jordan Burroughs — Sun, 26 Sep 2021 00:04:57 +0000

I've noticed when testing authenticated endpoints in Postman that every time my token expired, I needed to take a new token from my POST /authenticate endpoint and copy-and-paste it into each of my requests. This can quickly become a tedious process when your token's TTL is very short.

So I came across a quick-fix that has helped me save time by completing this process in just one click, and I wanted to share it.

The Solution

1) Start using environment variables!

Rather than explicitly entering the value into fields, take advantage of Postman's environment variables. There are different levels of variables (see here, but I like to keep my projects organized by creating different environments.

You can even set up for different environments (i.e. dev, sandbox, prod)

To add to a field, just surround the variable name with double curly brackets: {{token}}.

Now all of your variables live in one place.

2) Create a post-request script

Now you can set the environment variable using a post-request script. Under the endpoint tab where you get your token (usually a POST to an authentication endpoint), click the "Tests" tab.

This is where you can do all kinds of things (check out the snippets on the right side). However, in this case, we are just setting an environment variable.

Add this script to the panel:

const token = pm.response.json().token;
pm.environment.set("token", token);

Note: Your authentication endpoint response may have a different structure so make sure in Line 1 you are referencing the correct token property.

Now any time your token expires, you just call this endpoint and the token returned will be used everywhere it is referenced (i.e. all your protected endpoints).

Conclusion

I understand that this probably isn't the best way to do this. Please share a better solution in the comments! It would be extremely helpful for everyone.

Also, I know that I never use Postman to its full potential, so if you have any useful tips on Postman in general, please share those as well!

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Git vs Subversion

Jordan Burroughs — Wed, 22 Sep 2021 16:06:13 +0000

Git isn't the only option!

When I was first posed this statement, I was completely caught off guard. What do you mean Git isn't the only option? How else could someone track their changes and work on source code as a team? In my short software engineering career, I've always assumed that Git was the best and only answer in the realm of version control systems (VCS).

That was until at my job, I was made aware that one of our projects used Subversion, or SVN for source control. What even is that?

The main difference between Git and SVN is that Git is distributed and SVN is centralized. The way these two architectures are implemented amplify what the real differences are.

In this post, I'm going to explain what Git and SVN are, give a brief history of each system, analyze some of their advantages, and address some common questions that I personally had about them.

Quick note: There are other version control systems out there, but these are two of the most popular and relevant to me. I will briefly identify some alternatives later on.

What is a VCS?

A version control system is software that helps developers efficiently communicate and track code changes over time.

Using a VCS provides numerous benefits such as improved code transparency (who made the change, what exactly was changed, when the change was made), faster product development, and assists in disaster recovery.

What is Git?

Ah, the one we all know and kind of love? I personally have a love-hate relationship with Git. It annoys me when can't remember what and how "set-upstream" works, but I always appreciate that it has my back when need to trace that bug that was introduced in a previous commit weeks ago.

Git was created in 2005 by Linus Torvalds and other developers of the Linux kernel. Yes, The Linus Torvalds creator of Linux. After Linus found that current source-control management systems could not meet the scale of the Linux kernel, he prompted the start of Git development.

Git is a distributed VCS, meaning that you have to clone the entire central repository (repo) to make a change. This ensures that when making your changes, you have the entire history of the code in your newly cloned local repo.

After you have made your changes, you can merge them with the branch that everyone refers to as the 'main' branch on the central repo. For anyone that now wants the latest code changes, they need to update their local version of the code by pulling the new changes from the central repo.

Git focuses on the file changes and metadata, rather than the entire file tree. It uses optimized algorithms and sophisticated compression techniques to ensure great performance.

So Git is Github, right?

Nope. Although they may sound the same, these guys are completely different. In short, Git is a system for managing source code changes and Github is a cloud provider for hosting Git repos (among many other features).

Anyone can implement Git in some way, but one of the services Github provides is hosting your central repo. So as long as Github is online (knocks on wood), all of your code and its history are safe on their servers and can be accessed anywhere you have an internet connection.

What is Subversion?

So what is this Git alternative you speak of? Well it's called Subversion, or SVN for short.

Predating Git by 5 years, the SVN project was started in 2000 by CollabNet to create an open-source VCS. It aimed to improve upon the revision control system called Concurrent Version System (or CVS). Since 2010, SVN has been developed by Apache Software Foundation as well as becoming a part of the Apache Top-Level Projects.

SVN is a centralized, network-aware VCS. Therefore, all of your data is stored on a central server and the only way to access it, is via a network connection.

The process of making code changes is slightly simpler than Git, with one less step. Rather than cloning the entire repo, you get a working copy directly from the central repo. Then you commit those changes to the repo where you can merge them.

Pros of Git

Stashing Work. Git allows users to take their current code changes and "stash" them to be accessed at a later time.

I've used this feature many times when working on one thing and something with a higher priority comes through the pipeline. I simply stage and stash my changes, complete the new task, and pop and apply my stashed changes to continue where I left off.

Easier merging. This is what Git was made to do. It was built for teams and communities to better manage all of their code changes.
Works offline. Unlike SVN, when you have the entire repo on your own machine, you don't have to be connected to a server to make any changes. You simply can make the changes without connection to the central repo, then once back online, you can then merge your changes with the central repo.

Pros of Subversion

Handles binary files. Both SVN and Git use a model called Copy-Modify-Merge. This is fine for mergeable files, but SVN also uses the model of Lock-Modify-Unlock which is perfect for un-mergeable assets like binary files. No concurrent modifications can then be made on these files.
Simpler. SVN removes the step to clone the entire repo to a client's local machine before making changes, eliminating a huge step in the Git process. Your team all works from one repo.
Access Control. (This is my favorite feature of SVN)
Have you ever noticed that everyone with access to a Git repo all have the same user permissions? In certain enterprise settings this is a huge no-no. SVN actually allows for granular path-based user permissions enabling you to allow/deny users to read/write specific folders and files.

FAQs

Why is Git so popular?

There are many aspects that could contribute to the popularity of Git. Those include:

The dominance of Github influenced many users to naturally adopt Git
Its fast branching and merging capabilities
Its ability to enable users to work on code offline
Its scalability
Linus Torvalds started it

What are some other VCSs?

Mercurial - a free, distributed source control management tool.
CVS (Concurrent Versions System) - a centralized VCS.
Fossil - a simple, high-reliability, distributed software configuration management system.
GNU Bazaar - a distributed and client–server revision control system sponsored by Canonical.

Conclusion

So which should you use? I can't be the one to tell you that, but I can tell you that I prefer Git for almost everything.

Although, it's good to know the useful alternatives out there that utilize the centralized and distributed architectures. There's always a good solution depending on your use case.

If you are a beginner, I would just start with Git because it is the most widely used VCS.
If you've been using Git for a while, try investigating some of the other VCS mentioned. Just knowing they exist can be very helpful if there comes a time when your looking for one for a specific use case.

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

4 Books Every Junior Software Developer Should Read

Jordan Burroughs — Thu, 16 Sep 2021 01:59:59 +0000

If you decide to click away after seeing that I recommend the same titles that every other article tells you to read, I wouldn't blame you. Although, there is a reason why these books resonate with nearly all software developers that read them (and not only beginners).

This post will be different because I will be giving you a brief explanation on why you should read them and what you, as a new software developer, should expect to get out of them.

This is a post that I know would have been helpful to me when I first started looking to enhance my new career not too long ago.

So I was (and still am) in your shoes. Without further ado, here's what you came for:

1. Cracking the Coding Interview

by Gayle Laakmann McDowell

Whether you are currently looking for a job or whether you are perfectly happy in your current role, this book is an absolute must for any dev, especially juniors.

Not only are there endless amounts of practice problems with detailed solutions, but the first sections of the book dissect the entire interview process and give quick concept overviews that anyone could find useful for reference, or even last minute cramming (which I would NOT recommend doing, but it doesn't hurt to fill that need).

I first got this book in college to prep for internship interviews and ever since then, I see myself always referring back to it whenever another interview is coming up, or when I need a quick refresher on certain topics.

From behavioral and technical interview tips to data structures and algorithms, this one has it all. 13/10 would recommend.

2. Living by the Code

by Enrique López Mañas, Ray Wenderlich

This one was pretty interesting and unique. The authors basically interview top developers and innovators in the tech space and they give advice to young developers.

What else do I need to say? You get advice straight from the horse's mouth.

But here's what I love the most:

Each interviewee is usually asked questions related to their specific field or domain, but there is also a set questions that the interviewer asks everyone. Among those is: "What are the 3 books (or resources) that have had a lasting impact on how you do your work?" The authors then list that person's recommendations at the end of each interview!

In the end, you have an endless amount of resources that you can use to spawn new areas of interest and help naturally guide you in the beginnings of your career. From this book alone, my reading list has expanded tenfold and yours can too, as soon as you pick up this book.

Good starting point to boost your career. 12/10

3. Clean Code: A Handbook of Agile Software Craftsmanship

by Uncle Bob (Robert C. Martin)

Ah yes... the quintessential classic. This book appears on every software dev book recommendation list. It is pretty much the bible for clean code that is a must read for everyone in the field.

I read this coming out of college and for me, it was a revelation. In school they teach you the basics of programming, computer theory, and maybe even some assembly. But, Uncle Bob teaches you importance of clean code and the advantages of adjusting your style to fit it.

Hallelujah! 14/10

4. The Pragmatic Programmer: From Journeyman to Master

by Andy Hunt, Dave Thomas

Let's finish off with yet another classic. With a seemingly endless series of topics (and smaller tips within those) the authors analyze many different aspects of software development and how to think beyond if-statements and for-loops.

From the perspective of a beginner, you can't get much better than this. There are so many tidbits of information, that any time you reread this book, you'll learn something new to apply directly to your code and career.

Learn exactly what it means to be a Pragmatic Programmer, you won't regret it. 13/10 - exceptionally pragmatic.

Conclusion

One common theme with all of these books is the idea that you will always find your way back to them throughout your career. That is why it is crucial to get them in your library ASAP.

There are many other books I have read that didn't make this list (including some non-technical books that can make an overall impact on your life), but let's start with these guys for now.

I'm always open to book suggestions, so leave a comment with some of your good reads.

Remember that it is never the wrong choice to invest in your education! The time and money you spend to better yourself now, will always payoff big in the long run. 😀

DEV Community: Jordan Burroughs

6 Tips That Will Fix Your Interview Anxiety

Impact of the Behavioral Interview

⒈ Relax, View it as a Conversation

⒉ Smile 😁

What if my interviewer is all business, and doesn't even hint at a smile?

⒊ Have Points-of-Conversation Prepared

⒋ Use SAR

⒌ Focus on Yourself and Highlight Successes

⒍ Ask Good, Open-Ended Questions

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Stay in the L(OOP) with Object-Oriented Programming Basics

What is Object-Oriented Programming?

1. Abstraction

2. Encapsulation

3. Inheritance

4. Polymorphism

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Don't Use Create React App Until You Know This

What are source maps?

Why Does The Browser Show Everything?

Should I Generate The Source Maps?

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Bookmark These 8 Front-End Websites Now!

⒈ CSS-Tricks

⒉ cssreference.io

⒊ Coolors

⒋ Unsplash

⒌ Alligator.io

⒍ Awesome

⒎ Brand Palettes

⒏ Documentation! 📄📄📄

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

1 Tip to Double Your Productivity in Postman

The Solution

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

Git vs Subversion

What is a VCS?

What is Git?

So Git is Github, right?

What is Subversion?

Pros of Git

Pros of Subversion

FAQs

Why is Git so popular?

What are some other VCSs?

Conclusion

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶

4 Books Every Junior Software Developer Should Read

1. Cracking the Coding Interview

by Gayle Laakmann McDowell

2. Living by the Code

by Enrique López Mañas, Ray Wenderlich

3. Clean Code: A Handbook of Agile Software Craftsmanship

by Uncle Bob (Robert C. Martin)

4. The Pragmatic Programmer: From Journeyman to Master

by Andy Hunt, Dave Thomas

Conclusion

Thanks for reading my first ever blog! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶