"Decreased database query time by optimizing indexes." Technically true. Also completely forgettable. The verb hides what you actually did—profiling queries, rewriting joins, adding covering indexes—and the vague phrasing gives recruiters nothing to anchor on.
What weak 'decreased' bullets look like
Here are four real patterns we see on backend engineer resumes, with one-line autopsies:
"Decreased API response times through caching."
Zero specificity—what kind of caching? Redis? In-memory? What was the before/after? This reads like a task, not an outcome.
"Decreased system downtime by improving monitoring."
"Improving monitoring" is a means, not a method. What alerting did you add? What runbooks did you write? What was downtime before and after?
"Decreased costs by refactoring services."
Which services? What was the cost driver—compute, storage, egress? "Refactoring" is an umbrella term; recruiters want the action underneath.
"Decreased errors in production deployments."
From what baseline? To what target? Errors measured how—Sentry alerts, customer-reported incidents, rollback rate? This bullet could mean anything.
Each bullet uses "decreased" as a placeholder where a sharper verb and a number belong.
Stronger swaps — 15 synonyms
| Synonym | When it fits | Resume bullet |
|---|---|---|
| Slashed | Dramatic, deliberate cuts—latency, cost, error rates | Slashed p99 API latency from 2.1s to 340ms by replacing N+1 queries with batched RPC calls |
| Eliminated | Removing something entirely—bottlenecks, manual steps, failure modes | Eliminated replication lag spikes by migrating from async to semi-sync postgres replication across 12 read replicas |
| Halved | Exactly 50% reduction—clean, specific, memorable | Halved docker image build times (14min → 7min) by parallelizing multi-stage builds and caching dependency layers |
| Cut | Direct, forceful—pairs well with cost or time metrics | Cut Redis memory usage by 68% (22GB → 7GB) by introducing TTL policies and migrating cold keys to postgres |
| Compressed | Technical precision—data size, payloads, throughput | Compressed gRPC payloads by 81% using protocol-buffer field pruning and zstd encoding, saving 4.2TB/month in egress |
| Trimmed | Incremental, careful optimization—often ongoing work | Trimmed background job queue depth from 18K to 3K tasks by tuning worker concurrency and adding job deduplication |
| Dropped | Sudden, measurable fall—often tied to infrastructure changes | Dropped 503 error rate from 1.8% to 0.09% by adding circuit breakers to third-party service calls |
| Lowered | Gradual, controlled reduction—SLOs, thresholds, baselines | Lowered storage costs $14K/month by implementing tiered S3 lifecycle policies across 480TB of logs |
| Reduced | Generic but serviceable—use when the verb isn't the star | Reduced schema migration downtime from 90min to 4min using online DDL and ghost table swaps in MySQL |
| Shrank | Physical or logical size reduction—databases, queues, indexes | Shrank main postgres table from 2.4TB to 890GB by archiving records older than 18 months to cold storage |
| Minimized | Deliberate containment—blast radius, attack surface, failure domains | Minimized cascading failure risk by isolating payment services into separate k8s namespace with dedicated resource quotas |
| Curbed | Controlling growth or runaway behavior—costs, alerts, retries | Curbed spurious alerting by 73% (940 alerts/week → 250) by tuning CloudWatch thresholds and consolidating duplicate monitors |
| Downsized | Capacity or instance right-sizing—compute, fleet, clusters | Downsized RDS instances from db.r5.8xlarge to db.r5.4xlarge after query optimization freed 60% CPU headroom |
| Diminished | Softer, less aggressive—good for incremental or passive gains | Diminished cold-start latency for Lambda functions from 1.9s to 680ms by enabling provisioned concurrency for top 6 endpoints |
| Contracted | Narrowing scope or footprint—often paired with architectural decisions | Contracted service dependency graph from 47 to 22 edges by consolidating shared utility libs into a single internal SDK |
Three rewrites
Taking three of the bad examples from above and giving them teeth:
Before: "Decreased API response times through caching."
After: Slashed p95 API response time from 820ms to 140ms by deploying Redis cluster and caching 200K user profile objects with 15min TTL.
Why it works: Specific latency percentile, exact numbers, named technology, cache strategy detail.
Before: "Decreased costs by refactoring services."
After: Cut monthly AWS spend by $22K (18%) by migrating batch processing from Lambda to Fargate Spot and compressing S3 event payloads.
Why it works: Dollar amount, percentage, named services, two concrete actions.
Before: "Decreased errors in production deployments."
After: Dropped rollback rate from 11% to 2% by adding schema validation to CI pipeline and introducing feature flags for gradual traffic ramp.
Why it works: Clear metric, before/after, two technical mechanisms that together deliver the result.
When 'decreased' is genuinely the right word
Sometimes the gentler verb fits:
Gradual, passive trends. If you monitored a metric that organically declined over months due to cumulative small fixes, "decreased" captures that drift without overclaiming a single heroic action.
Softer compliance or policy language. In audit or security contexts—"decreased privileged-account usage"—the term can signal controlled, measured progress rather than a dramatic overhaul.
When the mechanism is a black box. If a vendor upgrade or platform change delivered the gain and you didn't touch the internals, "decreased" honestly signals you observed the improvement without owning the mechanism.
Why uncommon verbs can backfire for non-native recruiters
We built Sorce because job applications are broken. One quiet piece of that: many recruiters—especially at outsourced TA firms or international teams—parse resumes in their second or third language. Verbs like "orchestrated," "spearheaded," or "catalyzed" force a lookup that slows the scan. "Decreased" is weak, but it's clear. The fix isn't to swap in fancier synonyms—it's to pair a common, direct verb ("cut," "dropped," "slashed") with a number that does the convincing. Clarity beats cleverness. A recruiter who has to pause to decode "ameliorated" is a recruiter who's already moved to the next resume. When sending your resume via email, the subject line and first bullet need to land in under three seconds—exotic verbs burn that budget without buying signal.
40 free swipes a day. Sorce applies, you swipe.
For more: curated synonym, debated synonym, delegated synonym, detected synonym, distributed synonym
Frequently Asked Questions
- What's a stronger word than 'decreased' for a backend engineer resume?
- Words like 'eliminated,' 'compressed,' 'slashed,' or 'trimmed' are stronger because they imply intentional action and technical precision. Pair them with specific metrics—latency, error rates, query times—to show real impact.
- Should I use 'decreased' or 'reduced' on my resume?
- 'Reduced' is marginally stronger because it's more direct, but both are weak without numbers. Better options include 'cut,' 'halved,' or 'dropped,' which sound more decisive and pair naturally with percentages or absolute values.
- When is 'decreased' the right word for a resume bullet?
- 'Decreased' works when you're describing gradual, continuous improvement over time—like monitoring a metric that slowly trended down. For sudden drops or deliberate optimization work, stronger verbs like 'slashed' or 'eliminated' better capture the action.