Product Designers (PDs) and Software Engineers (SEs) work and think in a quite different way. We (SE) naturally tend to focus on technical solutions and code. Sure, at ToolTime we take part in the whole lifecycle of a feature, but at the end of the day, as SEs we provide a solution using our programming skills. On the other hand, PDs look for ways to provide value to the user by making the features visible, understandable and intuitive via UI/UX.

These two different approaches lead to different vocabulary and processes. Let’s take a look at what tools and environments each uses. PDs at ToolTime use Figma for creating mockups and the design system. SEs use code and they see the visual result of their code in the actual app. This comes with a question: What is the source of truth for the design? The Figma mockups or the actual code that is deployed to production?

Figma comes with the disadvantage that it’s quite distant to the SEs, as it's not their everyday's tool. Same applies to code, where PDs struggle. Moreover, it may take quite some time for PDs to be able to review the implemented design since they have to wait for a preview URL and use the entire product in order to check the design of one feature or design system component.

We decided to solve this problem by adding something in between that is easy for both sides to use and making the source of truth for the design that is deployed to production. We chose Storybook as our tool that displays our design system and we feel very justified by this choice.

Why Storybook

Storybook is a widely known tool, test-proof and fits our purpose very well. We can run it both locally and have it on the cloud for easier access as well via Chromatic. In addition, it is not opinionated and we can give it any shape we need, in close collaboration with our PDs.

Another advantage of Storybook is its stories files. They can be used as a reference for our SEs as we can, most of the times, just copy/paste the code from a story to our actual code.

Chromatic reviews

Every time we push code to a git branch on Github, Chromatic checks if there were any changes that resulted to different design in Storybook. If that’s the case, a design review is required, which can be performed only by our PDs. They can see the changes, comment, accept or reject them. This way we make sure that any design system change is approved by our product team first.

What’s the result?

The quality of the developed UI as well as consistency in the product increased by a lot. The collaboration between our design and engineering teams improved and became smoother and more efficient. Most notably:

• The vocabulary became consistent
• The source of truth for design system components isn’t on either team’s side, but in the middle
• We can implement and review our design system independently from the product
• With Chromatic, PDs are in control of new implementations and changes
• SEs can use the stories as reference for their code
• Easy and transparent cross-functional collaboration 🎉

While it's not something you would want to start with (well, unless you already have all the building blocks) a micro-service oriented architecture comes with more gains than pains. What you are looking at is the current state of TT architecture. Yes, You can probably recognise the pattern - backend being a monolith application being split into more and more services. But, it's not what I wanted to write about.

How long does it take for a new service to be in production?
Before we dive into it. How long does it take you to build a new application and ship it to production. Let's say, only basic server with monitoring and logging, CI/CD pipeline, and 1 test endpoint. How long does it take you from the first command line call to the moment when the app is available? Think about it and we will come back to it at the end.

Highly aligned
First thing that we really wanted to see is how we will ensure that with the growing number of newly created applications we do not have to rebuild existing things over and over again. We agreed on a set of important items that a service needs to have:
- centralised logs - here is where DataDog comes to play
- each app is monitored and alerts when there are problems - this is a mix of Kubernetes features and DataDog alerts
- each build step is available as a command line tool - we decided for Makefile
- each service defines each own running environment - Helm is our friend here
- CI pipeline with steps is defined - CircleCI is our tool of choice
- we get CD pipeline out of the box - CI provides Docker images and Argo-Cd takes care of deployments
In the end we wanted to get as close to 12factor apps as possible. As You can imagine, this level of alignment is not easy to achieve, even more difficult to implement for each service and very hard to maintain.

So, to the next step

Single source of truth
We have built a single source of truth project which we could use as a reference point. This is where a lot of discussions around How happened. We have built a simple Spring Boot application first. The app was exposing a sample endpoint and that's pretty much it. Then the work around CI added a circleci/config.yaml, a need to have centralised logs pushed us towards DataDog agents deployed on our Kubernetes, the need to define the environments ended up to be a bunch of Helm files in the project. You get the point. One app to have it all.

In the end, a developer could clone the repo, rename packages, and run the app locally.
Then just fiddle with CircleCI, register an app with our gitops repo, add your DB lib, secrets to Kubernetes. Drink coffee and boom.

I know what you are thinking... such an effort. We thought the same. This was great but still... not good enough.

