Join our Engineering Team!

We create the products and tools that allow our Country Ops Teams to gather and review data and enable our Partnerships and Impact Groups to communicate the insights we learn from that data about smallholder farmers. This work spans many areas, from building features into our in-house survey authoring system to designing UX and implementing UI that allow users to visualize data in clear, legible ways.

The map of Colombia shown above is a good example of how our systems fit together. The data in that map comes from thousands of in-person surveys that our Ops Team administered in Colombia, which is one of about 30 countries in which we conduct survey work. To handle that survey data, we've built our own platform for authoring and managing surveys (Jebena, which has a React frontend and a Python/PostgreSQL backend exposed via GraphQL on AWS). We manage integrations with a third-party system for collecting data on Android devices in the field, and then we create insight scores for each observation (via Python code on an EC2 pipeline). We build the infrastructure and systems for aggregating the data into regions (as defined and stored in PostGIS) and making data like that accessible for various projects (Sini, with a Hasura-based GraphQL API). We're also tasked with building ad hoc projects, such as this interactive Ethiopian Coffee Map.

For our EUDR work, we collaborate closely with our MLOps team, which is responsible for generating the underlying deforestation detection model. The Engineering & Data Group owns the backend services and APIs that receive EUDR farm lists (GPS points and polygons), validate and prepare those lists, and run them against the model and our geospatial datasets. Our systems compute the relevant intersections and make the results available through our EUDR portal and internal tools, so that traders can understand their risk profile and prepare the documentation they need for compliance.

To support all of this, we're about thirty people, grouped into teams around areas of responsibility (data science, data processing, data collection, IT work) and products (Responsible Sourcing and EUDR).

You'll join our EUDR team and take ownership of a workflow that is still evolving. Customers submit lists of farms, and our job is to make sure those lists can be interpreted correctly by our systems and evaluated against our deforestation detection model. You’ll work closely with Liz (our product manager), Smart (frontend engineer for the EUDR portal), Stefan (who leads UX for our external tools), and Jacek (the other backend engineer on the team).

The day-to-day work involves a mix of backend engineering and investigative problem-solving. When something doesn’t look the way a customer or our Support team expects, you’ll often be the one digging in to understand what happened — whether the issue comes from input data, a misunderstanding of how the model works, a gap in our documentation, or an edge case in our business logic. These investigations rely on patient, methodical reasoning.

A significant part of the role involves working within ambiguity. EUDR is a regulated space where the rules continue to evolve, and internal requests don’t always come with fully defined requirements. In practice, that means you’ll often help clarify intent, explore feasible approaches, and guide conversations toward an implementable decision when different stakeholders have different interpretations. This work suits someone who is comfortable shaping direction as part of the process and working with non-technical stakeholders.

The regulation itself also changes over time. As the EU releases new guidance, parts of the system may need to be adjusted to align with updated expectations. You’ll help interpret those changes, understand their implications, and update the Python-based backend so that the system stays consistent, predictable, and compliant.

Our backend stack runs in AWS Fargate using Docker containers and Python. We rely on PostgreSQL and PostGIS for geospatial queries, and use CI/CD and Terraform to keep things stable. Much of the engineering work is about making the system more resilient every week — strengthening data checks, improving observability, and reducing sources of ambiguity that make troubleshooting harder.

Monday Team Standup. Our Monday meetings are simple 30-minute meetings per team, back-to-back, with most team members joining the one meeting relevant for the team they're in.

We also run regular "homeroom" meetings, where members of the team meet based on their technical area. Otherwise we keep meetings to just those needed for a project. For day-to-day work, we use Slack for async communication and hop onto Slack huddles or Google Meet as needed.

We work in a mixed, evolving stack. Some parts of our platform are relatively new; others have been running for several years and need modernization or cleanup. We use GitHub, CI/CD, and (in newer projects) Terraform. Much of our backend work is GraphQL-based (though not all of it), and React is our primary frontend framework. For collaboration and design we mainly use Miro and Figma. Macs are most common, but Linux and Windows are fine too.

We're a nonprofit, and that shapes how engineering operates. Because much of our organization is not built around software development, engineering often works with teams who bring deep field or program expertise but may not frame needs in technical terms. We’ve been strengthening this collaboration with the addition of engineering-focused product managers, and that work is ongoing. At times, priorities move quickly or shift as programs evolve, so engineers play an important role in bringing clarity, scoping work, and helping teams understand what’s feasible. The work is meaningful, but it does require comfort with a dynamic environment and with guiding conversations toward practical solutions.

We make a point to stay connected in a remote-work world. Remote-first work requires intentional effort, so we invest in time together. We get together generally twice a year — once for a full-company retreat (May 2025 in Tanzania) and once for an Engineering & Data retreat (most recently fall 2024 in Guatemala). The whole organization meets weekly on Tuesdays, with rotating presentations from different teams. Our group also meets every other Friday for an informal hangout, and every ~three weeks for a broader cross-team check-in.

We strongly believe everyone in our Engineering & Data Group should spend time in the field. There’s no substitute for visiting our field teams, learning about the work they do, and seeing firsthand what life is like for coffee farmers. Almost all of us have spent time in the field (field visits are not required), and we try to visit for a week or two each year; those trips consistently shape how we approach our work.

We want our interviews to be comfortable, transparent, and useful. Our goal is to give you space to show how you work, and for you to learn enough about us to know whether Enveritas is the right fit. In terms of benefits and compensation, please see the job posting for details, including the salary range for this role.

We also want to be upfront that timelines sometimes shift. The volume of applications for engineering roles has increased significantly in recent years (LLMs have changed how easy it is to apply broadly), and we're investing time into reading applications carefully so we can understand whether we're a good fit for you and vice versa. When volume is high, it may take us longer than usual to respond.

After your introductory interview, the full interview process typically takes four to six weeks and includes four conversations totaling about five hours, plus roughly four hours of preparation time. Here's the outline:

• •

  Introductory Interview (30 minutes; audio-only Google Meet). A chance for you to ask questions about Enveritas and the role, and for us to learn about your background and what you're looking for. We use this call to confirm that moving forward with the technical interviews makes sense.

• •

  Engineering Technical Interview I (60 minutes; Google Meet). A technical conversation with one or two of our engineers. We'll talk through your experience with Python, PostgreSQL, and infrastructure. We may look at a brief code snippet together to understand how you reason about and extend existing code.

• •

  Engineering Technical Interview II (60–90 minutes; Google Meet). This interview is based on a small take-home assignment (1–2 hours, on your own time). This lets us understand how you approach writing software without the pressure of live coding. We'll discuss your decisions, tradeoffs, and thought process.

• •

  Final Interview (45–60 minutes; Google Meet). A conversation with Jeff and potentially a second team member. We use this time for any follow-up questions, and to help you get a clear sense of whether this role and Enveritas match what you're looking for next.

After the interviews, there are a few final steps:

• •

  Reference Check. We ask for three references, ideally former managers or close collaborators. We may request them before the final interview. For more context, see our reference check notes.

• •

  Job Offer. We aim to extend an offer within two weeks of completing reference checks. To keep things equitable across the organization, our offers are firm and aligned with the posted salary range.

• •

  Post-Offer "Kick-the-Tires" Meeting. Once we extend an offer, we're happy to set up time with Jeff or the team for you to ask deeper questions. We can also walk through internal tools or code so you can understand what working here will actually feel like.