Job Application Platform

There are tons of services out there to find a new job, but none of them submit your application for you. This is where this project came in. A candidate can fill out a profile, including any skills and experiences they have. Once completed, they can set up “Auto Applications” that will run every day, finding and applying said candidate to jobs that match their skillsets against the job’s criteria.

What’s more is that this process also works in the reverse. A recruiter can set up an “Auto Application” for candidates, which will automatically find candidates matches their jobs so they may contact them for further details. They can even set a criteria percentage a candidate must meet or exceed in order to apply or will otherwise be immediately rejected.

The client was looking for a architecture that allowed frontend and backend developers to be able to work independently of one another. This required us to split up the app into an Angular (newest version) frontend served by a Ruby on Rails API.

We chose Angular for its use amongst enterprise companies, which is the type of company looking to run it after launch. It also offers everything we could need to build out a fully-featured frontend, including routing, requests, state management, build tooling, and more. Using TypeScript was a motivator to use Angular, as it’s a great language to work with and makes it simpler to iterate upon our work.

Our choice to use Rails is based on its ability to get up and running quickly, as well as the strong ecosystem it comes with. It’s also used by a number of their competitors, which only solidified this decision.

As one may have guessed, a large portion of this application is based upon search. So we used Elasticsearch to assist us in fetching the most relevant data to the user. This includes not only querying for jobs, but candidates and companies as well.

All of this runs through our CI / CD system build on top of GitLab, which automatically runs our tests and deploys when they pass. This provides a small layer of abstraction in the development and deployment process, allowing developers to focus on what they do best–writing code.

The biggest challenge with this particular project was the client / stakeholder. While we expect most projects to have some hiccups and a few changes during the development process, we don’t expect development to be continuously turned on its head.

If we were building a house, they would continually change the layout of the first floor as we’re working on the third. Part of it was due to a lack in setting proper expectations during the on-boarding of the project, but a much larger part was the client referring to his “wishlist” as absolute features rather than the agreed upon scope. Despite a number of setbacks, we were able to deliver them a working product our team was proud of.

When it comes to technical challenges, the auto application was the hardest part. I can’t go into detail on how it works, as it’s the core of their business model, but can tell you it took quite some time to get it working based on specific skill criteria. But to make it run as efficiently as possible, we ran this process in the background so as to not block the main thread and cause any kind of noticeable delay to the end-users.

There were four developers working on this project, with myself overseeing the merging of the front and back ends. While I did get involved in a vast-majority of the frontend build, I primarily spent my time in Rails and helping my teammates where I could. I did transition off the project towards its tail-end to get cranking on the next app in the queue–a food delivery service.