Build A Get-Hired MVP
Since March 1st, I’ve been systematically working on getting my second frontend development job. The backbone of my plan is publishing a portfolio of small projects. Each project on my roadmap is designed to do one (or more) of the following:
- Increase the perceived value of hiring me
- Reduce the perceived risk of hiring me
- Increase the probability that I get invited for interviews
Projects that demonstrate fundamentals (e.g. writing your own implementations of functions) are the kind of projects that reduce the perceived risk of hiring you. If you’re not completely qualified for a role, projects that demonstrate fundamentals suggest you will be able to quickly get up to speed and you probably need less “hand-holding” to get there. All else equal, that makes you a less risky hire.
On the other hand, projects that demonstrate your ability to implement the specific concepts, tools, and technologies a role requires is what gets people excited about hiring about you. They increase the perceived value of hiring you.
Maintaining a popular open-source project is a popular way for senior developers to increase the perceived value of hiring them. But not everyone has the time and ability to build and maintain an open-source project. So what’s the alternative, especially if you’re a time-constrained junior or mid-level developer — you build a minimum a viable project, which I colloquially refer to as a Get Hired MVP.
A Get-Hired MVP is the smallest project that you can build that demonstrates the concepts, skills, and technologies required for a specific job (but not so small that it’s more of a code challenge than a project).
The name Get Hired MVP isn’t meant to imply that the project will get you the job. It might. But its purpose is to get you invited for interviews. You still need to have your narrative, answers to common interview questions, and code-challenge skills all on deck.
A good Get-Hired MVP is typically intentionally over-engineered. By over-engineered I mean, technically, the project resembles a large production-ready application, but practically, it’s a simple project. Or as Kent Dodd said:
“The goal is to mimic the configuration of a large real-world application without having all the extra complexities of a real-world application.”
An example of a good Get-Hired MVP is the “Sick Fits” project you build in Wes Bos’ Advanced React course. It’s small enough that you can build it relatively quickly, broad enough to demonstrate conceptual competency, and deep enough to suggest sufficient technical competency. The main difference is that your Get-Hired MVP should not be a tutorial project, it’s something that you conceptualize and build yourself (or ideally with the help of a mentor), from scratch.
Of course, if you have the time, you could go big and build something like this, which I’m guessing would eliminate any doubt most hiring managers would have about hiring you for a mid-level frontend job. But if you’re time-constrained, you can almost certainly get invited for interviews with a more minimal project.
I knew from Day One that a Get-Hired MVP would be the capstone project of Level and Launch — I just didn’t know what to build. That changed this week.
My friend Sebastian, who was the lead developer when I was at Aperto an IBM Company agreed to be my Get-Hired MVP project mentor. With his guidance and my research, I figured out what I’m going to build and I have a rough plan to get it done.
For my Get-Hired MVP, I’m going to build an interactive dashboard with React. The project’s name is React Interactive Dashboard (not the most creative name, but at least it’s clear). Long story short, I’m going to use React, Redux, and friends (e.g. React Router) for the frontend. The first-iteration backend will be a node.js REST API with either MongoDB or MySQL for storage. In the second-iteration, I’m going to build a GraphQL proxy in-between the React app and the REST API. Finally, the project will have a test suite that includes unit tests, integration tests, and continuous integration.
It sounds like a lot, but remember, it’s intentionally over-engineered. I’m not getting too crazy in terms of requirements and design. Instead, the requirements are relatively simple and practical. I will invest the time saved (as a result of reducing the project’s complexity) in crafting it like it’s going to see production.
I’m using Kanban Flow to manage Level Up and Launch’s sub-projects. There was a TDB ticket in my backlog reserved for my Get Hired MVP. Earlier this week I converted the TBD ticket into a ticket titled “React Interactive Dashboard.” I pasted the ticket description below; it includes a rough project plan.
As React Interactive Dashboard will be an Agile project, the details are subject to change, but this is more or less where I am going with the it. I can’t wait to start and get it done.
In summary, a Get-Hired MVP is a tool for learning and self-promotion (especially getting invited for interviews). It should be practical, probably intentionally over-engineered, and customized to achieve your goal. Once it’s done it should be your go-to code sample if someone asks for one. Best of all, after you find your new job, you can stay sharp by enhancing your Get-Hired MVP or rewrite it using whatever the hot new language or library of tomorrow is.
React Interactive Dashboard Project Plan v1
Project Purpose
To learn how to build full-stack React apps, prove it, and increase my chances of getting invited for job interviews.
Project Requirements
- It should display data by fetching it from a server
- It should allow the user to summarize the data (i.e an overview page)
- It should allow the user to see a detailed view of the data (i.e. drill-down)
- It should allow users to edit the data via simple forms and save it to a da
Project Strategy
1. Build the minimal version required to get invited for interviews and not more.
2. As much as possible, prioritize features that will add the most value upfront. If you run out of time, you will have built the most valuable project that you could have with the time you had.
Project Stack
Bold items are required. All other items are “nice to haves”.
- HTML (Structure, semantics)
- CSS (Layout, styling, transitions, animations)
- Emotion (CSS in JS library)
- React (UI library)
- React router (Routing)
- Redux (State management)
- Formik (Form handling)
- Redux Form (Form handling)
- TBD Redux Async Library (Async data handling)
- GraphQL (Data handling)
- node.js (Server)
- MongoDB or MySQL (Storage)
- ESLint (Linting)
- Prettier (Formatting)
- TypeScript (Type checking)
- Jest + React Testing Library (Unit Testing)
- Cypress (E2E testing)
- Circle CI (Continuous integration)
Project Timeline
The project will start on 1 APR 2020 and, ideally, will be finished by my deadline to start applying, 1 MAY 2020.
If the project is not done by 1 MAY 2020, I will make a judgment call about further development. There will be two options. Option A is continuing development until the project is good enough to compete for mid-level SPA developer roles. Option B is pausing development and focusing on job applications (including code challenges).
Project Workflow
This subproject’s workflow is the same as described in the main project’s README.md. The main points are:
- The project is managed using a mix of Scrum and Kanban
- Intervals (i.e. sprints) are one week to ensure tight feedback loops
- There is work in process limit for “In Progress” items
- Retros are mandatory and must include a published write up
