PENSCO Software Engineer Work Sample Test

Greetings, and thank you for your interest in joining our team. This work-sample test is administered in lieu of the much-hated whiteboarding session that is so common in our industry. Our goal is to strike a balance between asking you to spend personal time on our interview process and getting us enough high-signal information to assess your skill and to provide us with a starting point for our on-site discussions.

Overview

Develop a simple web app with a RESTful backend that provides for the ability to purchase some number of shares of a publicly traded stock (think AAPL, FB, OPB) given an investment amount and stock ticker symbol (ex: OPB).

Requirements

We ask that the following guidlines are met in the final submission. Note that these requirements are rather loosly-defined so as to give you choice in your implementation. We do expect the API to define distinct resource(s) that the UI will integrate with in order to handle creating the stock purchase. This should be architected as if it's a small component of a much larger system.

User Interface

We're using modern Angular (version 2+) at PENSCO, but we do not necessarily want to impose that restriction on you for this test. The choice to use a framework or simply vanilla JS is yours. Additionally, we will not be looking for fancy styling, so please don't worry about that. Using zero CSS or even just default Boostrap or something is completely fine.

• accept both a stock ticker symbol (ex: OPB) and an investment amount in USD (ex: 1333.37)
• include a mechanism to asychronously submit the data to the API in order to create the purchase
• provide the user visual feedback on any success or failure from the backend

Backend / API

Most of our services are written using NodeJS (current LTS version) and leverage the Express framework. We encourage you to use this stack too, but we'll accept and review submissions in other languages or frameworks too.

This API will need to provide for the ability to create a purchase of stock (to serve the UI's needs), but will also provide additional endpoints that are not necessarily required to be wired up to the UI. Make sure your solution allows a user (user being defined as someone interacting with the UI directly or something integrating directly with the API endpoints) to do the following:

• create a stock purchase given the data the UI will end up submitting
• retrieve a stock purchase given it's unique identifier
• retrieve a listing of all stock purchases known to the system (no paging required, just list)
• retrieve a listing of all stock purchases known to the system that match a given stock ticker symbol

In order to create the purchase you'll need to know the stock's current market price. Luckily, there exists a free public API to provide this information. You will need to integrate with this API in order to complete the backend implementation. Obviously you'll also need to persist the stock purchases in order to implement the required features. Don't stress too much over this and just choose something/anything simple. Wanna serialize JSON to disk? Fine. Wanna throw in SQLite? That's also fine. It's up to you.

Code Quality

There should be some effort made to ensure that the systems operate as expected and can be maintained with relative ease should a future fellow developer need to add something, fix a bug, ect. How this is acheived is completely up to you.

Final Submission

Project should include reasonable spin-up instructions so fellow developer can get going quickly. We use yarn for our Node/Express services. If your submission requires dependencies outside of the NodeJS/NPM ecosystem then you should assume that your reviewers laptop will need a setup script that pulls down and configures all the dependencies (for instance, if you submit a DropWizard API do not assume the reviewer already has maven/gradle installed or remembers the colloquial 'start up this Java project' commands).