🏡 Return back to the handbook home page

⛰️ Why are we here?


🚀 Vision and mission

📖 Useful industry resources

💥 How we’re building the team


💛 Operating principes

📍 Where are the team based

🗺️ Where we hire and why

📅 Company cadence

🧍 Weekly standups

✋ Biweekly all hands

🎯 Biweekly happy hours

🗣️ Communication

💪 How we’ll support you?


🛫 Company onboarding

⭐ Benefits

🤝 Share options

💬 Sharing your view

💵 Compensation

📗 Policies

💳 Expenses

🏖️ Vacations

🧒 Caregiver policy

🛠️ Engineering at Junction


🔰 Engineering values

🌀 Engineering cycles

🎯 API design guidelines

🕛 Managing issues

📞 On call

🚀 Progression

Trust your peers ✅

We are all competent engineers with ownership of our work. Each team member brings their unique set of experiences and expertise.

Code reviews, RFCs and discussions are forums for cooperation. We provide each other commentaries and suggestions. But we always trust the owner to make the final decisions based on their product and domain knowledge.

Strive for good outcomes, not perfect solutions ✅

We can take shortcuts to achieve our goals. But we need to have a clear idea of how the shortcut can be an integral step towards the optimal solution.

Simple is better than clever ✅

“Keep it simple, stupid.”

As engineers, we’re all partial to fun abstractions, crazy one liners and funky code. And this is all great fun, but not in a shared code base.

We strive to maintain a clear, concise, and functional code base. One that is friendly to new contributors, and to existing contributors who are all humans with short-term memory.

Guardians, not carpenters ✅

We take ownership of our work. This includes the ongoing performance and the developer experience.

Our pride stems from crafting solutions that deliver exceptional developer experiences. When issues arise, we are invested in resolving them, ensuring our systems operate at their best.

Test strategically ✅

Test the behaviours and the state transitions, not the programming structures.

We are opinionated about what needs to be tested. We do not chase arbitrary test coverage percentage targets. We do not blindly test “everything”.

Every production behavioural bug we fix should contribute to the test suite in some form. After all, a bug was a behaviour unforeseen during development.