Engineering at Cadmus

What is Cadmus?

Cadmus is an online environment where assessment can be created by Teachers and completed by Students. It offers Universities a brand new way of conducting assessment, that will help to improve teaching and learning outcomes, including, but not limited to, academic integrity, student experience and graduate outcomes.

What does the Engineering behind Cadmus look like?

As a Software Developer on our team, you will be helping expand the Cadmus platform to reach millions of University students in the World, tackling the engineering problems related to scale along the way. Our platform houses an ecosystem of rich front-end applications which include environments for learners (Students) and teachers (Academics/Lecturers). These drive the core Product experience.

Front End

The front-ends are React based clients, managing their states using various strategies including Redux. The client data flows through GraphQL APIs and Web Socket streams. We value GraphQL because it provides a Type System for the APIs, and we love Types. These clients have complex requirements of being progressive (offline first) and connection agnostic. Leveraging modern Web APIs and understanding core browser technologies are essential. Our main Student client is built around a React based Rich-Text editor. If you are familiar with the difficulties in applying an immutable programming model to a ‘Content Editable’, do apply.

Back End

The Cadmus front-end is served by a robust and scale-focused Elixir back-end which handles our heavy distributed data communication requirements. We are one of the few Functional Programming shops in Melbourne and hope to become one of the biggest. The vast amounts of data generated by our clients require a maintainable concurrency model which the Erlang VM provides. Functional Programming concepts, and (by extension) Functional Reactive Programming, seep into a lot of solutions we employ and value.

Data Engineering

Apart from the core back-end and various front-end environments, we have a large data processing pipeline for analyses and require near-real-time metrics. Data Science is our second strength and feature. Building scalable, cost-effective, batch + stream processing pipelines are engineering problems we tackle every day. You won’t be restricted to just Web and Server problems.

Our Challenges

Across all our deployed solutions we have to tackle problems related to network transport Integrity and Consistency, Distributed Communications and Conflicts, Event Sourcing and Operational Transforms, efficient Batch analysis, Stream Processing, Authentication and Security, L.M.S protocols, Concurrency, immutable Content Editable editors, and more. Solutions to these are sometimes adopted and other times bespoke. It is not just Web App based Product.

What Do We Look For?

Overall, we look for developers with similar values to us.

This idea is central to our search for a new developer to join our team. It is a growing team and its growth has been driven by trust and collaboration. While a certain amount skill and depth are important, we value compatibility and drive for programming more.

We also want you to be happy to work with us. Here are a few description points to help you flesh us out:

We love Learning

And do it constantly, both in the workplace and personally. The Tech world will never be stagnant and we are always excited about what’s coming next, or what we can contribute to. It’s a natural part of us as developers and we want to work with similar self-motivated and passionate programmers who want to excel. We want to solve hard problems but also care about approaching these problems with strong fundamentals and tested knowledge. It’s important to know what you don’t know.

We didn’t begin with a full understanding of the problems mentioned above, we experimented and kept learning through our own learning processes. What are you learning next to become a better developer? How do you learn?

We love Teaching

Growing alone can be slow, but helping others and educating them on your Learnings can leap-frog everyone’s growth, including yours. Bring your ideas and spread them. We value Feedback. The product has only grown because ideas, languages, and stacks were learnt and spread around. This is what allowed us to turn-around from a NodeJS backend to an Elixir backend for a more suitable concurrency model.

We love Languages

Code is our way of communicating ideas. Everyone in our Dev Team comes from varied programming backgrounds. They have brought patterns and ideas from different programming paradigms which have helped us improve our codebase tremendously. It keeps us flexible to tackle different problems. It is easier to communicate abstract solutions in code when everyone has the ability to grasp different programming models.

Be comfortable and productive with one language but have the experience to switch if you think you can produce a better solution in a different language.

We like writing Good Code

Code style is personal and should be. But Code produced in a Team environment can only be considered Good if it adheres to a preset Team Standard (even if it is different from your personal style). This is what Good Code is to us: uniform and maintainable by the whole Team. Of course, these standards are also set by us and you. We want to build a scalable product without sacrificing developer productivity.

We care about underlying Engineering Problems

As much as we love elegant code solutions and high-level abstractions, we need to deploy production-ready code. We need to understand and care about the side-effects our code produces or runs within. We don’t have dedicated Teams to deal with Code delivery, deployment, and scaling. Understanding Caches, Indexes, Memory abstractions, IO bottlenecks, Networks and HTTP transport .etc. is important. You don’t need to understand all of this in depth, as long as you show care and consideration for these side-effects and computing fundamentals.

We do Functional Programming, but above all we value diversity The largest Repository in our organisation is the Elixir back-end. Our front-end javascript code also uses a lot of functional programming concepts including the Reactive data model from the Elm lang through Redux, FRP constructs, and Immutability. But we do not restrict ourselves to just FP languages and provide the freedom to use the best language suitable for the problem. We have a healthy language spread across the many internal repositories, experiments and prototypes, scripts and tools, data analysis systems .etc. These languages include Elixir, Javascript, Python, R, Ruby, Haskell, Elm, Go, and shell scripts.