See how Tegus can accelerate your research
Hello! We’re the technology team at Tegus. Job postings only contain a fraction of the information that people should know so we provide more detail here to help you decide if Tegus is the sort of place you would want to join.
Tegus helps companies make better decisions. Using interviews with experts, financial filings, and other data, Tegus creates helps investors and key decision makers at companies understand better understand markets and businesses. Our products and services help our customers discover answers to the most challenging questions they face.
Tegus customers are key decision makers in businesses. This includes:
And more - we are regularly adding new data sets to our platform to help our customers better understand their markets and their businesses. To learn more about our founding story, visit our about us page.
People at Tegus are eager to help each other out. There is always someone who can help answer a question, even if the answer lives on another team. Or occasionally an issue crops up that doesn’t have clear ownership—you can be sure multiple engineers will come forward to help out.
Helping out goes beyond reactive assistance. Engineers are rewarded for pitching ideas and taking the initiative. Sometimes those initiatives are product focused, but just as often it might be a quality-of-life improvement to the shared developer tools. Initiatives aren’t limited to code changes either.
We’re a team of engineers, designers, product managers, data scientists and more coming together to redefine financial research. We believe that small teams of smart, talented people can have enormous, outsized impact on the company and the industry.
We come from a huge variety of backgrounds; in particular, most Tegus employees have no prior experience in finance. We value hard work, ingenuity and outside perspectives in all parts of the product development process.
We believe opportunities are limited but talent is everywhere so we don’t limit our hiring to specific locations. Our HQ is in Chicago and some people value having the opportunity to go into the office a couple days a week. But many of us are spread out across the US from New York to California.
We organize our team into small, cross-functional groups from product, design, engineering and data that own specific areas of the product. For example, the Content and Experts team is responsible for growing our expert network and increasing the rate at which Tegus generates new content, while our Search team works to increase the relevance and power of our customer-facing transcript search.
We work in two-week iterations, which typically start with each team sitting down together to assess, scope and break down upcoming work. While we release new software all the time, we find having defined iteration boundaries makes for a good cadence for thinking about work inside a team.
One highlight each iteration is our demo meeting. Every other Monday, we come together in the afternoon to show off the work we’ve done over the last two weeks. We celebrate our progress and upcoming releases and show off the impact our work is having.
Finally, each team regularly conducts retrospectives to find ways to improve. We talk about what’s going well and what isn’t, and we’re careful to note and follow up on any action items.
We release our main web application multiple times per day; our automated deployments only take one click to take a change from CI to staging to production. Deploying frequently is an engineering team superpower that we take full advantage of: it reduces risk by spreading changes out over time and allows our team to get their code out delivering value as fast as possible.
We hate repetitive, error-prone work in our development processes. We invest heavily in automating and abstracting as much as possible, which gives each engineer more and more leverage the more we grow. At Tegus, engineering teams get more productive over time, not less.
High quality automated tests are the key to confidently making changes at the speed we’re shooting for. We continuously invest in our test suites and are experts and finding the right way to exercise new changes.
As engineers, we know that good tool selection has a huge impact on what a team can get done. We believe in choosing boring technology whenever possible; we seek to maximize our leverage by using a small, carefully-chosen set of tools that are easy to learn and productive at scale.
The shared backend for our applications is written in Ruby on Rails. For nearly 17 years Rails has been a fantastic framework for happy and productive engineers. We use a particular variant of the “modular monolith” pattern within our application to keep our architecture as clean as possible.
The Tegus product involves ingesting 3rd party datasets - company data, SEC filings, earnings calls, etc. Python is great for data processing and manipulation and a good foundation for the machine learning that we expect to be coming soon.
Our web frontend applications are written entirely in Vue and Typescript. We find the simple, batteries-included approach of Vue gives us a ton of power when building new features, and Typescript helps us catch errors well before they’re visible to our customers.
We use GraphQL across all of our APIs for two reasons. First, the flexibility of GraphQL allows many new features to be prototyped without any backend changes at all. Second, GraphQL gives us a machine-readable API schema definition, which we use to automate many parts of our development workflow.
We’re hosted at AWS and take advantage of their amazing technologies so we don’t have to re-invent what they have built for us.
Our interview process is designed to make hiring decisions confidently, while also being efficient with candidates’ time.
Our typical interview process heavily relies on doing technical work alongside the candidate. For engineers, this means we’ll do a pair programming exercise with you early in the process, and may do another toward the end. We keep interviews focused and topical - you won’t be asked arcane questions about manhole covers and won’t write code on a whiteboard.
We're a group of product and brand designers that love to create great experiences and make approachable yet empowering experiences. For more details, see our Design Team Introduction on Medium.
Understand previous information. How are users using the product today? Where are current product experiences falling short of their expectations? How can we improve the content discovery experience?
Set the direction through broad exploration. Based on earlier knowledge, we sketch and wireframe "blue sky" concepts and iterate on them - not limited by current technologies. Designers sketch and wireframe to ensure they’re exploring the solution space broadly. We leverage variable fidelity to bring concepts alive to socialize them internally and gather feedback from users.
Cross-functional squad aligns on vision and top priorities then kickoff the work to figure out how we'll solve the opportunity and define success. During the kickoff and initial investigation, we analyze the current state, identify deltas, capture vision confidence level, and determine a plan on how to tackle it. In situations where a big product change could be complicated or even controversial, we run a product workshop with the squad, and other leadership, to ensure everyone understands the scope of the problem and potential repercussions.
This phase attempts to answer one crucial question: do we have enough information to move forward? This involves an exploration of the tech involved, working through broad concepts and rapid iterative prototyping to critique, get internal feedback, and validate with users. A combination of qualitative and quantitative metrics are used to gauge the success of these experiments.
After the experiments, we use Komodo, our design system, as the foundation to build and ship the product or feature on a common tech stack with a UI that aligns with the broader Tegus user experience. We monitor and measure the impact of the work. Based on learnings, the team makes any necessary improvements to the product, then additional iterations may be needed.