Ease of use
The next step was to apply one of the CD rules: automate everything. We have created a command line tool which does the following:
- creates a new project out of the source of truth repository using the right name
- registers a new app with the CI pipeline (CircleCI)
- registers a new app with the GitOps continuous delivery (ArgoCD)
The only thing the developer needs to do is to push the code to a remote repo and they will see the app.

The mindset
I believe that was the hardest part. It has always been. How do we buy in to something where the pros are not so clearly visible but the issues are  obvious from the very beginning?
- why lift table joins to code when DB has been successfully doing that for decades
- what about transactions?
- this will increase the cost of infra, each service comes with a memory footprint
- rather than having 1 place to look, we will have to chase the code around in case of problems
and many many more which I will not mention here. I guess another article need to be written to fully explain what was blocking us and how we worked around these. I must say that I am very proud of the team here.

How long does it take for a new service to be in production?
We can say this:
- 30 seconds to create a new service, it's just a 1 command line call
- 5 mins to run the CD pipeline (the image creation could be improved)
- 40 seconds to deploy and have the service boot up

So all together 7 mins. How long does it take you?

The path to arrive at the goal is more important than the goal itself.

(Someone said that, probably not Lao Tzu)

Introduction: what we had to accomplish

In ToolTime we have currently three autonomous squads, following the Agile principles of self-organising and cross-functional teams. The squad in which I am working is called "collaboration squad". The name is not only about our internal collaboration, but mainly indicating our focus on enhancing the collaboration, the teamwork and the workflow for our customers.
One of the requested features was to have notifications appearing in the Web application when somebody performs some action. For example, when a field worker (imagine an electrician, a plumber or some other type of craftsman) creates or closes an appointment from the mobile app, the office-located colleagues should see a notification in the Web app.
Here below is a screenshot:

The requirement was just display the notification and don't store it, because we have another feature of the product, called "activity log", to store and display the history of events.
The flow is: a field worker performs some action using the mobile app, then the backend system, that receives requests form the mobile app, should send a notification to the Web app, that in turn should be listening and display the notification for some time.

Different options on the table

We didn't have any notification system in place so far, therefore we wanted to investigate the possible options available for implementing this mechanism. As always happens in these cases, we don't want to just pick any solution, but we want to work together to define the best solution for our problem. All the engineers in the squad, five people at that time, contributed with "spikes" to the team knowledge of available options and practically tried some proofs of concept. The process is very democratic: each one contributes with ideas and proofs of concept, we discuss together and take a decision. We think that only a democratic team environment can encourage people's creativity and we enjoy working this way.
Omitting a few ideas for the sake of brevity, the main solutions we tried in our spikes are:

• Firebase Realtime Database.
• GraphQL subscriptions in our backend service.
• GraphQL subscriptions in a new microservice.
• Server-sent events.
• AWS AppSync.

Firebase was one of the most valuable solutions, as it appeared to be easy to implement, especially on the frontend side. It is just about using a DB table, where the backend should write and from where the frontend should read (subscribing to changes). It could have really become our solution, just we had some minor concerns:

• an additional cleanup mechanism was needed. Our business case was not exactly about storing something, but more of the type fire-and-forget. It looked like a valid solution but a bit "artificial" in our asset.
• There was a lack of "contract" between frontend and backend.
• We should have taken care of some other nonfunctional aspects, like security, in an additional cloud environment, as we are currently mainly using AWS.

Our main backend service is based on GraphQL and the Web app is communicating with it in GraphQL, therefore it looked natural to us to consider GraphQL subscriptions, based on the WebSocket protocol.
The first place we considered for adding GraphQL subscriptions was our backend service, but we soon found two cons in doing that:

• It would have forced us to upgrade the GraphQL version, which is something that we would prefer to postpone according to our plans for improving our system.
• It would have added more responsibilities to the backend service, that we want to split instead, as we are currently migrating towards a microservice-based architecture.

As a consequence, we thought that it would have been better done inside a new microservice, dedicated only to this mission (something like a "notification-service"). Another respectable option, still forcing us to create and maintain a service and to add custom code.

Yet another respectable idea was to use server sent events instead of WebSocket, considering that our case is mono-directional and not bi-directional as a chat. A small reasonable proof of concept was presented for the backend side, still this was making us develop some custom code inside some service for the purpose.

At the end, we embraced the serverless idea, that is AWS AppSync, that is like saying a serverless version of the idea of GraphQL subscriptions, as AppSync is essentially a GraphQL service. AppSync became our notification service.

