.tech Podcast - Flexible remote working at Form3

blogs· 4min

November 17, 2022

Jordan Van Dyk is Form3's first Canada based engineer. He joins us to share why he chose to work at Form3, what his interview experience was and what a typical day looks like for him on the Tooling team. Then, he shares how his team works and makes recommendations for how highly distributed teams can successfully work together.

Jordan Van Dyk is a Senior Software Developer on the Tooling Team at Form3. Two of the major projects he's working on are k8s-promoter and a variety of GitHub actions tooling. Based in Canada, Jordan has been at Form3 since November 2021.

Choosing Form3

Jordan was our very first Canada based employee, with more colleagues since. He first found out about Form3 on LinkedIn Jobs. He was drawn to the opportunity for two main reasons:

  • Getting into FinTech was something appealing to Jordan
  • The job advertisement sounded really interesting Ready for a new challenge, Jordan decided to apply!

During his interview process, Jordan was impressed with the recruiter interactions, who gave him a completely different experience from companies he was applying with at the time. Then, Jordan learned about the tech stack which included:

After these initial impressions, he was even more excited and convinced that he wanted to continue with the process.

The interview process

Jordan was completely new to Go, which is typical for most of the candidates that we interview at Form3.

The first step in the Form3 interview process was a take home test, which aims to be closer to a real world situation than the typical Leetcode-style coding questions. Despite Jordan's lack of experience, he found resources on the internet which made it easy to accomplish.

After the take home test, the next step is the video interview which lasts 1.5hrs split into three parts:

  • A further introduction to Form3
  • A mock incident
  • Take home task discussion

At the end, Jordan chose to join Form3 for a variety of reasons: tech stack, engineering culture, as well as his personal passion for economics and banking. He has had the opportunity to learn more about the financial aspects from colleagues since joining.

A day in the life of Jordan

Due to hiring at scale, Jordan's team, the tooling team, was split into two smaller teams. Jordan's team now has 2 Canada-based colleagues on his team, as well as team members from the UK, Poland and other European countries. The other team has a similar mix of locations. This means that there is a 5/6 hour time difference between Jordan and the rest of the team.

