Handling the 'Not Invented Here' Syndrome
Describe a time you successfully introduced an external tool or library despite facing resistance from colleagues who preferred to build the solution internally.
Why Interviewers Ask This
Salesforce values collaboration and customer success above all. Interviewers ask this to assess your ability to balance innovation with pragmatism. They want to see if you can navigate internal resistance without being dismissive, demonstrating emotional intelligence and the strategic judgment to know when external solutions save time versus building custom tools.
How to Answer This Question
1. Set the context clearly by describing a specific project where building from scratch was the initial consensus but seemed inefficient.
2. Introduce the conflict: Detail the 'Not Invented Here' sentiment, explaining why colleagues felt proprietary code was safer or better.
3. Present your evidence-based approach: Explain how you conducted research, created a cost-benefit analysis, or built a small proof-of-concept to validate the external tool's superiority.
4. Describe your communication strategy: Highlight how you listened to concerns, addressed technical risks, and aligned the solution with Salesforce's core value of 'Customer Success.'
5. Conclude with measurable outcomes: Share metrics like reduced development time, lower maintenance costs, or faster time-to-market achieved by adopting the external library.
Key Points to Cover
- Demonstrating the ability to listen and validate the concerns of resistant colleagues before pushing back
- Using data-driven evidence like proofs-of-concept or benchmarks to overcome subjective biases
- Aligning the decision with business goals such as speed-to-market and resource efficiency
- Showing humility and a willingness to collaborate rather than imposing a top-down mandate
- Highlighting a successful outcome that benefited the broader team and customer experience
Sample Answer
In my previous role as a Lead Developer, our team was tasked with building a real-time notification engine for a new CRM feature. The consensus was to build it in-house to maintain full control over the architecture. However, I noticed that several engineers were already struggling with legacy WebSocket implementations and facing tight deadlines.
I researched three open-source libraries and identified one that offered robust scaling and better documentation. When I proposed it, two senior developers strongly resisted, arguing that using third-party code introduced security risks and violated our 'build it ourselves' culture. Instead of dismissing their concerns, I scheduled a workshop to present my findings.
I built a minimal proof-of-concept using the external library alongside our existing stack to demonstrate performance benchmarks. I showed that the library reduced latency by 40% and cut our estimated development time from six weeks to ten days. Crucially, I also presented a security audit plan provided by the library maintainers, directly addressing their fears.
By focusing on data rather than opinion, we reached a consensus. We adopted the library, which allowed us to launch the feature two months ahead of schedule. This experience reinforced my belief that at companies like Salesforce, the best solution is the one that delivers the most value to the customer efficiently, regardless of whether it was written internally or externally.
Common Mistakes to Avoid
- Dismissing colleagues' concerns as stubbornness or lack of vision instead of addressing valid technical risks
- Failing to provide concrete data or a proof-of-concept to support the recommendation for an external tool
- Omitting the specific outcome or metric that proves the external solution was actually better than the internal build
- Sounding arrogant or implying that the team's original idea was stupid rather than just suboptimal
Practice This Question with AI
Answer this question orally or via text and get instant AI-powered feedback on your response quality, structure, and delivery.