Technical Support Engineer · outside-in homework

support engineering teardown

An outside-in support-engineering teardown of QuickNode, from someone who lives in JSON-RPC. What breaks for customers, how I would triage it, a competitive map, the JD mapped to a plan, and a live RPC-debugging tool I built for this application. Public information only.

Scale

10B+ req/mo

JD: more than 10 billion

Surface

Multi-chain RPC

ETH · Base · Solana · +

Team

120+ people

global, remote-first

Miami, FL

global remote roles

Backed by Tiger Global · Y Combinator · SoftBank · Seven Seven Six. Figures per public sources and the JD.

Summary

Thesis: for RPC infrastructure, support quality is part of the product. A dropped WebSocket or a confusing 429 costs a customer's app real uptime, and the customer feels it as your outage. The Technical Support Engineer sits on the seam that runs customer to RPC to node to engineering.

This page runs that seam end to end. It maps what breaks and where it sits, gives an ordered JSON-RPC debugging playbook with copy-pasteable curl, and reads QuickNode against its competitors. To prove the first layer of triage, I built a working tool that runs the health battery automatically: RPC Doctor. Point it at any EVM endpoint and it returns the chain, block height, client version, latency, batch and archive support, with clear errors for CORS, 401, 429 and timeouts. See §05.

QuickNode in context

Snapshot

Cloud infrastructure company powering blockchain and web3 apps with managed RPC endpoints and node infrastructure.
Serves more than 10 billion requests per month across many chains (Ethereum, Base, Solana, Polygon, BNB, Arbitrum, and more).
~120+ people, global and remote-first; HQ in Miami, FL.
Backed by Tiger Global, Y Combinator, SoftBank, Seven Seven Six.
Customers run production apps on these endpoints, so a support miss is a customer-facing outage.

Product surface, and the support seam it creates

Surface	What it is	What support gets asked
RPC endpoints	Managed HTTPS + WebSocket JSON-RPC per chain, shared or dedicated	timeouts, wrong network, 429, method support
Dedicated / archive nodes	Isolated nodes; archive keeps full historical state	missing trie node, old-block reads
WebSocket subscriptions	eth_subscribe for new heads, logs, pending tx	disconnects, missed events, reconnect logic
Add-ons marketplace	Streams, Functions, Token/NFT APIs, enhanced methods	enablement, quota, response shape
Rate limiting	Credit-based limits, method weights per plan	credit math, throttling, plan fit
Dashboard + billing	Endpoint config, usage, Stripe-based billing	credits, refunds, plan confusion

Who the customers are: dapps, wallets, exchanges, indexers, trading bots, and infra teams. They ship on top of these endpoints, so support is load-bearing. Every ticket is a live app degraded until it is answered.

What breaks, and where it sits

The recurring RPC-support tickets, in the customer's words, mapped to the likely cause, the layer it lives at, and the first check. Most tickets resolve at one of six layers (see §03).