A typical day for Jordan consists of:

  • Waking up close to his meetings start time and grabbing a coffee (don't we know the feeling!)
  • Logging into the team daily sync meeting, which is a 15 minute status meeting to highlight any blockers
  • Depending on the day, there could be other team ceremonies such as refinement sessions or retrospectives. These meetings are kept to as much of a minimum as possible. Any amount of overlap time in a highly distributed team is extremely valuable, so the team don't want to take it all up with meetings.
  • Working on new or existing tasks. Typically, this also means pairing with a fellow engineer for a few hours of the day.

Timewise, Jordan works approximately 9AM to 5PM. Most of his meetings will run from 9AM to 11AM local time (or 2PM to 4PM European time). He typically pairs until about 12PM, when he will break for lunch. Typically, he will be working by himself in the afternoon.

Pairing is standard practice at Form3 and working in a vastly different timezone does pose some difficulties. The overlap in time is typically 3 hours, so the team does require some planning for pairing. However, asynchronous communication is something that is required to move tasks forward.

As a side note, Jordan had never working with pair programming on his team before. Now, he can't imagine ever going back and working without pairing. You can read more about our approach to pairing in this wonderful blogpost.

Team adjustments

As the first Canada-based engineer, Jordan sees himself as a bit of a guinea pig for the team and company as a whole. He has played a crucial role in adjusting the team working processes to allow for working in locations across vast time differences. When he joined, the team did have to make some changes:

  • Moved most of their team meetings in the afternoon for the European time zones, in order to allow Jordan to join in his morning time.
  • Meetings with other teams also had to be moved in the afternoon for the European time zones. If these meetings cannot be moved, then catch-up meetings or notes are required to bring everyone up to speed.

Async communication takes place almost entirely on Slack, while GitHub is used to track issues and the progress of work. Slack bots are used to automate as much of the mentions and reminders as possible.

Project work

Jordan gives us an idea of how the Tooling team organise and deliver their work:

  • When it comes to planning, the team makes a quarterly plan together with their product manager (PM). The PM has the overview of any client requirements and whether there are any immediate team dependencies on the Tooling team.
  • Then, they use GitHub to create and prioritise granular tasks.
  • From there, the team is allowed to choose their own work, respecting the set priorities as much as possible. They then start tackling tasks as quickly as possible.
  • Every so often, the team have refinement meetings with their team lead to ensure that everyone is in alignment with the tasks that they are delivering, including the revision of deadlines.

Engineers at Form3 take a lot of ownership of their work. Ultimately, their lead is responsible for all the work that the team delivers. However, the team is expected to step up for issues or providing support to other teams. The Tooling on-call engineer will have an overview of who's worked on the features and be able to refer issues to the correct person. In a highly remote team, a highly refined backlog is crucial. It prevents those in other timezones from being stuck on tasks until the rest of the team come online and are able to provide guidance.

Documentation is another important aspect of the work that Jordan does on the Tooling team, as it provides guidance and knowledge-transfer to other teams. It's extremely important to keep progress and details of a task up to date to prevent drift in scope and project completion. At Form3, documentation is usually written at the end, as part of the definition of done. This ensures that we keep documentation up-to-date through the life of the project.


After working in a highly remote environment for nearly a year, Jordan can make the following two recommendations:

  • Both the new joiner and the team need to be flexible to ensure that the remote joiner is not left to the wayside.
  • Async communication should be the default choice. While it may feel that we are more connected when we jump on calls, async communication needs to move as the first priority to ensure that nobody is missing anything. Meetings should be recorded, allowing people to catch up.

Once you get into this routine of working, it flows pretty easily. Jordan is enjoying his time at Form3 and he is happy he took the leap in joining such a remote, distributed team.

Written by

Adelina Simion Technology Evangelist

Adelina is a Technology Evangelist at Form3.

She started as a Java engineer, then converted to Go in 2018. She is in charge of telling Form3's tech stories, drawing from her own technical experience.

Adelina is passionate about sharing good technical content for beginners, who might be intimidated by the abstract concepts and jargon of most technical discussions. Her previous conference talks include speaking about NATS at GopherCon UK and implementing serverless at GopherCon Europe.

She is also a LinkedIn Learning instructor. Her course "Applied Concurrency in Go" was published in the platform in January 2022.

Further resources

blogs · 6 min

How to find and fix memory leaks in Go applications

Imagine one day you prepare a proof of concept application. You quickly write some code that shows your idea, add tracing and metrics so you can see how it performs, deploy the application to test environment and boom, after running for 1 hour the application restarts with Out Of Memory error. This screams "memory leak", but you look into the code and see nothing obvious. You may start thinking that overall restart every hour isn't that bad. If you are thinking like that, I encourage you to keep reading as I'm going to guide you on how to debug and fix memory leaks in Go applications.

November 24, 2022

blogs · 6 min

NACLS? Ain't nobody got time for that!

In this blogpost, Adam will try to convince you to implement AWS NACL as additional layer of network protection. He will go through some basics, present some best practices that you could leverage and in the end show how easy it is to implement NACLs in Terraform.

November 10, 2022

blogs · 7 min

Buckle Up Your mTLS With OAuth 2.0 Client Authentication and Certificate-Bound Access

Application security is a persistent hot topic in the technology industry. It is quite common to use mTLS in a business-to-business application, where security is incredibly important, and which uses the zero trust security model. mTLS is also popular with microservices and service mesh to ensure that sensitive resources are not accessible to unauthorised services in the network. mTLS is a transport layer authentication protocol. In this article, Milap Neupane explains: the basics of the mTLS and OAuth 2.0 protocol, the potential drawbacks with mTLS and how OAuth 2.0 Client Authentication and Certificate-Bound Access help improve security.

October 13, 2022