Technical Support & Solutions Engineer
Rugved Darwhekar
I find why the queue is full, not just how to empty it faster. 4.5 years diagnosing and resolving Android, ChromeOS, and Generative AI production issues for Google, from first customer report through root cause and engineering handoff.
Open to
Technical Support Engineer
Solutions Engineer
Product Support Engineer
Triage / Escalation Engineer
AI / Developer Experience
0
Android & ChromeOS issues owned weekly
0%
Bounce rate — lowest on a 40-person team
92→0%
Triage accuracy after playbook + KB rollout
0
Pixel devices used for reproduction
Process
How I think about a ticket
Closing a ticket and solving a problem are different jobs. Here's what that's worth to a team, the philosophy behind it, and the loop I actually run.
Why work with me
Diagnoses root cause, not symptoms
Debugs across platform internals, APIs, and 52 devices to find what's actually broken.
0.7% bounce rate
Owns problems end-to-end
Takes a ticket from first report to a validated fix, not just to reassignment.
80–100 issues owned weekly
Builds trust customers can feel
Explains complex problems in plain language and leaves people more confident, not more
confused.
SVP/VP escalations · 3 regions
Closes the loop with engineering
Hands off reproducible cases with root cause and impact, and drives some fixes myself.
3–5 dev-ready reports / week
Builds the process, not just the fix
Playbooks and a knowledge base rebuild that cut repeat tickets and scale a team past
one person.
92% → 98% triage accuracy
Automates before being asked
Already fluent in AI-augmented workflows: RAG pipelines, duplicate detection, and
automation that cut manual work.
70% faster feedback analysis
Operating philosophy
Five habits that feed into each other, not five separate rules.
01
Signal, not noise
A recurring ticket is a signal once you trace it far enough.
02
Feed the roadmap
A bug report earns its cost when it changes what engineering builds next.
03
Scale through docs
A playbook written once lets a junior engineer solve what used to need an
escalation.
04
Automate the repeatable
Automation frees investigation time for the cases that actually need a human.
05
Own the problem
Customers deserve a real investigation, not a reroute into someone else's queue.
The investigation loop
Tap a stage to see how it plays out.
Who I work with
Customers
Plain-language status, honest timelines, and one owner who doesn't disappear between
updates.
Engineering
A reproducible case, not a forwarded ticket: logs, a suspected root cause, and impact.
Program management
Accurate severity and timeline signals, so executive updates reflect reality.
Quality
Field regression signal that feeds pre-release test coverage and bisection tooling.
Developer relations
Migration blockers translated into documentation and tooling developers can self-serve.
Background
Experience
4.5 years supporting Google's Android and Generative AI orgs, in the seat where customer impact meets root cause.
● Current
HCLTech
Supporting Google
Oct 2021 – Present
4.5 yrs · San Jose, CA
4.5 yrs · San Jose, CA
Technical Support & Solutions Engineer — Android · ChromeOS · Generative AI
- Own end-to-end investigation of 80–100 Android and ChromeOS production issues weekly, from customer report through root cause to engineering handoff, holding the lowest bounce rate (0.7%) and one of the lowest hop rates (2%) on a 40-person global triage team.
- Serve as Level 2 triage engineer for Android and ChromeOS, processing reports from Google dogfooders, external developers, testers, and internal engineers against a team queue of 10,000–18,000 issues monthly.
- Became the dedicated support engineer for executive-level escalations across North America, LATAM, and EMEA, including SVPs, VPs, GMs, and Directors.
- Reproduce customer-reported issues across 52 released and pre-release Pixel devices, flashing exact builds and configuring auth states, feature flags, peripherals, and network conditions to match the reported environment.
- Route issues across 500+ Android platform components, keeping misrouted issues rare, and produce 3–5 developer-ready bug reports weekly with reproduction steps, regression analysis, and diagnostic logs so engineering can start debugging without follow-up.
- Assign Priority and Severity classifications based on technical risk and customer impact before escalating, then follow each issue through resolution with weekly follow-ups so nothing stalls in a queue.
- Authored the team's foundational 25-page Level 2 investigation and triage playbook (Aug 2022), then led a 2023–2024 knowledge base rebuild using NotebookLM and a custom RAG implementation, lifting triage accuracy from 92% to 98%.
- Built a duplicate-issue finder using ML similarity matching on incoming issue titles and descriptions, cutting time to find duplicates by 25%.
- Founding member of the Android/ChromeOS build bisection program (est. Aug 2025), averaging 3 bisections weekly and automating build flashing and flag configuration with Python and ADB.
- Led a developer productivity initiative resolving SDK integration blockers for external partners across Python, Java, and Go, authoring canonical sample integrations.
- Built a prototype RAG pipeline on Vertex AI using parent-child chunking, hybrid BM25 + dense vector search with RRF reranking, and Qdrant, reducing developer feedback analysis time by 70% in internal testing.
- Isolated a critical face-auth failure by writing a custom Android sample app to reproduce it, giving engineering a fully reproducible test case that enabled an immediate patch.
PythonVertex AIRAGQdrantNotebookLMAndroid SDKADBAppiumGCPSQL
City of LA
Housing Dept.
Oct 2020 – Oct 2021
Los Angeles, CA
Los Angeles, CA
Software Support Engineer — Web
- Functional and regression testing for a housing portal serving 3.6M residents.
- Resolved 300+ bugs and brought the platform to WCAG 2.1 and Section 508 compliance.
- Integrated automated smoke checks into the CI pipeline, reducing post-deploy emergency fixes.
JavaJavaScriptC#ASP.NETCI/CDWCAG
Vision Labs
May – Oct 2020
San Francisco, CA
San Francisco, CA
Android Developer
- Built cross-platform VR apps integrating BLE and Wi-Fi P2P.
- Automated critical user journeys with Appium and Firebase Crashlytics.
KotlinAndroidBLEAppiumFirebase
Education
MS Computer
Science
Cal State Northridge
GPA: 3.64
Key modules
Data OpsSystem
DesignML FundamentalsDistributed Systems
Education
BE Computer
Science
Government College of Engineering,
Aurangabad
GPA: 3.10 · Maharashtra, India
Foundation
Undergraduate foundation in computer science, ahead of the platform and AI-focused work
that followed at CSUN and Google.
Proof of work & field notes
Writing
Two ongoing threads: real escalations I've investigated, and the thinking behind how I triage. Both grow over time, more escalations and more posts land here as I write them up.
Executive escalations
Details below are generalized to protect confidential information. Structure and outcomes reflect real investigations.
★ Flagship · Multi-window launch regression
The one-second black screen: a three-activity trampoline hiding in the launch path
A brief black window on launch, traced through three activities and a hidden gateway
component, to a fix that shipped in a phased rollout.
Read case study →
Platform regression · Hardware release
Thermal/battery regression escalated ahead of a hardware release
An intermittent regression threatening a release timeline, isolated through build
and flag bisection under executive attention.
Read case study →
Biometric auth · Unreproducible from ticket
Face-auth failure isolated with a custom repro app
A failure engineering couldn't reproduce from the ticket alone, solved by building a
purpose-made sample app.
Read case study →
SDK migration · Developer-facing
SDK migration blocker resolved for external developers
A silent migration gap blocking developers across three languages, closed with
canonical tooling and documentation.
Read case study →
Field notes
A six-part series on how I actually think through technical triage, one discipline per stage of a bug's life.
Part 01
The Confidence Gate
Why I ask one question before I touch a single log line, and why speed of action
isn't proof of understanding.
Read post →
Part 02
Logs Confirm, They Don't Explain
An accurate log can still send you to the wrong team. Truth and completeness aren't
the same thing.
Read post →
Part 03
The Hypothesis Comes Before the Log
Searching a log and testing a theory look identical from the outside. Only one of
them scales with experience.
Read post →
Part 04
Fixing the System, Not Just the Ticket
"Who caused this" and "what allowed this" sound similar and lead to completely
different outcomes.
Read post →
Part 05
Severity Is Not Urgency
Treating severity and priority as one question is exactly how the wrong bugs jump
the queue.
Read post →
Part 06
Closing the Loop
The bug doesn't leave your responsibility just because it left your queue. Why
follow-up is the discipline everyone skips.
Read post →
Automation & AI
What I've built
Never AI for its own sake. Each of these exists because a specific manual process was slow, inconsistent, or didn't scale.
AI infrastructure
RAG developer feedback pipeline
Prototype
The problem
Developer feedback was drowning in unstructured noise. Built and evaluated a
prototype retrieval pipeline to surface signal fast, validated with RAGAS faithfulness metrics against a
golden dataset.
70%
Reduction in feedback analysis time, internal testing
Vertex AIQdrantBM25+DenseRRFRAGAS
Parent-child chunking · hybrid search
AI tooling
Duplicate issue finder
Active
The problem
Investigators were re-diagnosing issues that had already been triaged. Built an ML
similarity matcher over incoming titles and descriptions that surfaces likely duplicates before manual
investigation starts.
25%
Faster time to find duplicates
PythonML similarity
matchingSQL
Surfaces duplicates pre-investigation
Test automation
Android HIL framework
Active
The problem
Pre-release hardware validation was entirely manual and unrepeatable. Built a
hardware-in-the-loop framework running real device tests, directly unblocking hardware release timelines.
100+
Repeatable automated test flows on real hardware
PythonAppiumADBAndroid SDK
Toolkit
Skills & capabilities
AI / ML
Vertex AI / GCPExpert
RAG / LangChainExpert
Gemini / LLMsAdvanced
Qdrant / EmbeddingsAdvanced
Prompt engineeringExpert
Core programming
PythonExpert
JavaAdvanced
KotlinAdvanced
JavaScript / NodeIntermediate
SQLAdvanced
Mobile & tooling
Android SDK / ADBExpert
Logcat / bugreportsExpert
Appium / HILAdvanced
REST API / PostmanAdvanced
Flask / DjangoAdvanced
Frameworks & engines
n8n / agentic AIAdvanced
Git / GitHubExpert
JIRA / AgileExpert
ReactIntermediate
FirebaseAdvanced
Active credentials
Google: Generative AI Fundamentals
Google: Intro to Generative AI
AWS Partner: Generative AI Essentials
Android Development: UI with Kotlin
Postman: QA Engineer — Navigating the Testing Lifecycle
Documentation I build as I go
Playbooks
Step-by-step triage guides for recurring regression classes, the reason team triage
accuracy moved from 92% to 98%.
Knowledge base
A searchable record of prior root causes, so a new engineer's first instinct is to check
history, not start from zero.
Runbooks
Concrete steps for high-severity incidents: log sources, escalation contacts, and rollback
criteria, written before the incident.
Decision trees
Ownership routing logic, subsystem, team, severity, encoded so triage doesn't depend on
one person's memory.
Let's talk
Get in touch
Open to Technical Support Engineer, Solutions Engineer, Product Support Engineer, and Triage/Escalation roles. Remote, onsite, or ready to relocate anywhere in the US and Ireland.
Currently accepting
SF Bay Area, California, USA · In-person · Remote · Ready to relocate
anywhere in the US & Ireland.
Scan to revisit this page
rugvedd.com