PocketPills Software Engineer Interview: Questions, Experience & Prep (2026)

PocketPills is a Canadian digital pharmacy that delivers prescription medications directly to patients at home. Their engineering team builds and maintains the platform covering prescription management, pharmacy workflows, patient communications, and integrations with healthcare providers. As of July 2026, knok's jobradar shows 2 open Software Engineer roles at PocketPills.

Engineers here typically work across backend services, web applications, or mobile features tightly coupled to real patient workflows. Because the domain involves personal health data, expect a culture where reliability, correctness, and privacy compliance carry real weight alongside delivery speed.

For broader context, knok tracks 5,395 active Software Engineer roles across India as of July 2026. Salary bands for this role in India are:

For a Canadian company, compensation for remote or India-based roles depends on the specific arrangement. Candidates report that the hiring process typically involves a recruiter call, a coding or take-home assessment, and one or two rounds with the engineering team.

These are the types of questions candidates report seeing for Software Engineer roles at PocketPills. The mix reflects both technical depth and the healthcare context the company operates in.

1. Walk me through how you would design a system to send prescription refill reminders to thousands of patients reliably.
2. Describe a production bug you fixed. How did you find it, fix it, and make sure it did not happen again?
3. PocketPills handles sensitive patient health data. How do you think about building features that store or process that kind of information?
4. Tell me about a time you worked with a poorly documented third-party API or integration. How did you approach it?
5. How do you maintain code quality when your team is moving fast and timelines are tight?
6. Walk me through a complex feature you shipped end-to-end. What were the hardest technical decisions?
7. How would you design a notification system that supports email, SMS, and push, with per-user preferences?
8. Tell me about a technical disagreement with a teammate. How did you work through it?
9. What do you know about healthcare data regulations, and how would that influence how you build a feature?
10. How do you approach writing tests for critical business logic, such as dosage calculations or payment flows?
11. Describe a time you improved the performance of a slow API or database query. What was your process?
12. How do you evaluate whether to adopt a new tool or framework in a production system?

Q: Describe a production bug you fixed. How did you find it, fix it, and make sure it did not happen again?

*Situation:* At my previous company, we received alerts that a batch job processing user notifications had silently started failing for a subset of users after a routine deployment.

*Task:* I was on-call that week and responsible for diagnosing the issue and getting the system back to a healthy state without data loss.

*Action:* I pulled the recent deployment diff and cross-referenced it with error logs. A schema migration had changed a nullable column to non-nullable, and the batch job was not handling that gracefully. I wrote a hotfix to guard the null case, deployed it behind a feature flag, and ran a backfill to reprocess the failed records. I also added a unit test covering the null path and wrote a post-mortem.

*Result:* Notifications resumed within two hours. The post-mortem led us to add schema migration checks to our CI pipeline so similar changes would be caught before reaching production.

---

Q: Tell me about a time you worked with a poorly documented third-party API.

*Situation:* My team needed to integrate with a legacy insurance verification API that had outdated documentation and inconsistent error responses.

*Task:* I was the engineer assigned to own the integration and make it reliable enough for production use.

*Action:* I set up a sandbox environment and systematically tested every endpoint, logging actual request and response shapes. I built a thin wrapper that normalised error codes, added structured logging for every call, and wrote integration tests against recorded fixtures so we could detect if the API behaviour changed. I also documented my findings in our internal wiki.

*Result:* The integration shipped on time. When the vendor silently changed a response field months later, our tests caught it immediately and we fixed it before any user was affected.

---

Q: How do you approach writing tests for critical business logic?

*Situation:* At a previous healthtech company, I was building a calculation engine that determined co-pay amounts for different insurance plans.

*Task:* The logic was complex, edge cases were numerous, and a bug would directly affect how much patients were charged. I needed a testing strategy I could defend to both the engineering lead and the compliance team.

*Action:* I mapped every known edge case with a product manager and documented expected inputs and outputs as a spec. I wrote unit tests covering each rule branch, property-based tests for combinations we had not thought of, and a small set of end-to-end tests using anonymised real examples. I also flagged the module for mandatory peer review.

