The seven most common questions software engineering candidates ask during an interview—and a hiring manager’s answers

As a Hiring Manager, I speak to a number of software engineering candidates each week, and I often receive similar questions from curious candidates. Here are the most common questions I receive, and my answers. I hope you find these FAQs useful, and as always, feel free to reach out to us if you have additional questions! We hope you’ll consider joining us at Curology.

What is the pairing and mentorship culture like within the Engineering org?

We highly value mentorship at Curology. Every onboarding engineer gets an onboarding buddy to pair with, ask questions, and generally learn from. In addition, Senior and Staff Engineers hold open “office hours” throughout the week for any engineer to drop into for questions and guidance. That’s not to say that’s the only time these engineers are available, but dedicating specific time slots helps to lower the barrier for connecting, especially in a remote environment. Engineers are typically assigned to projects in pairs, and projects are scoped to about six weeks, so the engineering pairs assigned to work on a project for those six weeks can determine their desired cadence for pairing or working independently. Typically, most engineers will end up pairing for about 2-6 hours per week, and that might be some time with their partner on a project, and some time with a Senior Engineer or mentor who is available to answer questions. This is completely flexible and could be more or less depending on their preferences.

What resources are there for learning and career development? How often do engineers on your team get to learn something new or take on work in areas that are new/challenging?

We strongly encourage learning and growing as a core part of an engineers’ role. Managers work closely with their teams to find projects and challenges that suit both their engineers’ interests, goals, and skills. Projects are scoped to take about six weeks, and we try to resource engineers with enough time to explore new topics or take on new challenges during a project cycle without sacrificing the project deliverables. Outside of their main project work, managers work with engineers to identify opportunities for career & skills development, such as writing documentation for a new feature, small projects to improve a stakeholder pain-point, or refactoring a piece of legacy code. We have professional development budget and encourage taking classes, we have bookclubs for both ICs and managers, and often look for additional learning opportunities through Lunch & Learns or knowledge sharing.

How much and what type of interaction should I expect with Product Managers?

Product Engineering at Curology is organized into three cross-functional Product Groups: Patient Experience, Growth & Subscriptions, and Medical & Pharmacy Ops. Each group typically has 1-3 Product Managers, 10-14 software engineers, 1-2 Engineering Managers, as well as designers, data analysts, data engineers, a UX researcher, and a Program Manager. In particular, Product Managers work closely with engineers during the planning phase of a project, and may co-author a document together with an engineer to describe the motivation, requirements, technical specifications, risks, and other details of a proposed project. Product Managers “sponsor” projects and are available to help unblock engineers during the building phase, and also help to provide insight into business priorities, success metrics, and the roadmap. PMs at Curology do not typically run stand-up or project-manage engineering work in the way that they often do in Agile organizations — engineers typically self-manage those day-to-day activities for their own projects.

How much and what type of interaction should I expect with Product Designers?

Like Product Managers, the interaction between engineers and designers tends to be very collaborative within product groups. For new features with a frontend element, designers will typically help plan the project alongside the PM and engineering “sponsors”, and designers will join weekly meetings throughout the active building phase of the project to request feedback, iterate on designs, provide assets, and conduct design reviews of new features before they are pushed to production. Engineers are also invited to participate in design critiques before designs are finalized or a feature is built.

What are your typical working hours? Or, what does work-life balance look like for you?

We have people working across a variety of timezones and have limited overlapping hours for meetings, so outside of a few core meeting hours, we encourage our teams to set their own schedule and work normal hours within their time zone. This could look like 9am-5pm for some, or 8am-3pm and 9-10pm if you have parenting or other responsibilities in the afternoon – or any other routine that works for you, within reason, that amounts to about 40 hours per week. The Tech Team at Curology was “remote-optional” before the Covid Pandemic started, and we’ve adopted tools and policies to encourage asynchronous communication, document everything, and make remote work enjoyable for most folks. In general, we try to enable a flexible schedule and sane working hours, communicate those via shared calendars and Slack statuses, and give people uninterrupted blocks of time to focus and get things done.

What does “Unlimited PTO” actually mean?

The People & Culture team at Curology recently re-branded the term “Unlimited PTO” to be “Minimum Time Off”, which means that we encourage and enable employees to take a minimum of three weeks of Paid Time Off per year, in addition to 14 company holidays like Labor Day, Thanksgiving, and New Year. In addition, Curology offers a few company-wide days off per year that don’t count towards your PTO.

What are your On-Call requirements and how often do you have incidents?

We have a small group of trained engineers who rotate through On-Call on a regular basis (in the past, we’ve had one engineer per week with one backup, though we may reorganize this in the future). The On-Call engineer is notified via Pager Duty if an incident occurs, and is expected to acknowledge the incident and triage it to the necessary folks who can fix the issue. The On-Call engineer is not necessarily expected to fix the issue themselves if there is someone else with more knowledge of the problem, but they are asked to monitor and manage the situation, and communicate status updates to affected team members. In the last six months, we’ve averaged two incidents per week. In addition to the Product Engineering rotation, we also have on-call rotations among the Data, IT, and Site Reliability teams.

Join us

We believe great skin should be a fact of life, not a luxury

View open positions