Our solution

In AppSync we define a small schema reflecting the structure of our notifications (type of action, author of the action, time in which it took place, etc.), with one mutation for sending notifications, to be invoked by the backend service, and one subscription, to be invoked by the frontend app. We used "NONE" data sources, as the data is just in transit inside AppSync, we don't need to store anything.

Just a few lines of code (such an "if" condition) were added to the subscription resolver, to check that users are subscribing to events belonging to their company and not another one.
Subscribing and getting notifications was easily implemented in the Web application using Amplify. Similarly for the backend service, it was just about sending a request to AppSync with the data about the event that was triggered by some user action.

Nothing to do for the mobile app, just sending requests to the backend service as before.
We had also fun with some amount of work to be done at infrastructure level, not so difficult, regarding the Terraform definition of our resources (infrastructure as software).
Notice: this was an effort only at creation time, to define the infrastructure, but not at maintenance time, as we went for a serverless solution, as mentioned.
The work was related also to exposing the AppSync subscription with a readable public URL, using AWS CloudFront and Route53, and to security.

We don't want to talk in detail about the security aspects of our solution, just for the purpose of security, but we think we obtained a respectable level of security by combining different AppSync authentication modes, for the sender of events and the subscriber, and other general AWS features like WAF.

Here is a diagram summarising our solution:

• The subscription from the Web app goes through Route53 and CloudFront, reaching AppSync.
• A request arrives from the mobile application to the backend service.
• The backend service sends a notification to AppSync.
• The Web app, that previously subscribed to AppSync, receives the notification.

The Result

So far, a few months after the release, we have encountered:

• customer satisfaction,
• zero bugs,
• zero infrastructure issues,
• zero infrastructure maintenance work.

The initial research work and the infrastructure configuration paid off. The solution respects the nature of our requirements. The "path" to get to the result and the team collaboration were the key. A mainly serverless solution with a very little amount of code means you can just use it and basically forget it from a maintenance point of you, so that you can focus on other features in this fast-paced world.

What is separation of concerns?

Good question.

In the late 2000s, Web Developers would identify concerns such as Content (HTML), Styling (CSS) and Interactions (JavaScript). If the website was build using a dynamic language such as PHP, one could identify additional concerns, for example Business Logic, Session Persistence, Database Queries (SQL), and many more.

It used to be pretty common to write HTML (or PHP) files that would mix multiple, if not all of those concerns in a single file. HTML4 was even enabling developers to define styling with HTML tags such as <font>, <marquee>, or <blink>. Nowadays, if we want to achieve effects such as the <blink> tag offered, we would write a CSS animation and target an HTML element with a CSS selector, if we want to display bold text for purely stylistic reasons, we would use the font-weight CSS property instead of using the <b> tag.

In React Apps we find many similarities with early days websites. Let us go through some of the concerns we have identified and systematically separated in our apps in order to reduce file length, increase clarity, allow for higher collaboration through modularity, and higher maintainability through conventions.

Concerns in React

Before we dive deeper, let us get familiar with the goal of React, by reading the first line in the React documentation.

React is a JavaScript library for building user interfaces.

Alright, let's identify the common concerns of a user interface:

• Routing
• Content
• Styling
• Interactions

We will tackle other non-UI concerns, such as business logic or data handling, and dive into concepts such as single-responsability principle in future articles.

So, first of: Routing!

Routing

🛣 Routing binds a URL to a React component.

When we enter a URL in our browser, or when we click on a link, we expect the application to load a page. In a Single Page Application, this is the responsibility of a Router.

Various React apps introduce complexity by using a mixture of two paradigms: Application routing and Nested routing.

Let us define these two terms first to create common understanding with the examples of react-router-dom. In these examples we will imagine a simple application that routes to a home page, a user profile, and a user profile edit page.

Application routing introduces a unique application-wide Router and associated routes, listening to URL changes, and its responsibility is to render a different page for each route.

// App.jsx
const App = () => {
  return (
    <Router>
      <Switch>
        <Route path="/" component={<HomePage />} />
        <Route path="/profile/:username" component={<ProfilePage />} />
        <Route path="/profile/:username/edit" component={<ProfileEditPage />} />
      </Switch>
    </Router>
  );
};

Nested routing introduces multiple routers nested within each other. In this example the App.jsx file includes a <Router>, and so does the ProfileWithRouter.jsx file.

