A developer to do q&a

Senior Full-Stack Product Engineer / QA & Project Lead NestJS • Ruby on Rails • Next.js • QA • Product Thinking • Project Management We are looking for a senior developer who does more than write code. We want someone who will try to break our platform so we can make it better. Our platform is large, complex, and growing quickly. We need an engineer who can move between development, quality assurance, product thinking, user experience, architecture, and project management. If you simply wait for a designer or project manager to tell you exactly what to build, this probably is not the right position. We want someone who asks: * What happens if the user does this? * What happens with 100,000 records instead of 100? * What happens if two people perform this action simultaneously? * What happens if the API fails halfway through? * What permissions are missing? * Can this workflow be simpler? * Is this business rule actually correct? * What happens to existing data when we change this? * How could a user accidentally—or intentionally—break this? * What did the designer or developer forget? * Does this feature actually solve the user’s problem? What You’ll Do 1. Build and Improve the Platform Work across: * Next.js * NestJS * Ruby on Rails * PostgreSQL * APIs and integrations * Existing legacy and modern application architecture You will build new functionality, but a major part of your responsibility will also be improving what already exists. That means: * refactoring weak implementations * improving performance * simplifying complicated workflows * fixing architectural problems * finding inconsistent behavior * improving existing features * identifying technical debt before it becomes a major problem We don’t consider a feature finished just because it works on the happy path. ⸻ 2. Try to Destroy What We Build We specifically want someone with an adversarial QA mindset. Your job is to actively look for ways the platform can fail. Test things developers normally don’t test. For example: A developer builds appointment scheduling. We don’t only want you to verify that an appointment can be created. We want you asking: * Can two users take the last available appointment? * What happens if the provider becomes unavailable afterward? * What happens when the timezone changes? * What happens with recurring appointments? * What happens if payment succeeds but appointment creation fails? * What happens if the user refreshes halfway through? * Can someone access another organization’s appointment? * Can someone bypass a permission through the API? * What happens after cancellation, rescheduling, refunds, or deletion? You should enjoy finding these problems. Breaking something in QA is a success. Finding it after production is a failure of our process. ⸻ 3. Own Quality Assurance You will help establish a stronger QA culture across the development team. This includes: * functional testing * regression testing * integration testing * API testing * permission testing * edge-case testing * negative testing * concurrency testing * performance testing * security-minded testing * cross-browser/device testing * automated testing where appropriate Every feature should be evaluated beyond: “Does it work?” We also need to know: “Where does it stop working?” ⸻ 4. Think Like a Product Manager You should be able to take a feature idea and help turn it into something developers can responsibly build. Before implementation, you should understand: * the business problem * personas * user journeys * domain model * entities and relationships * business rules * permissions * lifecycle and states * data ownership * APIs * integrations * validations * failure behavior * edge cases * security implications * migrations * scalability * testing requirements * technical acceptance criteria You should be willing to challenge incomplete requirements. If the specification doesn’t make sense, don’t quietly build it. Ask why. Propose something better. ⸻ 5. Think About the User Experience You do not have to be a UI designer, but you must care deeply about how the software feels to use. We want engineers who notice things like: * unnecessary clicks * confusing terminology * inconsistent patterns * poor navigation * workflows that are technically correct but frustrating * missing loading, empty, success, and error states * features that expose too much complexity too early Our principle is: Simple when the problem is simple. Powerful when the problem requires complexity. If you see a better way to accomplish something, we want you to say it. ⸻ 6. Help Manage Development This role also requires strong project-management instincts. You should be comfortable helping: * break large initiatives into deliverable pieces * define dependencies * identify blockers * review developer progress * evaluate whether work is actually complete * coordinate frontend/backend dependencies * identify scope problems early * prioritize bugs * manage technical debt * improve development processes * keep projects moving without sacrificing quality You should be able to look at a feature marked “Done” and determine whether it is actually done. ⸻ What We’re Looking For We want someone who is: Technically strong You can understand architecture, databases, APIs, frontend behavior, backend behavior, and production systems. Curious You naturally investigate why something behaves the way it does. Skeptical You don’t assume that because something passed once, it works. Product-minded You care about the business problem and the person using the software—not just the ticket. Detail-oriented Small inconsistencies bother you. Comfortable challenging people If a developer, designer, product manager, or founder proposes something that doesn’t make sense, we expect you to respectfully challenge it. Independent You can take an incomplete problem and systematically figure out what needs to happen. Obsessed with improvement When you encounter an existing feature, you naturally think: How could this be better? ⸻ Technical Experience Strong experience with several of the following is preferred: * Next.js * React * NestJS * Node.js / TypeScript * Ruby on Rails * PostgreSQL * REST APIs * background jobs / queues * authentication and authorization * multi-tenant applications * automated testing * CI/CD * Git/GitHub * cloud infrastructure * logging and monitoring * performance optimization Experience working on a large SaaS, ERP, marketplace, healthcare, scheduling, workforce, fintech, or other complex operational platform is highly valuable. ⸻ The Person We Do NOT Want We are probably not a match if your development process is: “Give me the Figma and I’ll code it.” Or: “That wasn’t in the ticket.” Or: “It works on my computer.” Or: “QA will find it.” Or: “That’s the product manager’s problem.” We don’t separate thinking from development that rigidly. Great engineers help us determine what should be built, how it should behave, how it could fail, and how it can become better. ⸻ How We Will Evaluate You Candidates should expect practical evaluation. We may give you an existing feature and ask you to: 1. Use it. 2. Understand what it is trying to accomplish. 3. Find bugs. 4. Find edge cases. 5. Find security or permission problems. 6. Find UX problems. 7. Find architectural concerns. 8. Identify missing business rules. 9. Recommend improvements. 10. Prioritize what should be fixed first. 11. Explain how you would technically implement the improvements. We are much more interested in how you think than whether you can memorize framework syntax. ⸻ The Mission We are building a platform that is intended to handle increasingly complex real-world businesses and workflows. We need somebody on the team whose instinct is: Build it. Question it. Break it. Understand why it broke. Fix it. Then make the whole experience better than it was before. If that sounds like the kind of engineering you enjoy, we’d like to talk.