Systems Engineering

We build APIs

The systems engineering team primarily builds services and APIs that power the mobile and web apps we build for Vokal's clients.


The two primary languages we use to build API servers at Vokal are Python and Go. Python is a popular language for rapid development using frameworks like Django and falcon. Go is an increasingly popular systems programming language developed by Google; it's syntax is C-like, but offers type safety, performance, and a simple asynchronous programming paradigm.

In addition to Python and Go, you will likely need to write direct database queries. We primarily use Postgres as our database engine of choice, but most databases (including MySQL, MSSQL, Cloud SQL, Aurora, etc) use some flavor of SQL (or, Standard Query Language).

Finally, when dealing with Linux-style servers, you'll have occasion to write shell scripts to automate tasks. We have relevant code standards for all these languages:

Framework-specific standards and best practices are also documented for:

Core Skills

Systems engineers are expected to be self-directed in skill acquisition on these subjects, in addition to the shared core skills.


As systems engineers, we are also responsible for the deployment and operation of the servers we develop. We largely leverage IaaS from Amazon in the form of Amazon Web Services (AWS). You'll want to familiarize yourself with Vokal's existing tooling for devops, and be sure you've gathered important prerequisites from the client before kicking off development.

It's always wise to keep abreast of deployment platforms available since each client has different needs and budgets, however. Google's competing Cloud Platform IaaS also offers interesting services and tools (and often a price advantage).


Documentation is important—arguably as important as the APIs we build. Clear documentation makes it possible for iOS, Android, and Web engineers to use those APIs and build apps for our clients. Be sure to familiarize yourself with our API Documentation Standards and the GitHub-Flavored Markdown we use.

It's also very helpful to use git tags and mark commits that represent the state of the code that is released to production as a "release" on GitHub. Details about how to do so are outlined in the Release Notes documentation.


All code needs tests that cover as close to 100% as possible. If you build a feature or come up with a bug-fix, write tests that prove it works as intended. No patch will be accepted without tests, period; this is enforced company-wide, and helps eliminate bugs ending up in the wild.

We also have our own coverage reporting tool called cvr. For Systems projects, we expect at least 95% test coverage for a build to pass; you should configure this in the settings for your project on cvr.

Here are sample scripts you can use as examples to add to your project's .drone.yml file to report test coverage to cvr. Be sure to have a senior engineer add your project's token to the drone configuration for your project.


        - pip install -r requirements.txt
        - cd <projectdirectory>
        - coverage run --source='.' test
        - coverage xml
        - export CVR_URL="$DRONE_COMMIT&owner=$REPO_OWNER&repo=$REPO_NAME&prependpath=<projectdirectory>&coveragetype=cobertura"
        - curl -F coverage=@coverage.xml $CVR_URL
        - cd ..


        - pip install -r requirements.txt
        - nosetests -v --with-coverage --cover-package=app --cover-xml
        - export CVR_URL="$DRONE_COMMIT&owner=$REPO_OWNER&repo=$REPO_NAME&coveragetype=cobertura"
        - curl -F coverage=@coverage.xml $CVR_URL


        - go get
        - go get -t
        - go build
        - go test -gocheck.v -coverprofile=coverage.txt -covermode=count
        - export CVR_URL="$DRONE_COMMIT&owner=$REPO_OWNER&repo=$REPO_NAME&coveragetype=gocover"
        - curl -F coverage=@coverage.txt $CVR_URL