// App.jsx
const App = () => {
  return (
    <Router>
      <Switch>
        <Route path="/" component={<HomePage />} />
        <Route path="/profile/:username" component={<ProfileWithRouter />} />
      </Switch>
    </Router>
  );
};

// ProfileWithRouter.jsx
const ProfileWithRouter = () => { 
  const match = useRouteMatch();
  return (
    <Router>
      <Switch>
        <Route path={`${match.path}/edit`} component={<ProfileEditPage />} />
        <Route path={match.path} component={<ProfilPage />} />
      </Switch>
    </Router>
  );
};

Now, if the Nested routing principal follows clear team conventions across the whole application, and is perhaps even enforced through tooling, then this approach is not, per se, a knotty strategy. However, if conventions cannot be enforced or aren't followed, it can lead to maintainability issues. In our Apps, it led to vague responsibilities, and obscurity about which components handle which routes, why, and how, one of the many questions was "should these components also render content?". We found it made it particularly hard for a new team to take over a project, or for a new colleague to get a quick understanding of the application.

Application routing has an advantage in that it offers centralised clarity about all reachable parts of the application, if properly isolated it does not even need to live in App.jsx, it can live in its own file, away from other UI concerns. So we moved all routing logic to an Application routing strategy and isolated it like so:

#1 Store routes as an array of objects:

// Routes.js
export const routes = [{
  path: '/',
  component: HomePage
},{
  path: '/profile/:id',
  component: ProfilePage
},{
  path: 'profile/:id/edit',
  componentt: ProfileEditPage
}];

#2 Consume the routes in a router:

// Router.jsx
import { BrowserRouter, Switch, Route } from 'react-router-dom';
import { routes } from './routes';

export const Router = () => {
  return (
    <BrowserRouter>
      <Switch>
        {routes.map({ path, component }) => { 
          <Route path={path} component={component} />
        })}
      </Switch>
    </BrowserRouter>
  );
};

#3 Import the router in the App

// App.jsx
import { Router } from 'Router';

export const App = () => {
  return <Router />;
};

This solution is not unique to ToolTime, it is already widely used by the React community, and is central to many opinionated frameworks such as Backbone, Vue, or Angular.

So this is how we solved Routing: we centralised the routing logic, and removed nested routing from components. Developers benefit from clarity, and routing concerns are separated from other concerns.

Content

📰 Content describes the semantics of a component.

It might be interactive content such as <video>, or <img>. Or actionable content like form elements with <button> or <input>,  or a link to another page with an anchor tag <a>. In most cases however, it will be text described as paragraphs with <p>, headings with <h1>, <h2>,… unordered lists with <ul>, etc. And other tags such as <main>, <section> to structure the content in a page.

For this example we will render a blog post with what is known as divitus, the excessive usage of <div>, in detriment of semantic HTML tags.

// BlogPost.jsx
export const BlogPost = () => { 
  return (
    <>
      <div>How much I like banana bread</div>
      <div>
        I looooove banana bread!<br />Very very much!
      </div>
    </>
  );
};

The above example has no semantic value: a browser, a search engine, or a screen-reader is unable to tell which text is the title, and which text is the post's content.

Let's solve this with semantics:

// BlogPost.jsx
export const BlogPost = () => { 
  return (
    <>
      <h1>How much I like banana bread</h1>
      <p>
        I looooove banana bread! <br />
        Very very much!
      </p>
    </>
  );
};

This was easy. Beyond semantics, HTML also provides build-in functionalities, such as form validation, dns pre-fetching, and much more. Check out the MDN HTML guide for more.

⚠️ Content anti-patterns

Beware of anti-patterns, many React components available throughout the libraries in the community, will provide some functionality without rendering anything.

While this is accepted by many as "normal", we do believe that this goes beyond the responsibilities of a UI library. Expressing functionalities, such as data-fetching for example, are better expressed with functions, or with React hooks, than they are with JSX.

For example we forbid the usage of Apollo's <Query> component, instead we rely on Apollo's functional API to fetch data and extract that responsibility to a different file.

Alright let's dive into the next topic: Styling.

Styling

💅 Styling defines the look and feel of a component.

Many tools such as JSS, CSS Modules, Emotion,… can be used to style components.
What is also pretty common in various documentations is to "co-locate" styles with the component functionality in the same file, such as this:

// BlogPost.jsx
const styles = {
  title: {
    color: 'red'
  }
};