Symptom (customer's words)	Likely cause	Layer	First check
"requests timing out"	DNS/TCP/TLS reach or wrong endpoint region	1 network	curl -w timing; ping the region
"getting 429 / rate limited"	Credit or method-weight limit for the plan	2 HTTP	read x-qn-* / rate headers, method weight
"missing trie node / no old state"	Full node queried for historical state	5 node	archive check: balance at old block
"eth_call reverts unexpectedly"	Contract logic, wrong block tag, or bad params	6 client	reproduce with explicit block + decode revert
"WebSocket keeps disconnecting"	Idle timeout or missing reconnect/resubscribe	3 envelope	heartbeat, re-eth_subscribe on open
"connected to wrong network"	Endpoint points at a different chain	4 method	eth_chainId, decode to network
"nonce too low / replacement underpriced"	Client tx nonce and gas management	6 client	eth_getTransactionCount pending vs latest
"response differs between providers"	Node client version or spec-detail diff	5 node	web3_clientVersion both sides, diff params
"billing / credits confusion"	Plan limits, method weights, Stripe	billing	usage in dashboard, plan vs method cost

One-line takeaway: most "the RPC is broken" tickets resolve at the client or plan layer. Reproducing them fast is the whole job, and it is what the tool in §05 automates.

The debugging playbook

How I triage a Web3 RPC ticket: an ordered layer model. Work top to bottom, stop at the first layer that fails, and give the customer the exact command that reproduces it. Every snippet below is copy-pasteable against any EVM endpoint.

Layer	Question	First command
1 · Network	DNS/TCP/TLS reachable, from where?	curl -w '%{time_total}' -o /dev/null
2 · HTTP	Status 200, or 401 / 429 / 5xx?	curl -i, read status + rate headers
3 · Envelope	Valid JSON-RPC 2.0, no error object?	pipe response to jq .error
4 · Method + params	Right method, right params, right block tag?	eth_chainId, eth_blockNumber
5 · Node capability	Archive vs full? Client version match?	eth_getBalance at old block
6 · Client logic	Nonce, gas, retry, reconnect on the app side?	reproduce with explicit params

Layers 1 to 4: reach, status, envelope, network

# block height + timing in one shot curl https://YOUR-ENDPOINT -w '\ntime_total=%{time_total}s\n' \ -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

# which chain am I actually on? curl https://YOUR-ENDPOINT -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' # 0x1 mainnet · 0x2105 Base · 0x89 Polygon · 0xa4b1 Arbitrum

# node client + version (provider diffs live here) curl https://YOUR-ENDPOINT -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"web3_clientVersion","params":[]}'

Layers 5 to 6: batch, archive, client behaviour

# does the endpoint support JSON-RPC batching? curl https://YOUR-ENDPOINT -X POST -H 'content-type: application/json' \ -d '[{"jsonrpc":"2.0","id":1,"method":"eth_chainId"}, {"jsonrpc":"2.0","id":2,"method":"eth_blockNumber"}]'

# archive check: state at an old block should NOT error curl https://YOUR-ENDPOINT -X POST -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance", "params":["0xUSER","0x1"]}' # "missing trie node" here = full node, needs archive

# local proxy to inspect a customer's outgoing Web3 calls mitmproxy --mode reverse:https://YOUR-ENDPOINT -p 8080 # point the customer app at localhost:8080, watch every # request/response; a small Node or Python proxy works too

The proxy step is the one the JD calls out directly: set up a local proxy to debug outgoing Web3 requests. It surfaces the real payload the customer's SDK sends, which is where "the RPC is broken" usually turns out to be a client bug.

Competitive map

The RPC-provider landscape QuickNode competes in. Fair reading of where each one wins and where QuickNode has the edge or the gap.

Provider	Position	Who they win	QuickNode edge / gap
Alchemy	Developer experience + enhanced APIs	App devs wanting rich tooling and SDKs	Edge: chain breadth. Gap: enhanced-API depth and docs polish.
Infura	Incumbent, Consensys / MetaMask default	Ethereum-first teams, MetaMask defaults	Edge: multi-chain and dedicated nodes. Gap: default-status inertia.
Ankr	Multichain + decentralized RPC	Cost-sensitive, many-chain teams	Edge: managed reliability and support. Gap: raw price.
Chainstack	Global regions, transparent pricing	Teams wanting region control and clear tiers	Edge: add-on marketplace and scale. Gap: pricing clarity.
dRPC	Decentralized, pay-as-you-go	Teams wanting metered, no-commit usage	Edge: SLAs and dedicated infra. Gap: pure usage-based pricing.
Public RPCs	Free community endpoints	Hobbyists, testing, low-stakes reads	Edge: reliability, rate limits, support. Gap: they are free.

Where QuickNode competes

Support responsiveness and multi-chain breadth are where QuickNode wins. Endpoints are close to a commodity, so the differentiators are uptime, the add-on surface, and how fast a human unblocks a broken integration. That makes TSE quality a moat, not a cost center.

★

Common-ticket runbook

Frequent tickets, each with a one-line resolution path. Terse by design.

Rate limited (429)

throttle

Read the rate headers, map the method to its credit weight, check plan limit. Fix: batch calls, cache reads, back off, or size the plan up.

Archive node needed

node

missing trie node on old-block reads means a full node. Fix: route historical queries to an archive endpoint.

WebSocket drops

envelope

Idle timeout closes the socket. Fix: add a heartbeat and re-run eth_subscribe on every reconnect.

CORS from browser

client

Browser blocks a direct call; error looks like a network failure. Fix: proxy RPC through the app backend, keep the key server-side.

ChainId mismatch

config

App points at the wrong network. Fix: confirm eth_chainId against the intended chain, correct the endpoint URL.

Latency / region

network

Slow calls from a far region. Fix: measure time_total from the app's region, move to a closer endpoint.

Live tool: RPC Doctor

RPC Doctor

Paste any EVM JSON-RPC endpoint (or your QuickNode URL) and it runs the first layer of support triage automatically.

Try it live ↗

The health battery it runs, each mapped to a layer from §03:

eth_chainId → network

Decodes the id to a named chain, so a wrong-network config shows up on the first check.

eth_blockNumber + latency

Confirms the node is live and current, and times the round trip for a region read.

web3_clientVersion

Surfaces the node client and version, the usual root cause of "responses differ between providers".

Batch support

Sends a JSON-RPC batch and confirms whether the endpoint honours it.

Archive check

Reads state at an old block and flags missing trie node as a full-vs-archive answer.

Endpoint failover

Takes a backup URL and shows which endpoint answered, a preview of a resilient client.

Clear errors for the usual failures

Each check prints a plain error for CORS, 401, 429, and timeouts, plus the equivalent curl for every check so a customer can reproduce it. Browser CORS may block some providers; the tool surfaces that as a clear error, which is itself a common support scenario (fix: proxy the call server-side).

Honesty: RPC Doctor is my own tool, built for this application. It is not QuickNode's code and does not touch QuickNode's systems. It calls whatever public endpoint you paste in.

JD duties, my plan

Each line from the role, mapped to a concrete plan or to evidence. Growth areas flagged honestly.

JD line	My plan / evidence
Handle technical customer support	Triage by the six-layer model in §03; answer with a reproduction, not a guess. The runbook in §★ is my starting library.
Write scripts to debug	RPC Doctor (§05) is exactly this: a script that runs the health battery and prints the equivalent curl. I extend it per recurring ticket.
Reproduce customer issues	Reproduce with the customer's exact method + params against the same endpoint; set up a local proxy (mitmproxy / small Node or Python) to capture the real outgoing call.
Translate hardships into eng tickets	File with: exact request, expected vs actual, layer, repro command, blast radius, and a minimal failing case. Engineering gets a ticket it can act on.
Thorough debugging + documenting for other teams	Every solved ticket becomes a runbook entry and, where it recurs, a doc/FAQ line so the next customer self-serves.
Preemptively solve before multi-customer impact	Watch for the same symptom across tickets; when a client version or method starts trending, flag it to eng and pre-write the customer note.
1+ yr blockchain	Onchain builder: EVM dapps with wallet connect, viem/wagmi, contract calls, and multi-chain configs. RPC is my daily surface.
JSON-RPC spec	Fluent in the envelope, error codes, block tags, batch, and eth_subscribe. The §03 playbook is written from that spec.
Linux hosts	Comfortable on Linux: curl, jq, tcpdump, systemd logs, and running local proxies for request inspection.
Monitoring / alerting	Used to log and metric dashboards; would wire endpoint health probes and alert on error-rate and latency trends.
Stripe refunds / credits	Comfortable with Stripe billing flows; would own credit adjustments and refund tickets with clear, auditable notes.
IaC (Terraform / Ansible)	Growth area. My infra experience is container and deploy oriented (Docker, nginx, CI deploys). I have not run Terraform/Ansible in anger and would ramp on it early.

First 90 days

Days 1 to 30 · Learn

Learn the stack: chains, plans, credit math, add-ons.
Shadow the ticket queue, watch how seniors triage.
Read the docs cover to cover; note gaps.
Map JSON-RPC edge cases per chain (Solana vs EVM).

Days 31 to 60 · Own

Own a slice of the queue end to end.
Build repro tooling and internal scripts per ticket type.
Turn recurring answers into runbooks.
Tighten the proxy workflow for client-side bugs.

Days 61 to 90 · Reduce

Cut repeat tickets with doc and FAQ fixes.
Add proactive alerting on error-rate and latency.
Feed ticket patterns back to engineering.
Publish a monthly top-issues note for the team.

Method & sources

Method: outside-in, public documentation only. No access to QuickNode's internal systems, tickets, or metrics. Symptoms and causes are drawn from the public JSON-RPC spec and common RPC-support patterns.

Company: quicknode.com · About · QuickNode docs

Spec: Ethereum JSON-RPC (ethereum.org) · JSON-RPC 2.0

Competitors: Alchemy · Infura · Ankr · Chainstack · dRPC

Live work: RPC Doctor tool

Figures (10B+ requests/month, ~120+ people, HQ, investors) are public and taken from QuickNode's site and the job description. Confirm current numbers before quoting.

Independent homework by Edward Tay for the QuickNode Technical Support Engineer application. Public information only. The RPC Doctor tool is my own, built for this application, not QuickNode's code.