Core coding concepts: variables, functions, loops, conditionals, data structures — the building blocks of every program
Variables store data with a type; use integer cents for money, never floats
Functions encapsulate reusable logic; one job per function prevents copy-paste bugs
Loops repeat code; prefer for-each over index-based for safety
Conditionals branch execution; keep conditions simple or extract into named booleans
Data structures determine performance; HashMap for O(1) key lookup, Set for membership, List for ordered sequences
Production insight: wrong data structure at scale causes latency spikes; duplicated logic creates silent diverging bugs
Plain-English First
Think of a program like a restaurant kitchen. Variables are the containers on the shelf — a bowl for flour, a pot for stock. Functions are the recipes: a fixed set of steps that turn raw ingredients into a dish, and you can run that recipe as many times as you want without rewriting it. Loops are the line cook cracking 200 eggs one at a time until the batch is done. Conditionals are the head chef's rule: if the steak is under 55°C, it goes back on the grill — otherwise, it goes to the pass. The whole kitchen runs on these four ideas, and so does every piece of software ever written.
A startup I consulted for lost $40,000 in a single weekend because a developer copy-pasted the same 30-line pricing calculation in eleven different places, tweaked one copy to fix a rounding bug, and forgot the other ten. Every concept covered here exists specifically to prevent that kind of disaster.
These aren't beginner topics you graduate from. They're the atomic units that everything else — microservices, machine learning pipelines, distributed databases — is built from. Get them fuzzy in your head and you'll spend your career fighting symptoms instead of understanding causes. Get them sharp and you'll read unfamiliar codebases like a native speaker reads a newspaper.
By the end of this you'll be able to: write a function that does exactly one thing and does it predictably, use loops without accidentally running them forever, make your program take different paths based on real conditions, and pick the right data structure so you're not searching a 10,000-item list one-by-one when you don't have to. Concrete skills. Not vocabulary.
Variables and Data Types: Why Naming Things Correctly Saves Your 3am
Before variables existed in a structured way, early programmers worked with raw memory addresses — literal hexadecimal locations like 0x00A4. Change anything about your program and those addresses shift. You've now broken everything and the compiler won't help you find it. Variables are the abstraction that saves you from that nightmare. You give a meaningful name to a storage location and let the machine worry about where it actually lives.
Every variable has two properties that matter: its name and its type. The name is for humans. The type tells the computer how many bytes to reserve and what operations are legal. You can multiply two integers. You can't multiply two words. This sounds obvious until you're debugging a Node.js service at 2am where JavaScript silently coerced the string '42' into the number 42 mid-calculation and your invoice totals are now subtly wrong across 6,000 orders.
Name your variables after what they contain, not how they're used. orderTotalInCents is a variable. x is a crime. The person debugging your code at midnight might be you, and future-you will not remember what x meant. Every variable name is a comment you don't have to maintain separately.
Data types are the contract the variable makes with the rest of your code. An integer promises it's a whole number. A boolean promises it's either true or false — never null, never 'yes', never 1. Break the contract and your program either crashes loudly (good) or silently does the wrong thing (catastrophic). Always prefer explicit types over letting the language guess. The three minutes you save by not typing the type will cost you three hours when the guess is wrong.
OrderPricingService.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package io.thecodeforge.cs;
publicclassOrderPricingService {
publicstaticvoidmain(String[] args) {
// Store the price in CENTS (integer), never floating-point dollars.// Floats cannot represent 0.10 exactly — this has caused real billing bugs.
int unitPriceInCents = 1099; // $10.99 per item
int quantityOrdered = 3; // How many the customer wants// A boolean that controls downstream logic — shipping rules, tax rules, etc.// Name it as a statement that is either true or false, never 'flag' or 'status'.boolean isEligibleForFreeShipping = false;
// String for human-readable display only — never do arithmetic on this.String productName = "Wireless Keyboard";
// Calculate total: integer multiplication — no floating-point rounding errors.int orderTotalInCents = unitPriceInCents * quantityOrdered;
// Apply free shipping threshold: orders over $50 (5000 cents) qualify.// We check BEFORE formatting, so the logic lives here — not scattered in the UI.if (orderTotalInCents >= 5000) {
isEligibleForFreeShipping = true;
}
// Format for display ONLY at the very end — never store dollars as a double.double orderTotalInDollars = orderTotalInCents / 100.0;
System.out.println("Product : " + productName);
System.out.println("Unit price : $" + String.format("%.2f", unitPriceInCents / 100.0));
System.out.println("Quantity : " + quantityOrdered);
System.out.println("Order total : $" + String.format("%.2f", orderTotalInDollars));
System.out.println("Free shipping : " + isEligibleForFreeShipping);
}
}
Output
Product : Wireless Keyboard
Unit price : $10.99
Quantity : 3
Order total : $32.97
Free shipping : false
Production Trap: Never Store Money as a Float
double price = 0.10 + 0.20 gives you 0.30000000000000004 in Java, JavaScript, Python — every language. That four-trillionths of a cent becomes a rounding error that accumulates across millions of transactions. Store all monetary values as integer cents (or use BigDecimal if you must use decimal). This exact bug has triggered financial audits at companies I've worked with.
Production Insight
Type coercion in dynamically-typed languages is the #1 source of silent variable bugs.
In production, a string concatenation that looks like addition can corrupt thousands of records before anyone notices.
Rule: Use explicit type annotations and never mix types in arithmetic operations.
Key Takeaway
Name variables by what they contain, not how they're used.
Store money as integer cents — never use floats for currency.
Explicit types > implicit guessing — the compiler catches what you miss.
Functions: The One Rule That Prevents the Copy-Paste Death Spiral
The startup I mentioned in the intro? Their root cause was a violation of the most important rule in software: write a piece of logic once, name it, and call it. That's a function. Every time you copy-paste code instead of extracting a function, you create a new place where bugs can hide independently of each other.
A function takes inputs (called parameters), does something predictable with them, and returns an output. That's the whole deal. The power isn't the syntax — it's the contract. When calculateDiscountedPrice is called 500 times across your codebase and you fix a bug in it, you've fixed it in all 500 places simultaneously. Copy-paste gives you 500 separate bugs waiting to diverge.
The rule that separates functions that age well from functions that become nightmares: one function, one job. If you find yourself writing processOrderAndSendEmailAndUpdateInventory, stop. That's three functions being smuggled inside one name. Functions that do one thing are trivially testable, trivially debuggable, and trivially reusable. Functions that do three things in a trench coat are none of those things.
Parameters are the inputs your function needs to do its job. Return values are the output it promises to produce. Keep both small. A function that needs 8 parameters to work is a sign that either you need a data object to group them, or the function is doing too much. I've seen functions at FAANG-adjacent companies with 14 parameters. Every single one was a maintenance timebomb waiting on a deadline.
DiscountCalculator.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
package io.thecodeforge.cs;
publicclassDiscountCalculator {
/**
* Calculates the discounted price in cents.
* Single responsibility: take a price and a discount rate, return the result.
* No side effects — doesn't print, doesn't update a database, doesn't log.
* That makes it testable in isolation without mocking anything.
*
* @param originalPriceInCents The pre-discount price (must be >= 0)
* @param discountPercentage Discount as a whole number 0-100 (e.g. 20 means 20% off)
* @returnThe price after discount, in cents
*/
publicstaticintcalculateDiscountedPrice(int originalPriceInCents, int discountPercentage) {
// Guard clause: reject bad input immediately rather than silently computing garbage.// Failing fast here beats returning a wrong price that reaches the payment processor.if (originalPriceInCents < 0) {
thrownewIllegalArgumentException("Price cannot be negative: " + originalPriceInCents);
}
if (discountPercentage < 0 || discountPercentage > 100) {
thrownewIllegalArgumentException("Discount must be 0-100, got: " + discountPercentage);
}
// Calculate discount amount first, then subtract — avoids floating-point math.int discountAmountInCents = (originalPriceInCents * discountPercentage) / 100;
return originalPriceInCents - discountAmountInCents;
}
/**
* Formats a cent value into a human-readable dollar string.
* Separate function because formatting is a different job from calculating.
* Now you can change your currency display format in one place.
*/
publicstaticStringformatAsDollars(int amountInCents) {
returnString.format("$%.2f", amountInCents / 100.0);
}
publicstaticvoidmain(String[] args) {
int originalPrice = 4999; // $49.99
int discountRate = 20; // 20% off// Call the function — same logic works for every product without copy-pasting.int discountedPrice = calculateDiscountedPrice(originalPrice, discountRate);
System.out.println("Original price : " + formatAsDollars(originalPrice));
System.out.println("Discount : " + discountRate + "%");
System.out.println("Discounted price: " + formatAsDollars(discountedPrice));
System.out.println("You save : " + formatAsDollars(originalPrice - discountedPrice));
}
}
Output
Original price : $49.99
Discount : 20%
Discounted price: $39.99
You save : $10.00
Senior Shortcut: Guard Clauses First, Logic Second
Always validate your inputs at the top of the function and return/throw immediately if they're wrong. This is called a guard clause. It keeps the happy path un-nested and readable, and it means your function's core logic never runs on garbage data. The alternative — wrapping everything in a giant if-else — is how you get 8-level indentation that nobody wants to touch.
Production Insight
Copy-pasted logic is the leading cause of production inconsistency bugs.
I've seen a pricing error in a checkout flow that didn't affect reports because the report module had its own copy.
Rule: When you fix a bug, search your entire codebase for duplicate logic before marking it resolved.
Key Takeaway
Extract the first duplicate into a function — don't wait for three copies.
One function, one job — if the name contains 'and', split it.
Guard clauses protect your function from garbage inputs.
Loops and Conditionals: Controlling What Runs, How Many Times, and When
These two concepts are where programs stop being calculators and start being intelligent. A calculator computes one fixed thing. A program decides what to do based on conditions and can repeat work without you spelling out every step.
A conditional (if/else) is a fork in the road. Your program evaluates a statement that is either true or false, then takes the appropriate path. The condition must be binary — it can't be 'sort of true'. This is why booleans exist. When you see developers stuffing complex logic into a condition — five AND operators, two OR operators, a function call, and a negation — that's a sign the logic needs a named function. if (isOrderEligibleForExpressShipping(order)) is readable. if (!order.weight > 5 && order.destination != null && (order.tier == 'GOLD' || order.totalInCents > 10000) && !order.isFlaggedForReview) is a bug you haven't found yet.
A loop repeats a block of code until a condition is no longer true. The most dangerous thing a loop can do is run forever — an infinite loop that never exits will freeze your program and, in server environments, consume 100% of a CPU core until the process is killed. I've seen this happen in production when a while-loop's exit condition was accidentally set inside an if-block that never triggered, and the thread sat spinning for 40 minutes before monitoring caught it.
The most common loops you'll use:for when you know exactly how many times to repeat, while when you repeat until a condition changes, and for-each when you're walking every item in a collection. Don't use a while where a for is clearer. The right loop for the job makes the intent obvious without reading the body.
ShoppingCartProcessor.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
package io.thecodeforge.cs;
import java.util.Arrays;
import java.util.List;
publicclassShoppingCartProcessor {
// Represents a single item in a shopping cart.// Using a record-style structure so the data is obvious at a glance.staticclassCartItem {
String productName;
int priceInCents;
int quantity;
boolean isPerishable; // Perishables need cold-chain shipping — different logic applies.CartItem(String productName, int priceInCents, int quantity, boolean isPerishable) {
this.productName = productName;
this.priceInCents = priceInCents;
this.quantity = quantity;
this.isPerishable = isPerishable;
}
}
publicstaticvoidmain(String[] args) {
// A realistic cart — three different products, one perishable.List<CartItem> cart = Arrays.asList(
newCartItem("Wireless Keyboard", 4999, 1, false),
newCartItem("USB-C Hub", 2999, 2, false),
newCartItem("Organic Greek Yoghurt", 349, 4, true)
);
int cartTotalInCents = 0;
boolean requiresColdChain = false; // Flipped to true if ANY item is perishable.// for-each loop: we don't need an index, we just need every item.// This is clearer than a traditional for-loop when index doesn't matter.for (CartItem item : cart) {
// Calculate line total for this item.int lineTotalInCents = item.priceInCents * item.quantity;
cartTotalInCents += lineTotalInCents; // Accumulate into the cart total.// Conditional: check if this item forces cold-chain shipping.// Once true, it stays true — one perishable item affects the whole order.if (item.isPerishable) {
requiresColdChain = true;
}
System.out.printf(" %-25s x%d = $%.2f%n",
item.productName,
item.quantity,
lineTotalInCents / 100.0);
}
System.out.println(" ─────────────────────────────────────────");
System.out.printf(" Cart total: $%.2f%n", cartTotalInCents / 100.0);
// Conditional with else: only one path runs — not both.if (requiresColdChain) {
System.out.println(" Shipping: Cold-chain required (+$12.99 surcharge)");
} else {
System.out.println(" Shipping: Standard");
}
}
}
Output
Wireless Keyboard x1 = $49.99
USB-C Hub x2 = $59.98
Organic Greek Yoghurt x4 = $13.96
─────────────────────────────────────────
Cart total: $123.93
Shipping: Cold-chain required (+$12.99 surcharge)
The Classic Bug: Off-By-One in Loop Bounds
The most common loop bug is iterating one step too far or stopping one step too early — called an off-by-one error. Classic symptom: ArrayIndexOutOfBoundsException in Java, or silently skipping the last item. If your loop touches array indices directly, double-check: does it start at 0 or 1? Does it use < length or <= length? A for-each loop eliminates this entire class of bug — use it whenever you don't need the index.
Production Insight
Infinite loops in production aren't caught by tests — they manifest as CPU spikes and timeout alerts.
The worst case: a loop that only runs forever with specific data, making it impossible to reproduce locally.
Rule: Every production while-loop needs a maximum iteration counter and a fallback.
Key Takeaway
Prefer for-each over index-based loops to eliminate off-by-one errors.
Extract complex conditionals into named boolean functions.
Always add a safety counter to while-loops that process external data.
Data Structures: Picking the Right Container Stops You Searching 10,000 Items One-by-One
A data structure is how you organise information in memory so your program can find, add, and remove it efficiently. Pick the wrong one and a lookup that should take a millionth of a second takes a full second. At scale, that's the difference between a snappy API and a timeout that pages your on-call at 2am.
The three you'll use constantly as a beginner: Arrays/Lists, HashMaps, and Sets. A List stores items in order and lets you access them by position — perfect when sequence matters, like a queue of tasks or a history of events. A HashMap stores key-value pairs and finds any value instantly by its key — perfect when you need to look something up by an identifier. A Set stores unique items with no duplicates — perfect when you need to know whether something exists, without caring about order.
The critical concept behind HashMap performance is hashing. When you store userId → userProfile, the HashMap runs a mathematical function on userId to compute a bucket number, then drops the profile in that bucket. Lookup runs the same function, finds the same bucket, and retrieves it — in constant time, meaning it takes the same amount of time whether the map has 10 entries or 10 million. A List lookup doesn't work this way — it checks item 1, then item 2, then item 3... all the way until it finds a match. On 10,000 items, that averages 5,000 comparisons per lookup. I've seen a product catalogue feature grind a server to a halt because a developer used a List of products and searched it linearly for every incoming HTTP request. Switching to a HashMap keyed by product ID dropped the p99 latency from 4,200ms to 8ms.
Use a List when order matters. Use a HashMap when you need fast lookup by a key. Use a Set when you need to know 'is this thing already in here?' without duplicates.
ProductCatalogueService.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
package io.thecodeforge.cs;
import java.util.*;
publicclassProductCatalogueService {
// Represents a product in the catalogue.staticclassProduct {
String productId; // Unique identifier — this becomes our HashMap key.String name;
int priceInCents;
String category;
Product(String productId, String name, int priceInCents, String category) {
this.productId = productId;
this.name = name;
this.priceInCents = priceInCents;
this.category = category;
}
}
publicstaticvoidmain(String[] args) {
// HashMap<Key, Value>: productId → Product object.// Lookup by productId is O(1) — constant time regardless of catalogue size.// If this were a List, lookup would be O(n) — slower as catalogue grows.Map<String, Product> catalogue = newHashMap<>();
// Load catalogue — in production this would come from a database or cache.
catalogue.put("KB-001", newProduct("KB-001", "Wireless Keyboard", 4999, "Peripherals"));
catalogue.put("HB-002", newProduct("HB-002", "USB-C Hub", 2999, "Peripherals"));
catalogue.put("MN-003", newProduct("MN-003", "4K Monitor", 34999, "Displays"));
catalogue.put("MS-004", newProduct("MS-004", "Ergonomic Mouse", 3499, "Peripherals"));
// Simulate an incoming order with product IDs — exactly what an API receives.List<String> orderedProductIds = Arrays.asList("KB-001", "MN-003", "XX-999");
// Set to track which categories appear in this order — no duplicates needed.Set<String> categoriesInOrder = newHashSet<>();
int orderTotalInCents = 0;
System.out.println("Processing order:");
for (String productId : orderedProductIds) {
// HashMap.get() is O(1) — instant lookup, no matter how big the catalogue is.Product product = catalogue.get(productId);
if (product == null) {
// Product not found — log it and skip. Don't crash the whole order.System.out.println(" WARNING: Product not found in catalogue: " + productId);
continue; // Skip to the next item in the loop.
}
orderTotalInCents += product.priceInCents;
// Set.add() ignores duplicates automatically — no need for an if-check.
categoriesInOrder.add(product.category);
System.out.printf(" %-10s %-25s $%.2f%n",
product.productId,
product.name,
product.priceInCents / 100.0);
}
System.out.println(" ──────────────────────────────────────────");
System.out.printf(" Order total: $%.2f%n", orderTotalInCents / 100.0);
System.out.println(" Categories in this order: " + categoriesInOrder);
}
}
Output
Processing order:
KB-001 Wireless Keyboard $49.99
HB-002 USB-C Hub $29.99
MN-003 4K Monitor $349.99
WARNING: Product not found in catalogue: XX-999
──────────────────────────────────────────
Order total: $429.97
Categories in this order: [Displays, Peripherals]
Interview Gold: What O(1) vs O(n) Actually Means in Production
O(1) means the operation takes the same time no matter how much data you have. O(n) means it takes linearly longer as data grows — double the data, double the time. A HashMap lookup is O(1). Searching a List for a specific value is O(n). At 100 items the difference is invisible. At 500,000 items it's the difference between an API that responds in 5ms and one that times out at 30 seconds. Always ask: 'what happens to this code when the data is 1000x bigger?'
Production Insight
The most common production performance bug: using a List for key-based lookup because 'it works fine in tests'.
Tests use small datasets — production data is 1000x larger, and O(n) becomes a timeout.
Rule: Choose your data structure based on the operation, not the current size.
Every program encounters unexpected situations: a file doesn't exist, a network request times out, a user enters invalid input. How your code responds to these situations separates brittle systems from production-resilient ones.
Fail fast means you detect invalid state as early as possible and stop execution rather than silently propagating garbage. A null reference that gets passed through six layers of functions before finally crashing is a nightmare to debug. Check at the boundary where data enters your system — API input, file read, database query — and reject it immediately if it's invalid. Guard clauses at the top of functions do exactly this.
Fail clearly means when something goes wrong, your error message tells you exactly what happened, where, and with what data. NullPointerException at line 42 is useless. UserNotFoundException: user 'johndoe' not found in database is actionable. Log the context — the input that caused the failure, the state of the system, the stack trace — so you don't have to reproduce the bug to understand it.
Fail recoverably means when an error occurs, the system can continue operating in a degraded mode instead of crashing entirely. If the payment service is down, you can queue the order and retry later, rather than showing a 500 error to the user. If a cache lookup fails, fall back to the database and log the miss. Don't let a single failure bring down the entire request.
The alternative — catching all exceptions and doing nothing, or letting every failure crash the application — causes data corruption, customer frustration, and pager fatigue. Invest in error handling upfront: it's insurance against the 2am call.
PaymentProcessor.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
package io.thecodeforge.cs;
import java.util.logging.Logger;
publicclassPaymentProcessor {
privatestaticfinalLogger logger = Logger.getLogger(PaymentProcessor.class.getName());
/**
* Attempts to charge a customer.
* Fails fast if inputs are invalid, fails clearly by logging the cause,
* and fails recoverably by throwing a checked exception the caller can handle.
*/
publicstaticbooleanchargeCustomer(String customerId, int amountInCents) {
// Guard clause: fail fast on invalid inputif (customerId == null || customerId.isBlank()) {
thrownewIllegalArgumentException("Customer ID must not be null or blank");
}
if (amountInCents <= 0) {
thrownewIllegalArgumentException("Amount must be positive, got: " + amountInCents);
}
try {
// Simulated payment gateway call (could throw IOException, timeout, etc.)boolean success = PaymentGateway.charge(customerId, amountInCents);
if (!success) {
// Fail clearly: log the specific failure
logger.warning("Payment declined for customer " + customerId + " amount " + amountInCents);
}
return success;
} catch (PaymentGatewayTimeoutException e) {
// Fail recoverably: log and rethrow as a checked exception so caller decides retry or fallback
logger.severe("Payment gateway timeout for customer " + customerId + ": " + e.getMessage());
thrownewPaymentProcessingException("Unable to process payment, try again later", e);
} catch (Exception e) {
// Catch-all for unexpected errors — log FULL context, don't swallow
logger.severe("Unexpected payment failure for customer " + customerId + ": " + e.getMessage());
thrownewPaymentProcessingException("Internal payment error", e);
}
}
// Custom exception class so callers can handle payment failures specificallystaticclassPaymentProcessingExceptionextendsRuntimeException {
publicPaymentProcessingException(String message, Throwable cause) {
super(message, cause);
}
}
// Stub for demonstrationstaticclassPaymentGateway {
staticbooleancharge(String customerId, int amountInCents) throwsPaymentGatewayTimeoutException {
// simulatereturntrue;
}
}
staticclassPaymentGatewayTimeoutExceptionextendsException {
publicPaymentGatewayTimeoutException(String message) {
super(message);
}
}
}
Output
(No output — the code demonstrates structure, not a runnable output)
The Golden Rule of Error Handling
Never catch an exception unless you can either handle it (fix the issue, retry, return a fallback) or add context (wrap it in a more meaningful exception). Catching and swallowing exceptions without logging is how data corruption happens silently. If you can't handle it, let it crash — loudly.
Production Insight
The most expensive bug I've investigated was caused by an empty catch block in a batch processor.
Exceptions were swallowed, the batch continued processing corrupted data for 6 hours.
Rule: If you catch an exception, either log it, wrap it, or handle it — never nothing.
Key Takeaway
Fail fast: validate inputs at boundaries.
Fail clearly: log context, not just stack traces.
Fail recoverably: let callers decide retry vs fallback via checked exceptions.
● Production incidentPOST-MORTEMseverity: high
Copy-Pasted Pricing Calculation Cost $40,000
Symptom
Customers were charged incorrect amounts; some were overcharged a few cents, others were undercharged by up to $5. The accounting team noticed after a weekend of transactions.
Assumption
Copy-pasting the same pricing calculation across multiple modules was harmless — each copy worked independently, so fixing one would fix all.
Root cause
The pricing logic was not extracted into a single function. A rounding bug was fixed in one copy (the checkout module) but remained in ten other places (invoice generation, email confirmations, reporting, etc.).
Fix
Extract the pricing calculation into a single function calculateDiscountedPrice(int originalPriceInCents, int discountPercentage), call it everywhere, and write a single unit test that covers the rounding edge case.
Key lesson
The moment you copy-paste code instead of extracting a function, you create a bug that will diverge silently from its copies.
One function, one test — if the logic lives in one place, fixing it fixes all callers.
Monetary logic must use integer cents, not floats, to avoid IEEE 754 rounding errors.
Production debug guideQuick symptom-to-action guide for common failures5 entries
Symptom · 01
Variable has unexpected value at runtime
→
Fix
Check for implicit type coercion (e.g., string concatenation mixing numbers) or variable shadowing in nested scopes. Print or log the variable just before its use.
Symptom · 02
Function returns wrong result or behaves inconsistently
→
Fix
Isolate the function with known inputs. Check parameter values at call site. Verify the function has no side effects that modify global state. Add guard clauses for invalid inputs.
Symptom · 03
Loop runs forever or crashes the thread
→
Fix
Inspect the exit condition — ensure the loop body modifies a variable that eventually makes the condition false. Add a maximum iteration counter as a safety valve. Use a for-each loop where possible to eliminate index errors.
Symptom · 04
Conditional takes the wrong branch
→
Fix
Evaluate the condition on a whiteboard — decompose complex compound conditions into separate named booleans. Log each part of the condition to find the failing sub-expression.
Symptom · 05
Data structure lookup gets slower as data grows
→
Fix
Identify the data structure used. Searching a List for a value is O(n). Switch to a HashMap (for key-based lookup) or HashSet (for existence check). Confirm the hashing function distributes keys evenly.
★ Quick Debug Cheat Sheet for Core ConceptsWhen something breaks, use these immediate steps before diving deep.
Function returns wrong output−
Immediate action
Write a minimal test with hard-coded inputs outside the production flow.
Commands
Print all input parameters and intermediate values inside the function.
Trace the call stack to confirm the function is called with expected arguments.
Fix now
Add guard clauses for invalid inputs and return early. Extract the function if it's doing more than one thing.
Loop doesn't terminate+
Immediate action
Check the loop condition and ensure the body changes a variable that affects it.
Commands
Add a counter that increments each iteration and break after a max (e.g., 10,000).
Replace manual increment with a for-each loop over a collection if possible.
Fix now
Insert a safety valve: int iterations = 0; while (condition && iterations++ < MAX_SAFE). Investigate why condition never became false.
API response time spikes as data grows+
Immediate action
Identify the slow operation — is it a loop, a search, or a database query?
Commands
Check if you're using a List and calling `.contains()` or iterating to find an element.
Profile with a timer: log elapsed time for the suspect operation with a small dataset vs production size.
Fix now
Replace the List with a HashMap for key-based lookup or a HashSet for membership tests. Aim for O(1) operations.
Data Structure Trade-offs
Data Structure
Best For
Lookup Speed
Allows Duplicates
Preserves Order
List (ArrayList)
Ordered sequences, history logs, task queues
O(n) — scans from start
Yes
Yes — insertion order
HashMap
Fast lookup by unique key (userId, productId)
O(1) — instant by key
Keys: No / Values: Yes
No — undefined order
HashSet
Membership checks, deduplication
O(1) — instant contains()
No — duplicates silently ignored
No — undefined order
LinkedList
Frequent insertions/deletions at head or middle
O(n) — slow random access
Yes
Yes — insertion order
TreeMap
Sorted key-value pairs, range queries
O(log n) — binary tree
Keys: No / Values: Yes
Yes — sorted by key
Key takeaways
1
Store money as integer cents, always. Display it as dollars only at the last possible moment
never do arithmetic on floats that represent currency.
2
The moment you copy-paste a block of code instead of extracting a function, you've created a bug that will diverge silently from its copies at the worst possible time.
3
Reach for a HashMap over a List the instant you find yourself searching a collection by a specific attribute
O(1) vs O(n) is irrelevant at 10 items and catastrophic at 100,000.
4
A function that does more than one thing isn't a function
it's a liability. If you can't describe what it does in a single sentence without using 'and', split it.
5
Error handling is not optional. Fail fast, fail clearly, fail recoverably. The cost of swallowing an exception is corrupted data that you won't discover until it's too late.
Common mistakes to avoid
5 patterns
×
Using a floating-point double to store monetary values
Symptom
Totals come out as $19.990000000000002 due to IEEE 754 binary representation, causing rounding errors that compound across transactions
Fix
Store all money as integer cents (int priceInCents = 1999) and only convert to decimal for display using String.format("%.2f", cents / 100.0)
×
Writing the same logic in multiple places instead of extracting a function
Symptom
You fix a bug in one copy and three other copies stay broken, producing inconsistent behaviour that's nearly impossible to reproduce
Fix
Extract to a named function the moment you write the same block twice; the rule is called DRY (Don't Repeat Yourself) and it's not optional
×
Using a List and calling contains() or searching with a loop to check if something exists
Symptom
API response times degrade linearly as the list grows, often showing as p99 latency spikes in monitoring but not in unit tests that use small datasets
Fix
Switch to a HashSet for membership checks or a HashMap for keyed lookups; both give O(1) performance regardless of collection size
×
Writing a while-loop whose exit condition can never become false
Symptom
One CPU core pegged at 100%, the thread never returns, eventually causing a timeout or process kill
Fix
Always verify that the loop body contains code that will eventually make the condition false, and add a maximum iteration counter as a safety valve in production loops that process external data
×
Catching an exception and doing nothing (empty catch block)
Symptom
The program continues running with corrupted state, producing wrong results with no error signal until downstream systems fail
Fix
Never catch an exception unless you can handle it (retry, fallback, log context). If you can't handle it, let it propagate. At minimum log the error with input context.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
A HashMap lookup is described as O(1), but what can cause it to degrade ...
Q02SENIOR
You have a user session store that needs to check whether a session toke...
Q03SENIOR
A function you wrote passes all unit tests but produces wrong results in...
Q01 of 03SENIOR
A HashMap lookup is described as O(1), but what can cause it to degrade to O(n) in the worst case, and how do well-designed HashMap implementations defend against this?
ANSWER
The worst case for a HashMap is when all keys end up in the same bucket, turning the lookup into a linear scan of that bucket. This happens when the hash function is poor or when an attacker crafts keys that collide intentionally (hash collision DoS attack). Defenses: Java HashMap uses a tree structure (TREEIFY_THRESHOLD = 8) to convert the linked list into a red-black tree when collisions exceed the threshold, bringing worst-case to O(log n). Also, Java randomizes the hash seed (since Java 7u6) to mitigate collision DoS. The key is to ensure your key type has a good, fast hash function that distributes entries evenly across buckets.
Q02 of 03SENIOR
You have a user session store that needs to check whether a session token is valid on every API request — the store currently has 2 million active tokens. Would you back this with a List, a HashSet, or a HashMap, and exactly why? What changes if you also need to retrieve the user profile associated with the token?
ANSWER
For pure existence checking, use a HashSet of tokens — O(1) contains() and no duplicates. If you need to retrieve the user profile, use a HashMap<String, UserProfile> where the key is the session token — O(1) get(). Never use a List: O(n) lookup on 2 million tokens would take milliseconds per check, killing throughput. The List would also require checking for duplicates on insertion. A HashSet or HashMap uses the token's hashCode() to compute a bucket in constant time. Important: ensure the token type has a well-distributed hash code (e.g., UUID strings have good distribution). If tokens are sequential, wrap them in a class that mixes the bits or use a hash function like murmur3.
Q03 of 03SENIOR
A function you wrote passes all unit tests but produces wrong results in production when called concurrently by multiple threads. The function modifies a variable declared outside its own scope. What is this bug called, what is the exact failure mode, and what are two concrete ways to fix it without introducing a lock?
ANSWER
This is a race condition caused by shared mutable state. The failure mode: Thread A reads the variable, Thread B writes a new value before Thread A writes back, causing lost updates or inconsistent intermediate state. Concrete fixes without locks: 1) Make the function stateless — pass all required data as parameters and return a new value instead of modifying shared state. 2) Use an atomic variable (e.g., AtomicInteger) for simple counters, which uses CAS (compare-and-swap) to ensure atomic updates. If the function must modify a shared collection, use a ConcurrentHashMap or CopyOnWriteArrayList instead of a plain HashMap or ArrayList. The best fix is to eliminate the shared state entirely by redesigning the function to be pure — inputs in, output out, no side effects.
01
A HashMap lookup is described as O(1), but what can cause it to degrade to O(n) in the worst case, and how do well-designed HashMap implementations defend against this?
SENIOR
02
You have a user session store that needs to check whether a session token is valid on every API request — the store currently has 2 million active tokens. Would you back this with a List, a HashSet, or a HashMap, and exactly why? What changes if you also need to retrieve the user profile associated with the token?
SENIOR
03
A function you wrote passes all unit tests but produces wrong results in production when called concurrently by multiple threads. The function modifies a variable declared outside its own scope. What is this bug called, what is the exact failure mode, and what are two concrete ways to fix it without introducing a lock?
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
What's the difference between a variable and a constant in programming?
A variable can change its value after it's set. A constant is fixed the moment it's defined and cannot be reassigned — the compiler will throw an error if you try. Use a constant (final in Java, const in JavaScript, val in Kotlin) any time the value should never change: tax rates, API base URLs, maximum retry counts. This prevents an entire class of bug where someone accidentally overwrites a value that was supposed to be fixed throughout the program's lifetime.
Was this helpful?
02
What's the difference between a for loop and a while loop?
Use a for loop when you know in advance how many iterations you need — iterating over a list, counting from 1 to 100. Use a while loop when you repeat until something changes and you don't know how many iterations that will take — polling for a result, reading input until the user types 'quit'. The rule of thumb: if you're counting, use for. If you're waiting, use while.
Was this helpful?
03
How do I decide what to name my variables and functions?
Name them after what they contain or do, not how they're implemented. calculateOrderTotal is a good function name. doCalc is not. userEmailAddress is a good variable name. str is not. Your names are your documentation — they're read far more often than they're written. If you can't name something clearly, that's usually a sign the thing itself isn't clearly defined yet.
Was this helpful?
04
Why does HashMap order change between runs of the same program?
HashMap doesn't guarantee any insertion order — and in Java, since version 7 update 6, HashMap intentionally randomises its hash seed between JVM runs as a security measure against hash-collision denial-of-service attacks. If you need predictable ordering, use LinkedHashMap to preserve insertion order, or TreeMap to sort by key. If you're seeing non-deterministic ordering and your code depends on a specific order, that's the bug — HashMap is the wrong structure for that requirement.
Was this helpful?
05
Should I ever catch an exception and do nothing with it?
No. Empty catch blocks are one of the most dangerous patterns in production. They hide failures and allow corrupted data to propagate. If you don't know how to handle an exception, don't catch it — let it crash. If you must catch it (e.g., because a checked exception forces you), at minimum log the exception with context so you can investigate later. The only acceptable exception to this rule is very specific scenarios like cleaning up resources in a finally block, but even then you should log any exceptions that occur during cleanup.