export const BlogPost = () => { 
  return (
    <h1 className={styles.title}>How much I like banana bread</h1>
    <p>I looooove banana bread!</p>
    <p>Very very much!</p>
  );
};

While this might seem harmless in many cases, it becomes increasingly difficult to maintain when the styles grow in size, and the component grows in complexity.

The solution we advocate, is to separate these two concerns in different files, no matter how many lines of code, the result then looks somewhat like this:

// BlogPost.styles.js
export const styles = {
  title: {
    color: 'red'
  }
};

// BlogPost.jsx
import { styles } from './BlogPost.styles';
export const BlogPost = () => { 
  return (
    <h1 className={styles.title}>How much I like banana bread</h1>
    <p>I looooove banana bread!</p>
    <p>Very very much!</p>
  );
};

Beyond the advantage of creating smaller clearer maintainable files, the next author won't have to break up a file that grew in complexity.

Interactions

📲 Interactions describe a components behaviour on user input.

Let's imagine we want to render a button that behaves as a toggle for an information to be displayed below (that I love banana bread).

// ButtonWithContent.jsx
export const ButtonWithContent = () => {
  const [isEnabled, setIsEnabled] = useState(false);
  const clickHandler = () => {
    setIsEnabled(!isEnabled);
  };
  return (
    <>
      <button onClick={clickHandler}>Toggle information</button>
      {isEnabled && <p>I love banana bread</p>}
    </>
  );
};

This component contains multiple concerns now:

• A state isEnabled and its setter setIsEnabled expressed via React's useState hook.
• An event handler clickHandler toggling the state everytime the button is clicked.
• Stateful JSX that will conditionally render the <p> content.

Again, in many cases this will seem harmless, the file feels small and readable, but as soon as the feature grows in complexity, the next developer will need to decide to keep adding to it, or to move these concerns to a different file.

Moving behaviours out of the component can be achieved immediately, one way is to use React Hooks like so:

// ButtonWithContent.behaviour.js
export const useButtonWithContentBehaviour = () => {
  const [isEnabled, setIsEnabled] = useState(false);
  const clickHandler = () => {
    setIsEnabled(!isEnabled);
  };
  return {
    clickHandler: clickHandler,
    isEnabled: isEnabled
  }
};

Now the concerns of interactions are separated from the component's rendering concerns. The component calls a hook to retrieve the state and the click handler from the behaviour:

// ButtonWithContent.jsx
import { useButtonWithContentBehaviour } from './ButtonWithContent.behaviour';
export const ButtonWithContent = () => {
  const { clickHandler, isEnabled } = useButtonWithContentBehaviour()
  return (
    <>
      <button onClick={clickHandler}>Toggle information</button>
      {isEnabled && <p>I love banana bread</p>}
    </>
  );
};

Finally

We follow these principles because we find that they work for us, not every solution fits every context, you might need to adapt these ideas slightly to fit your needs, or perhaps you will need to look elsewhere for other solutions.

To us, large intricated software problems, become small solvable problems when they are split. Defining boundaries and responsibilities helped us refactor large messy files into clearer, smaller, maintainable files ; eventually this discipline has led to more readable, scalable, and testable software.

Idea

When I joined ToolTime, heavily influenced by a book called 5 dysfunctions of a team, and my previous experience I was convinced that the things I will be optimising for is how people in a team work, rather than what single engineers bring to the table. The idea was that I will try to create an emotionally safe environment where people voice ideas without being stigmatised. No shaming, and listening to understand, rather than listening to reply.
We need teams where conflict is creative, where people know and understand diverse approaches to a given problem. This way we can pick one that the business will benefit from the most. What is also important, and many teams I've worked with missed that, is that we can create a culture where buy-in is easier to achieve, and the disagree and commit is not just a weird way of saying "listen to the boss".

Values

What we are trying to understand during the interview is the candidate's attitude and mental model, secondarily their technical skills. No, it's not to say that technical skills do not matter. It is just that it is way easier to teach a programming language, technology and tools to a person with the right mindset, than to change the mindset of a really skilled, technical person.
We are looking for people who make everyone around them better engineers, and this way we will only get stronger teams which will ripple this "continuous improvement effect" outside their circle.

The mental model we are looking for can be described in a few words: the more I know, the less I know, many, small problems rather than one and big, no bullshit, curious, 2% grumpy.

