Console

How engineering works at Sourcegraph

How are the teams structured?

Teams are split into different groups, including Engineering, Product, Customer Support, Customer Engineering, Tech Ops and others. The org chart is available on the Sourcegraph website.

What tools do engineers use?

• Design: Figma
• Source Control: git & GitHub
• Issue tracking: GitHub + Jira
• Docs: Sourcegraph
• Devops: Sentry, Honeycomb, Datadog, Incident.io
• Comms: Slack, Twitter, Blog

Can developers pick their own tools?

Yes, we generally believe everyone and every team should be able to choose the tools that enable them to best do their jobs. We have many different editors in use and a lot of the monitoring and deployment tools we use across the company now were spearheaded by individuals. That being said, there are some soft constraints around the introduction of tools and technologies that affect others' work. For example, we are open to using new languages if there is a reason to favor them over existing languages in our stack, but have a status quo bias toward our existing set of languages.

How does the development process work? What's the process for working through bugs, features and tech debt?

Fast-paced, but structured. Most teams are on a 2-week or monthly cycle. We do quarterly planning for big projects/features. We have a lightweight process for planning and getting approval from key stakeholders that typically involves writing up an RFC and tagging the requisite stakeholders. We generally use GitHub Issues and Projects as the roadmap source of truth. We have a monthly product demo day for features and fixes that are shipping.

How does code get reviewed, merged, and deployed?

• Development happens in branches.
• Changes then are squash-merged into our main branch following code review from code owners.
• Deployment to sourcegraph.com is automatic after a change is merged into the main branch.
• We have a monthly release cycle for self-hosted customers, which is cut from the main branch.

What is the QA process?

Automated CI using Buildkite, with automated end-to-end tests.

What are some recent examples of interesting development challenges solved by internal teams as part of building the product?

• sg: internal tool for managing the Sourcegraph dev environment
• Sub-repository permissions: enforcing code permissions within repositories.
• Scaling up our infrastructure to support millions of open-source repositories and private code on sourcegraph.com.
• Both Notebooks and Code Insights were created as hack projects to help with onboarding, documenting code investigations and understanding high-level trends in our code, but they worked so well, we ended up productizing it and releasing them to our customers.

How does on-call work?

• OpsGenie for handling and routing alerts. Incident.io for collaboratively responding to incidents.
• We have an on-call rotation, but no one gets woken up in the middle of the night, because we distribute the rotation to our teammates around the world (fully remote).

Hiring process at Sourcegraph

How does the application process work? What are the stages and what is the timeline?

Applications are received through our careers page and we have a standardized engineering interview process plus a set of resources for candidates.

It is our goal to fill our openings as quickly as possible while maintaining a high quality bar and a strong candidate experience. Once a candidate begins the interview process with us, we aim to complete the interview process in 2-weeks or less.

The process typically looks like this:

1. Recruiter screen (30m).
2. Hiring Manager Screen (30-60m).
3. Team interviews - technical interview (60m) + cross-functional team collaboration interview (60m).
4. Values interview (30m).
5. Leadership interview (30m).

What is the career progression framework? How are promotions and performance reviews managed?

Our handbook documents our career development framework and how performance reviews are managed.