DeWu 2024 Backend Salary Insights & Deep Dive into Java Interview Questions
The article reveals detailed 2024 campus recruitment salary packages for DeWu’s backend, SRE, and client development roles, compares offer tiers, shares interview difficulty, and provides in‑depth technical explanations of Redis key expiration, MySQL redo/undo logs, crash recovery, thread context switching, and performance optimizations.
Author 小林 shares the 2024 campus recruitment salary data for DeWu (得物), focusing on backend development, SRE operations, and client development positions. The offers range from 26k to 39k monthly base, with total annual packages from 41.6w to 63.4w RMB, plus a 1200 RMB monthly housing allowance. Typical offers cluster around 40w‑50w, matching first‑tier tech companies.
Backend Development – 26k × 16 → 41.6w (Shanghai)
SRE Operations – 27k × 16 → 43.2w (Shanghai)
Backend Development – 27k × 16 → 43.2w (Shanghai)
Backend Development – 29k × 16 → 46.4w (Shanghai)
Frontend Development – 29k × 16 → 46.4w (Shanghai)
Backend Development – 30k × 16 → 48.0w (Hangzhou)
Client Development – 31k × 16 → 49.6w (Shanghai)
Backend Development – 34k × 16 + 10w signing bonus → 55.4w (Shanghai)
Backend Development – 39k × 16 + 5w signing bonus + 20w four‑year incentive → 63.4w (Shanghai)
The author categorises offers: 26k‑27k as regular, 29k‑32k as "SP" tier, and above 34k as "SSP" tier. While a few exceptional cases reach 39k base and 63.4w total, most candidates can expect 26k‑30k.
Regarding interview difficulty, DeWu’s Java backend interview aligns with top‑tier tech firms, emphasizing deep knowledge of MySQL, Redis, and operating systems. Sample questions and detailed answers are provided:
Redis Key Expiration
When a key has a TTL, Redis does not delete it instantly at expiration. Instead, it uses a mixed strategy:
Lazy deletion : The key is removed when accessed after expiration, returning nil if it no longer exists.
Periodic deletion : Every 100 ms (configurable via hz), Redis samples 20 random keys with expiration; if over 25 % are expired, it repeats up to 10 times to free memory.
MySQL Redo and Undo Logs
In InnoDB, redo logs are generated during transaction execution for every data‑page modification and are flushed asynchronously (by default at commit). Undo logs record the previous state of modified rows, enabling transaction rollback and MVCC.
Crash Recovery Process
Recovery proceeds in two steps:
Apply redo logs for all committed transactions whose changes were not yet persisted to data pages, ensuring durability.
Use undo logs to roll back any uncommitted transactions, restoring atomicity.
CPU/Memory Alert Handling (SRE Operations)
When an alert fires, the author follows "stop‑loss, diagnose, optimise":
Never restart the service immediately; first collect diagnostics with top or htop.
For high CPU, identify the hot thread using top -H -p <PID>, then locate its stack with jstack and generate a flame graph via async-profiler.
For high memory, check GC activity with jstat -gcutil, inspect live objects with jmap -histo:live, and, if needed, create a heap dump for MAT analysis.
After pinpointing the root cause, fix code defects or adjust JVM parameters (e.g., switch to G1 GC).
Why MySQL Uses B+Tree Instead of Red‑Black Tree
B+Tree stores data only in leaf nodes, reducing node size and I/O, and links leaves for efficient range scans.
Compared with B‑Tree or hash indexes, B+Tree offers lower disk I/O and better range‑query performance for large datasets.
Why Java HashMap Switches to Red‑Black Tree, Not B+Tree
HashMap operates entirely in memory, where B+Tree’s multi‑branch design for disk I/O offers no benefit. Red‑Black trees are lightweight, self‑balancing, and sufficient for the rare cases where a bucket exceeds eight entries.
Redis Hash Internal Structure
Redis stores small hashes (<512 fields, each <64 bytes) as a compact ziplist (now listpack in Redis 7.0). When thresholds are exceeded, it transparently converts to a standard hashtable , similar to Java’s HashMap, preserving O(1) access.
Why Redis Is So Fast
Redis achieves high performance through pure‑memory storage, a single‑threaded event loop (avoiding lock contention), and carefully chosen data structures that adapt to size: strings use integer encoding when possible, hashes switch between ziplist/listpack and hashtable, sets use intset or hashtable, sorted sets use ziplist or skiplist + hashtable, and lists use quicklist. These choices minimise memory fragmentation and maximise CPU cache hits.
Thread Context Switching
A context switch saves the current thread’s CPU registers and stack state, selects the next runnable thread, and restores its state. Frequent switches incur overhead, so high‑concurrency systems aim to reduce unnecessary thread churn.
Concurrency vs Parallelism on Single vs Multi‑CPU
On a single CPU core, multiple threads run concurrently via rapid time‑slice scheduling, giving the illusion of parallelism. With multiple cores, threads can truly execute in parallel, improving throughput. Overall, the article combines practical salary information, interview preparation tips, and deep technical explanations of backend systems, making it a valuable resource for aspiring backend engineers and SRE practitioners.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Services Circle
Delivering cutting-edge internet insights and practical learning resources. We're a passionate and principled IT media platform.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