• the more I know, the less I know - we want to know what the candidate thinks and why they think that. It's really unimportant that you do not follow TDD, we are curios to know if you can articulate why you decided to not follow that style.
• many small problems - whether a candidate breaks the issue down, how do they approach the given task. Will they fall into "analysis paralysis", or will they solve each step in isolation? Can they build a whole picture or do they get lost in details?
• no bullshit - interviews are stressful, and it's a game where you want to show the best of you to the interviewer. We know! We put a lot of effort to make it as pleasant as possible. However, we really appreciate people who openly say "I don't know", or better "I don't know but what do you think about this approach" rather than trying to tell us everything they know, which seems related.
• curious - will the candidate ask clarifying questions or will they rather burst an answer without really knowing the context. Will they accept that something that worked in a different context, might not work for ToolTime, and will they want to know "Why?"
• 2% grumpy - this is one of our Company Values, a positive attitude helps the team to a great extent. Just the bare feeling of positivity improves the team morale to the point where people naturally gravitate towards each other and want to help. Of course, everyone has worse moments, use the 2% for that.

Hiring process

Knowing what mindset we are looking for, our hiring process is organised in the following stages:

CV screening

We are looking at experience which projects were built with which tools and technologies. It's really way more important to see the application of a particular framework, rather than see a large list of keywords.

Initial call

We want to give the candidate an idea of what we do as a business, and how we operate. We want to understand a candidate's situation.

Call with the Head of Engineering

It's usually a semi-technical discussion. I explain how engineering at ToolTime works and will ask you to tell me your story and what your principles are. I will listen carefully and you should be ready for a series of open questions largely built from the story you tell. For example, if you say you follow SOLID principles, I might ask you what D stands for in SOLID. If you tell how great TDD is, probably my question will be "what is the biggest value of TDD".
Answers which indicate subjective thinking ("It's more readable", "This is better") are scored lower.

Technical call

At this stage, we will want to dive deeper in your technical skills. We will ask you about the technologies we use and what you have experienced in your career. Don't expect algorithms or data structures here, but more likely we will want to know how well you know ReactJs, what are the things you would change if you could, what are the good parts.

Last stage

If you got to this stage, chances are pretty high that you will land a job at TT 😏. All it takes now is to show all the things you told us about in practice. We will prepare a little challenge for you and ask you to pair with us and show how you would solve it. If your comfort zone is mobile, we would ask you to implement a single page app in a skeleton of an app using technology you want. One of our engineers will pair with you. What we want to know is how you cooperate with another person, how do you chose tools and solutions for a given problem.
We will also invite you to get to know people who drive and support product development at TT. You will have a series of coffee/tea chats with everyone. As exhausting as it could be this is also an opportunity for you to get a better idea on how it is to be a ToolTimer. Use it and be curious, ask all the questions that you have.

Decision

We use a very simple, and not an easy system to decide whether a candidate is accepted or not. Every person who participated in the interview gets one vote. They can vote Yes or No, there is no Maybe. Everyone gets a chance to articulate why they voted the way they did. Everyone can change their vote during the discussion. The caveat is one NO means NO, and the candidate is not hired. We are really serious about it, and we do not take this process lightly. At the end of the day it is quite an investment, from our side and from a candidate as well.
In order to help with the vote we have 3 ground questions:

• Is the candidate someone I want to work with every day?
• Is the candidate worth our energy to train them in the areas they fall short in, and will they be able to keep up?
• Can the candidate move without supervision in at least one area?

So really, one no means NO.

But... let's not forget we are dealing with people here, and we all have worse moments where we just fall short. It could be that the interview was too long, your head was in the wrong place or whatever else happened that made you answer in a silly way. Or, one of our interviewers had one of those moments, is that it? No. We also have a very special function in our process and it's called The Champion.
Any of the interviewers can become a champion, taking one of the NOs out. And if they do, they become accountable for setting the candidate for success in the team. They prepare, lead and support the candidate in the first 6 months in TT. Even though it's there, we have not used it since the very beginning. We live by our own rules of listening to understand, be curious and ask, and disagree and commit.

Feedback

Remember the YES/NO voting? That is also the moment where we gather notes that we will later on send to you. Whether they are concerns, ideas for improvement or good notes from your interview. These notes are something we send to a candidate. Sometimes we will send you a link to a book we believe will help you, sometimes it's more general ideas for leveling up. We do not think that failing an interview at ToolTime means you are a bad engineer. Different types of businesses require different types of engineers and that's the mentality we are trying to keep. Our goal is to make sure you will also benefit from the time you have invested in talking to us.