It's crazy how many people I know that don't keep an up-to-date resume! I had an HR rep ask me for a copy of my resume for a project we were working on and he was completely shocked when I handed over a professional, up-to-date, ready and raring to go resume to him within 10 minutes. I got a bit of a quizzical look like: 'That was fast. You on the market bro?' to which I give back a 'Nah brah, we coo' sort of look.
I mean, I get it. Resumes are boring and if you're comfortable with your job, then why keep one up to date?
- Just because you like your job doesn't necessarily mean your job likes you.
- Who knows when that next great opportunity may flop across your desk and it closes in one hour. Do you submit a rag or submit something your proud of? I'd prefer to do the latter.
As a guy that keeps their LinkedIn fairly up to date I get even more annoyed updating my resume because I'm just maintaining my resume in two places. I realize that LinkedIn has a neat 'save as pdf' feature on your profile but it really misses out on several of the important aspects of a developer resume that most HR groups want to see such as certifications, 'skills' / programming languages / technologies. Those are important!
Then there's the issue of standing out. Developer resumes are boring AF. Even mine goes a little like this:
Proficient in many bleeding edge languages such as Node.js, GoLang, Kotlin, ErLang, and Ruby
When most established companies want to see something like:
200 years’ experience in .NET and/or Java
Which is ridiculous as no one has that kind of experience and in the new fancy web, who wants to type 500k lines of code to achieve the same functionality you could in 100 lines in Node?
INB4: Exaggeration / Performance / ETC
I had an API built with Java/Spring that was 80k lines of code and when my team dwindled from 3 to 1 during the most recent downturn, I was making literally 0 progress per day. So I converted the entire API to Node with Express and Sequelize. My code base went from 80k lines to ~ 20k lines. My middleware to decode JSON tokens and to do permissions checking when from 3 - 5 java classes and swing configurations to 2 10 line chunks of node middleware. I've got no regrets for my I/O API migration. Anyways, back to business.
What exactly am I getting at here? I'm getting at differentiation of your submission over someone else’s, and have some fun doing it so that you don't go crazy and burn right out trying to make a bunch of text on a page look appealing.
That's where I'm at today, so I'm going to outline what I'm going to work on over the next little bit and fill people in on the idea and process.
Since I'm a backend developer with a passion for Project Management, I'm going to go ahead and layout my plan for developing a project to convert my boring PDF Resume into a neat functional REST API and then probably wire up a quick SPA app so people can browse it without being a computer. Anyways without waiting too long, here's what I'm planning on doing laid out in a super professional and official project charter.
RaaS Project Charter
1. Project Name:
RaaS: An Epic Resume As A Service
To create a RESTFul API to represent my resume to potential employers in a way that is less boring than a traditional Resume. This will help me keep my sanity when re-writing resumes over and over again and may even provide me with some new learning experiences
A RESTFul API that will allow prospective employers to browse my resume directly through the internet.
The only stakeholder is a tough son of a gun named Me. He'll be quite difficult to manage in getting this project successfully off the ground.
5.1 User registration and Authentication
Users should be able to register for accounts and authenticate against the API in order to make changes to their resumes and only their resumes.
5.2 Resume Creation
Users will be able to create and manage their resumes with a structure to be outlined in more detail in the Project Scope Statement
5.3 Resume Access Tokens
Users should be able to generate Access Tokens to distribute to hiring departments to access their resume. These tokens should be usable for one resume only and should be able to be revoked at any time. Access tokens provide read-only access and should be handled on an application-by-application basis (i.e. one token per company applied to) This will help users keep their security up to date!
This project will commence on Friday, March 30th 2018 and complete no later than Friday April 13th for obvious reasons. (I can blame delays on superstitious bad luck)
I assume that I'm going to have the time to get this project done in a reasonable amount of time.
Fatherhood, work, working out, I've got this great book to read, summer's coming up. Easter's coming up, this is a for-fun project, and all that jazz.
9 Decision Making Process
Probably a legal pad with a PROS vs CONS list
10 Project Authorization
Now that we have that out of the way, I'm going to go ahead and plan the stack I want to use. This is actually the hardest part of any project I've ever worked on.
- Node: This would get me up and running in no time. It's lightning fast for development and I have several projects running in production with Node. That being said, been there, done that, what else?
- Java / Spring: Spring Boot has made dev in Spring fast. Like really fast. You can have an API up and running simply by creating your model classes, building interfaces that extend a CrudRepository or PageAndSortingRepository and you'll be pretty much ready to go. I'm not sure what's changed with implementing stateless authentication or implementing a token-based authentication scheme, however this could also be a viable solution.
- Notes: Swagger has a plugin for Spring that looks for @RestControllers. This would get rid of the functionality of the CrudRepositories but would make documentation of the API a breeze.
- GoLang: I like golang, I don't have any projects running in GoLang, why don't I try to do something in golang?
This is less of an issue than one may think...
You can use any assortment of libraries to make dev a breeze. Since all objects are treated as JSON classes, almost everything is plug and play with a couple of database idioms to worry about.
- MongoDB: Mongoose's functionality has made MongoDB my go-to when using Node. I started playing with MongoDB YEARS ago and loved the flexible schema. My projects typically evolve and being a small (individual) team, this allowed me to make changes on the fly. I don't have any projects that are insanely large so I can't speak to scaling, performance, etc. etc. but it's not let me down yet! This isn't a crazy project either so I doubt I'm going to worry about scaling.
- SQL: MySQL, PostgreSQL, SQLite... they all play nice with Sequelize..
- CouchDB: Nano has made this a trivial task in node as well.
In previous projects, Spring went hand in hand with Hibernate which went hand in hand with SQL variants. Reading has kept me in the loop with new MongoRepositories which may take away from the pain and suffering involved with original Mongo queries in Java, but I've not played yet. I'd probably stick with SQL if I take this route.
Since mgo stopped being supported and there's no official driver for Go, SQL is looking to be the best bet I think!
Since I'm not REALLY focusing on a front end for this project, I'm going to ignore the front end which would have come down to Angular vs React - Since I know angular quite well and I really want to learn React. I'll cross that bridge when I get there.
Check back for Part 2 where I dive into my stack selection and get started on the codes.