Let’s get real, for a minute. We have all had to battle that cold front and feel it. You’re in an interview, both your palms are a little sweaty, and you just delivered the textbook definition of a relational database or the SOLID principles.Both hands are slightly sweaty, you’re in an interview and just recited the textbook definition of a relational database or SOLID principles. You’re feeling pretty okay. You got the theory right!
Then the interviewer leans over and says, “Okay, so tell me about a time when you really had to get your broken API integrated in a way on a tight deadline?”
Silence.
This prospect should give everyone pause, but it doesn’t have to. It’s the age-old struggle for any budding techie – theory vs. practice. As a kid, we’ve been taught to learn the rules and then win the game for years. However, in the tech industry, the game has changed.
We are in a special position at Net2Aspire, best staffing agency in USA. We’re not merely teachers, we’re talent developers. Interview with hiring managers, CTOs and recruiters in every week. We understand the reasons behind why they say “yes” and “no” for a candidate. So, let’s have an honest discussion about why it’s more important to get your hands dirty than have a clean theory book.
The main thing we must establish is that theory is not devoid of use. Far from it. Theory is the map. It provides information on where mountains are, where rivers run and the topography. If you don’t have a map you’re walking in the wild.
Yet employers don’t hire you for the map! They’re employing you to run around on the land.
You’re learning in a vacuum when you are learning theory. Controlled variables are the reason a formula works. A sorting algorithm is efficient since the data set is clean. However, the real world is one in which things become messy. Legacy code refers to real-world code written by a person who has departed from the company three years ago. No textbook ever mentions the edge cases or the inconsistency or the dirty data, about which real-world data is abundant.
If the employer queries your experience, they are not checking your memory! They’re pushing your body and testing your endurance. They want to know if you have ever gotten frustrated because of some bug that took 3 days to fix. They want to know if you’ve ever had to deal with the stress of having a production server crash. Experience is something that you can’t fake, and cannot be acquired through reading a pdf.
Consider what employers will expect of you. Hiring is expensive. A poor hire can be a business’s wasting of resources, from lost days of training to lost productivity. They cannot afford to just hope that you can put it into practice. They need proof.
Enter the “Hands-On Project” and this is now your strongest card.
A fouled up but working app on GitHub that is better than a resume that reads “Proficient in Python“. Why? The repository demonstrates the process. Illustrates code structure, commenting, error handling and iteration.
We do not recommend our students to create an application to record their “To Do” list. Even me, I have a To-Do app. Just as I have a To-Do app, everyone does! We ask them to construct something that will solve a micro-problem that is presented to them. Create a script to organize downloads folder automatically. Install a system to monitor electricity consumption. It shows you have command over your tools to the point where you can bend them to your will, rather than just following a tutorial step-by-step.
How does this work in Coding? It is applicable for reliability.
If you have never written code in an IDE (Integrated Development Environment) and you’ve never deployed it to a remote machine, then you have never witnessed deployment chaos. You don’t know what it’s like to merge a branch and watch the build fail. You learn how to write a loop in theory. Projects help you to learn how to revert a bad commit at 5pm on a Friday using Git.
Hands-on experience is an asset to employers due to trust. It tells them that “This is a candidate that has been in the trenches, they know the difference between ‘git pull’ and ‘git fetch’ etc. they will not panic when they see a merge conflict”.
If you’re working on a real project, even if it only has three users, you have to think about things like security (even sanitization of the input), performance, user experience, etc. These are not theoretical constructs. These are actual obstacles which determine the goodness or badness of your software.
So then, do you drop off the books and begin coding recklessly? No. We believe in project-based learning, but sometimes bad habits can form while doing unguided exploration.
The magic occurs during the synthesis. Here’s how Net2Aspire, best staffing agency in USA, is looking to overcome the difference:
It’s important to note that in today’s tech hiring world, particularly for software, data science and DevOps positions, your portfolio will be more important than your GPA. The degree to get your resume past an Applicant Tracking System (ATS) is that hiring managers check using GitHub or your portfolio. They want to see how you structure your code, how you document your process and how you handle your commits. A “real” project and a “real” user are the best proof of authority and practical competence.
This is a very “normal” obstacle. The idea is to refrain from consuming and to engage in creating, but on a micro level. Don’t attempt to develop a large application – consider micro-projects first. Learn a new concept (such as a particular Python library or React hook) and put it to use for a small, but real, problem. E.g., create a script that renames files in a folder or a simple web application to record your daily water consumption. It isn’t about creating the next Facebook: it’s about developing the muscle memory of active problem solving.
Absolutely not. The foundation for good projects is theory. If you don’t know the “why” of a framework or algorithm, then there is a practical limit to your skills. Theory is essential to help you understand and troubleshoot intricate problems, as well as design scalable solutions. It’s as simple as theory being the map, and projects being the terrain. Employers respect a person who can navigate the areas that are open to them, but to navigate you need a map in order to know what to expect. The most useful are termed “T-shaped”, possessing deep practical skills in one subject area, with a wide knowledge of the underlying concepts.
It doesn’t have to be a large project to be a good project! The three words that hiring managers seek: Relevance, Problem-solving and Polish. First, the project should be relevant to the job they are applying to (e.g., a data dashboard for a data analyst job). Second, it needs to address a particular problem—don’t create a generic tutorial clone (such as a “To Do” app). Rather, create something which automates a irritating process for you or addresses a weird pastime. Lastly, “polish” implies that the README file explains your thought process, you deal with error gently and logically, and your code is logically organized.
The section of your resume titled “Projects” is used to replace a professional experience section. Write a listing for each project similar to a job listing, with the Project Title, Technologies Used, and 2-3 bullet points for each project that show the impact or the specific challenges that you surmounted. Try to employ action verbs such as “Engineered“, “Designed“, “Automated” or “Optimized”. If your project is up and running, add a hyperlink to the site where your project is deployed or the repository, if it is a project repository. By using this framing, recruiters also have evidence that you have already been a developer, even if you did not have a job title.