*Result:* We caught two calculation errors during review that would have under-charged some patients. The module shipped with zero calculation bugs in the first three months and became the template the team used for other sensitive financial logic.

For technical design questions (such as the notification system or refill reminders), use a simple component breakdown: start with requirements and constraints, identify the main components, explain the data flow, then discuss trade-offs. Interviewers at healthcare companies often follow up on failure modes, so prepare for: what happens if a message fails to send, and how do you handle retries without spamming a patient?

For behavioral questions, the STAR structure works well: Situation (brief context), Task (your specific responsibility), Action (what you did and why), Result (measurable outcome or lesson). Keep the Situation short and spend most of your time on the Action.

For healthcare and privacy questions, show that you understand the principle even if you do not know every regulation by name. Talk about least-privilege data access, audit logging, encryption at rest and in transit, and not storing more data than you need. Mentioning that you would involve legal or compliance rather than deciding alone signals good judgment.

For questions about quality under pressure, give a concrete example and then name the practice: code review, test coverage targets, feature flags for risky changes, incremental rollouts. Abstract principles without examples land flat.

Domain awareness. PocketPills is in healthcare. You do not need a medical background, but candidates who show they have thought about what it means to build for a regulated, patient-facing product stand out. Mentioning privacy, audit trails, or graceful degradation signals that you understand the context.

Reliable engineering habits. Startups in regulated industries move fast but cannot afford silent failures. Interviewers want to see that you write tests, use observability tools, and treat production incidents as learning opportunities rather than things to patch and forget.

Clear communication. Healthcare products involve non-technical stakeholders: pharmacists, compliance teams, customer support. Engineers who can explain a technical decision in plain language are more valuable in this environment.

Ownership. Candidates report that interviewers at companies like PocketPills ask about features you owned end-to-end. Prepare examples where you drove something from design to deployment, not just implemented a ticket.

Collaboration over heroics. The team is relatively small, so cultural fit matters. Examples where you brought a teammate along, resolved a disagreement respectfully, or proactively shared knowledge will land better than 'I single-handedly saved the system' stories.

Week 1: Understand the product and domain. Use PocketPills as a patient would. Read about how digital pharmacies work in Canada. Understand the basic privacy principles that apply to health data. This gives you genuine context for every question about why the company builds what it builds.

Weeks 1-2: Refresh core technical areas. Focus on backend fundamentals: REST API design, database indexing and query performance, asynchronous processing (queues and background jobs), and basic system design patterns. These come up most frequently in candidates' reported experiences.

Week 2: Prepare behavioral stories. Build 4-5 solid STAR stories. Cover a production incident, a complex integration, a technical disagreement, a feature you owned end-to-end, and a time you improved code quality. Map each story to common question types so you are not inventing answers on the spot.

Week 2: System design practice. Work through designing systems with reliability requirements: notification delivery, scheduling reminders, processing health records. Practice explaining trade-offs out loud, not just on paper.

Before each round: Write down two or three questions you genuinely want to ask the interviewer about the team, the codebase, or how they handle incidents. Questions signal engagement and also help you evaluate whether the role is right for you.

Ignoring the healthcare context. Treating PocketPills like a generic SaaS startup is a missed opportunity. When you describe a feature involving user data, mention privacy considerations naturally. It shows you have thought about the domain.

Vague behavioral answers. Saying 'I always write tests' or 'I communicate well with my team' without a specific example does not help you. Interviewers at smaller companies want concrete stories, not principles.

Over-engineering design answers. Candidates sometimes jump straight to distributed systems with multiple queues, caches, and microservices for a problem that could be solved simply. Start simple, explain why you would scale later, and only add complexity when the interviewer pushes on it.

Not asking questions. With only 2 open roles at PocketPills right now, each conversation carries weight. Candidates who ask nothing signal low interest. Ask about the current biggest engineering challenge, how the team handles on-call, or what a typical first month looks like.

Skipping the result. In STAR answers, many candidates describe the situation and action in detail but forget to close with the outcome. Always end with what changed, what you learned, or what the impact was. Even a qualitative result like 'the team adopted this pattern going forward' is better than trailing off.