DEV Community: Sourabh Gawande

I Replaced Redis Locks with Database Atomicity and You Should Too

Sourabh Gawande — Wed, 03 Sep 2025 18:03:30 +0000

Picture this: You are a dev in a payment services company. The thing with payment transactions is that you are supposed to process each transaction (e.g. send money from John's account to Jane) exactly once. It's 3 AM, your PagerDuty is blowing up with alerts about transactions being processed multiple times by cron jobs, and you're staring at Redis locks that should prevent this exact problem. Sound familiar?

We didn't end up sending money to someone 20 times, but our problem was similar. This is the story of how we went from a complex Redis-based locking nightmare to a beautifully simple database-centric solution, and why you should probably ditch those distributed locks too.

The Great Redis Lock Disaster of 2025

Let me set the scene. We have this automated testing platform where developers would push their OpenAPI specs, and our job workers would generate tests in the background. Think Postman, but the test generation is automated. Simple enough, right? Wrong.

The system worked like this:

Developer pushes an OpenAPI spec with 50 endpoints to our platform
We create 50 "pending" test generation tasks in the database
Multiple job instances fight over who gets to process what
Chaos ensues, developers get duplicate test suites

Our "brilliant" solution was Redis user-level locking:

def main():
    redis = redis_client()

    # Get users with pending tasks
    users_with_pending_tasks = get_users_with_pending_tasks()

    # Try to acquire lock for a user  
    for user in users_with_pending_tasks:
        user_id = user["user_id"]
        lock_acquired = redis.setnx(f"process_lock_{user_id}", user_id)

        if lock_acquired:
            print(f"Acquired lock for user {user_id}")
            process_user_tasks(user_id)
            redis.delete(f"process_lock_{user_id}")  # Release lock
            break

This looked solid on paper. One job per user, clean separation, what could go wrong?

Turns out, a lot. Here's what we discovered after days of debugging.

The Ghost Lock Problem

Jobs would crash (because who writes perfect code?), leaving behind zombie locks in Redis. Developer #12345's tasks would be forever locked, waiting for a job that no longer exists. We'd have to manually clean these up, which is about as fun as debugging CSS alignment issues.

The Race Condition Ballet

Even worse, we had this beautiful race condition where two jobs would:

Both check if a developer has pending tasks ✓
Both try to acquire the same user's lock
One succeeds, one fails, but...
The winner sometimes processed tasks that were already being handled

It was like watching two developers simultaneously fix the same bug in different branches.

The "It Should Work" Syndrome

The most frustrating part? The logic was sound. User-level locking should prevent duplicate processing. But we were still getting duplicate test suites generated, and developers were opening GitHub issues faster than we could close them.

After staring at this code for the hundredth time, my teammate dropped this gem: "Why are we even using Redis for this? Isn't our database already designed to handle concurrency?"

The Database Epiphany

They were right. Here we were, adding this complex external dependency when PostgreSQL has been solving concurrency problems since before Redis was even a twinkle in antirez's eye.

The solution was embarrassingly simple:

def claim_task(task_id):
    result = execute_query(
        "UPDATE tasks SET status = 'processing' WHERE id = %s AND status = 'pending'",
        (task_id,)
    )
    return result.rowcount > 0  # True if we successfully claimed it

That's it. Twelve lines of Redis complexity replaced by three lines of SQL.

Why This Actually Works

When two jobs try to claim the same task simultaneously:

Job A executes the UPDATE first (we're talking microseconds here)
Job B executes the UPDATE immediately after
Job A finds status = 'pending', updates it to 'processing', returns rowcount = 1
Job B finds status = 'processing' (not 'pending'), updates nothing, returns rowcount = 0

The database engine handles all the locking, isolation, and consistency for us. It's literally what ACID properties were designed for.

The New Approach: Beautifully Boring

Here's what our main processing loop became:

def main():
    # Get all pending tasks - dead simple
    pending_tasks = get_tasks_by_status("pending")

    for task in pending_tasks:
        # Try to atomically claim this task
        if claim_task(task["id"]):
            print(f"Got task {task['id']}, let's go!")
            process_task(task)
        else:
            print(f"Task {task['id']} stolen by another worker, moving on...")

def claim_task(task_id):
    result = execute_query(
        "UPDATE tasks SET status = 'processing' WHERE id = %s AND status = 'pending'",
        (task_id,)
    )
    return result.rowcount > 0

No Redis calls. No lock cleanup. No timeouts. No complex error handling. Just pure, boring database operations.

Enter the Resource Hog Problem

But wait, there's more! (There's always more, isn't there?)

Our celebration was short-lived. Within a week, we discovered a new problem: one startup uploaded their monolithic API spec with 1,000 endpoints (yes, we've all been there). Guess what happened? All our job instances started fighting over that user's tasks, completely ignoring everyone else.

Meanwhile, Sarah uploaded her simple microservice spec with 3 endpoints and watched it sit in the queue for hours while MegaCorp's monolith hogged all the workers. Classic tragedy of the commons.

This is where the simplicity of our solution became both a blessing and a curse. It was too fair - treating all tasks equally regardless of user impact.

The Fairness Fix: Not All Users Are Created Equal

We went with the simplest solution first: limit each user to 2 concurrent test generation tasks max.

def main():
    pending_tasks = get_tasks_by_status("pending")

    for task in pending_tasks:
        # Check if this user is already hogging resources
        user_task_count = get_user_task_count(task["user_id"], "processing")

        if user_task_count >= 2:  # Max 2 concurrent tasks per user
            print(f"User {task['user_id']} hit their limit, skipping...")
            continue

        # Try to claim the task
        if claim_task(task["id"]):
            print(f"Processing task for user {task['user_id']}")
            process_task(task)

def get_user_task_count(user_id, status):
    result = execute_query(
        "SELECT COUNT(*) as count FROM tasks WHERE user_id = %s AND status = %s",
        (user_id, status)
    )
    return result["count"]

Simple, effective, and Sarah is happy again.

There Are A Few Other Ways To Solve This

The Single-Query Approach: For the SQL Wizards

If you want to be fancy (and reduce database calls), you can do the fairness check and task claiming in one atomic operation:

def claim_task_with_fairness(task_id, max_concurrent=2):
    result = execute_query("""
        UPDATE tasks t1 
        SET status = 'processing' 
        WHERE t1.id = %s AND t1.status = 'pending'
        AND (
            SELECT COUNT(*) 
            FROM tasks t2 
            WHERE t2.user_id = t1.user_id 
            AND t2.status = 'processing'
        ) < %s
    """, (task_id, max_concurrent))
    return result.rowcount > 0

This is beautiful from a database perspective - one query does it all. But it's harder to debug when things go wrong, and trust me, things will go wrong.

The Round-Robin Approach: Maximum Fairness

For maximum fairness, you can prioritize users who have fewer tasks running:

def get_fair_pending_tasks():
    """Get tasks ordered by user fairness - users with fewer running tasks go first"""
    return execute_query("""
        SELECT t1.* FROM tasks t1
        LEFT JOIN (
            SELECT user_id, COUNT(*) as running_count
            FROM tasks 
            WHERE status = 'processing'
            GROUP BY user_id
        ) t2 ON t1.user_id = t2.user_id
        WHERE t1.status = 'pending'
        ORDER BY COALESCE(t2.running_count, 0) ASC, t1.created_at ASC
    """)

This query is doing some heavy lifting:

Get all pending tasks
Count how many tasks each user has running
Order by fewest running tasks first, then by creation time

It's more complex but gives you true round-robin fairness. MegaCorp's monolith still gets processed, but not at Sarah's microservice's expense.

The Time-Based Approach: "When Did I Last Process This User?"

You could also add a last_processed_at timestamp to users and prioritize those who haven't been processed recently. But honestly, that's probably overkill unless you're running something like GitHub Actions at scale.

The Lessons I Wish I'd Learned Sooner

1. Your Database Is Smarter Than You Think

I spent weeks building a distributed locking system when PostgreSQL was sitting there like "I've literally been doing this since 1996, but okay..."

Databases are designed for concurrency. ACID properties exist for exactly these scenarios. Use them.

2. Complexity Is a Bug, Not a Feature

Every line of Redis locking code was a potential failure point:

Network timeouts
Lock cleanup failures
Race conditions between services
Memory management in Redis

The database solution eliminated all of this. Sometimes the best code is the code you don't write.

3. Fairness Isn't Optional in Multi-Tenant Systems

We learned this the hard way when MegaCorp's monolith starved all the microservice users. If you're building anything where multiple users compete for resources, think about fairness from day one, not when your users start filing angry GitHub issues.

4. Start Simple, Then Optimize

We went with the two-query approach (check user count, then claim task) rather than the fancy single-query version. Why? Because when something breaks at 3 AM, you want to be able to debug it quickly.

Performance Reality Check

Let's be honest about the trade-offs:

Database Approach:

✅ No Redis memory usage
✅ Leverages existing database infrastructure
✅ ACID guarantees
❌ Extra SELECT query for fairness checks
❌ Slightly higher database load

Redis Approach:

✅ Fast in-memory operations
✅ Dedicated locking primitives
❌ Additional infrastructure to maintain
❌ Network calls can fail
❌ Lock cleanup complexity
❌ Memory management

For our use case, the database approach was clearly better. Your mileage may vary.

When To Use Each Approach

Go with database atomicity when:

Your tasks live in the database anyway
You want strong consistency guarantees
You're trying to reduce infrastructure complexity
You trust your database more than your distributed systems skills (smart choice)

Stick with Redis/distributed locks when:

You need locks across multiple databases
Tasks involve complex multi-step operations
You already have Redis infrastructure you're comfortable with
You're building something like a workflow engine with complex state

The Bottom Line

We replaced 50 lines of complex Redis locking logic with 5 lines of SQL and immediately solved our duplicate processing problem. Sometimes the best engineering solution is the boring one.

Your database has been solving concurrency problems longer than most of us have been writing code. Maybe it's time to trust it.

When Docker Almost Died: Exploring Container Alternatives

Sourabh Gawande — Wed, 03 Sep 2025 06:26:07 +0000

During one of my mindless internet browsing sessions, I stumbled upon (Side note: I really miss StumbleUpon for finding random sites - they shut it down in 2018 🪦) an article about Docker almost going under back in 2019. Anyway, reading about how Docker nearly died got me thinking: what would we do if Docker disappeared tomorrow?

The Elegant Solution That Almost Wasn't

Before diving into alternatives, let's appreciate what Docker achieved. It's one of the most elegant pieces of tech built in the last 10 years, solving the notorious "works on my machine" problem by literally shipping the whole machine. It has become an indispensable part of the tech stack for most tech companies.

But there was a time when Docker was in serious financial trouble.

The 2019 Crisis That Almost Killed Docker

In September 2019, leaked memos revealed that Docker CEO Rob Bearden acknowledged "uncertainty [which] brings with it significant challenges" as the company desperately sought funding. While companies like Elastic and MongoDB had managed to build big businesses around their open-source software, Docker was looking to private investors just to keep going.

The situation was dire:

Despite having raised $272.9 million previously, Docker wasn't profitable
The company went through three CEOs in 2019 alone - Steve Singh stepped down in May, was replaced by Rob Bearden, who was then replaced by Scott Johnston in November
Docker was forced to sell its enterprise business to Mirantis for an undisclosed amount
The company managed to secure a $35M investment in November 2019, but only after selling off major parts of its business

There was a real chance of Docker shutting down and possibly not being maintained—which is the case with any software. There's always a possibility of it shutting down for whatever reasons. This made me wonder: if Docker shuts down and is no longer maintained, what are our alternatives?

Alternatives: Your Options If Docker Disappears

Here's a comprehensive breakdown of the main alternatives to Docker:

1. Podman - The Drop-in Replacement

What it is: A daemonless, rootless container engine that's designed to be a direct Docker replacement.

Pros:

Runs each container as a standard user process, making it inherently more secure and lightweight
Drop-in replacement for Docker CLI commands
Typically offers the best cost-efficiency for enterprises, eliminating licensing fees while providing enterprise-grade features
Rootless containers by default
No daemon required

Cons:

Smaller ecosystem compared to Docker
Some Docker Compose features may not work identically
Learning curve for Docker-specific workflows

Migration effort: Minimal - literally just replace docker with podman in your commands. Your existing Dockerfiles work as-is. You might need to adjust some networking configs for rootless mode, but most workflows transfer directly.

Pricing: Free and open source

Maintenance: Actively maintained by Red Hat

Best for: Security-conscious environments, enterprise deployments

Getting started: Podman Official Tutorial

2. containerd - The Kubernetes Native Choice

What it is: A runtime that focuses purely on runtime operations and serves as the container runtime for Kubernetes.

Pros:

Tests show containerd consumes fewer CPU resources compared to Docker
Industry standard for Kubernetes
Lightweight and focused
Cloud native

Cons:

Has fewer high-level features than a full-featured tool like Docker or Podman
Migration complexity is moderate - requires installing and learning a separate client tool like nerdctl
Less user-friendly for development

Migration effort: Medium - you'll need to install containerd and either learn ctr commands or install nerdctl for familiar syntax. Your CI/CD pipelines will need updates since you can't build images directly. Plan for some config file changes and team training.

Pricing: Free and open source

Maintenance: Actively maintained by CNCF

Best for: Kubernetes deployments, cloud-native applications

Getting started: containerd Documentation

3. LXC/LXD - System-Level Containers

What it is: Linux container technology that provides OS-level virtualization.

Pros:

Excels for system containers
Better isolation than application containers
Can run multiple processes and services
Near-native performance

Cons:

May use more memory due to its system-level operations
Different use case from Docker and Podman which target application containers
Steeper learning curve
Less portable than Docker containers

Migration effort: High - this isn't really a migration, it's a complete rethink. You'd redesign your architecture to use system containers instead of app containers. Think moving from microservices back to more traditional server setups, but containerized.

Pricing: Free and open source

Maintenance: Actively maintained by Canonical

Best for: Long-running workloads, system containers

Getting started: LXD Tutorial

4. Buildah - Container Image Builder

What it is: A tool that enables you to add content back to a container image, where the buildah run command imitates the RUN command in a Dockerfile.

Pros:

Excellent for building container images
Works well with Podman
No daemon required
Fine-grained control over image layers

Migration effort: Medium - mainly impacts your CI/CD image building. You'd replace docker build with Buildah scripts and pair it with Podman for running containers. Your development workflow stays mostly the same, but build pipelines need rewriting.

Cons:

Focused primarily on building, not running containers
Requires additional tools for full container lifecycle
Learning curve for Docker users

Pricing: Free and open source

Maintenance: Actively maintained by Red Hat

Best for: Container image building pipelines

Getting started: Buildah Tutorial

5. nerdctl - containerd CLI

What it is: containerd with a Docker-like command-line interface - making containerd user-friendly.

Pros:

Familiar Docker commands
Works directly with containerd
Supports Docker Compose syntax
Additional features like image encryption

Cons:

Still relatively new and less battle-tested
Some Docker features still missing
Requires containerd knowledge for troubleshooting

Migration effort: Low - commands are nearly identical (docker run becomes nerdctl run), and it supports docker-compose.yml files. Main effort is installing containerd + nerdctl and updating your scripts to use the new binary name.

Pricing: Free and open source

Maintenance: Actively maintained

Best for: Teams transitioning from Docker to containerd, local development

Getting started: nerdctl GitHub

Migration Considerations

When considering alternatives, think about:

Team expertise: Docker has the lowest learning curve for beginners
Use case specificity: LXC excels for system containers, while Docker and Podman target application containers
Performance needs: All perform well, but choose based on your specific requirements
Security requirements: Podman's rootless approach may be preferred in security-conscious environments

Docker's Recovery

It's good to know there are some decent alternatives even if Docker goes belly up. Although it seems like Docker has recovered from their troubles and is doing pretty well now. The company reached $207M in annual recurring revenue (ARR) by 2024, up 25% year-over-year from $165M in 2023. They successfully pivoted to a per-seat subscription model for Docker Desktop, which has proven sustainable.

The 2019 crisis was a wake-up call that even essential technologies can face existential threats. While Docker has successfully turned things around, exploring alternatives taught me a few things:

For drop-in replacement: Podman is your best bet
For Kubernetes environments: containerd is the natural choice
For system-level containers: LXC/LXD provides better isolation
For CI/CD pipelines: Buildah excels at image building

Either way, it's always good to have options. The container ecosystem is robust enough that if Docker disappeared tomorrow, we'd have viable alternatives to keep our applications running. Though let's hope it doesn't come to that!

Chrome DevTools: The Complete Use Case Guide for Developers

Sourabh Gawande — Mon, 01 Sep 2025 20:48:22 +0000

A practical, scenario-based breakdown of Chrome DevTools features that every developer should know

Chrome DevTools is arguably the most powerful debugging toolkit available to web developers, yet most of us only scratch the surface. This guide breaks down DevTools by real-world use cases you encounter daily, showing you exactly which tools to use and how to use them effectively.

🚀 Performance & Speed Analysis

"My page loads slowly - where's the bottleneck?"

Use the Performance Tab:

Open DevTools → Performance tab
Click the record button (circle icon)
Reload your page or interact with it
Stop recording and analyze the flame chart

What to look for:

Red triangles: Performance warnings
Long yellow bars: JavaScript execution blocking the main thread
Purple bars: Layout/reflow operations
Green bars: Painting operations

Pro tip: Use the "Screenshots" checkbox to see exactly when visual changes occur.

"My API calls are taking forever - how long exactly?"

Use the Network Tab:

Open DevTools → Network tab
Reload the page or trigger your API calls
Look at the Time column for total request duration
Click on any request to see the detailed timing breakdown:
- Queueing: Time waiting to be processed
- Stalled: Time spent waiting for available connection
- DNS Lookup: Domain resolution time
- Initial Connection: Time to establish connection
- SSL: Time for SSL handshake
- Request Sent: Time to send request data
- Waiting (TTFB): Time to first byte from server
- Content Download: Time to download response

Filtering tricks:

Type XHR to see only API calls
Type fetch to see fetch requests
Use larger-than:1M to find large files

"JavaScript is blocking my UI - what's causing it?"

Use the Performance Tab + Call Tree:

Record a performance profile during the slow interaction
Look for long yellow bars in the flame chart
Click on them to see the Call Tree tab
Sort by Self Time to find the heaviest functions

Coverage Tab for unused code:

Open Coverage tab (in drawer)
Click record and interact with your page
Red bars show unused JavaScript/CSS
Click on files to see exactly which lines aren't executed

📱 Responsive Design & Mobile Testing

"How does my site look on different screen sizes?"

Device Simulation:

Click the Device Toggle (phone/tablet icon) or press Ctrl+Shift+M
Select from preset devices or click Edit to add custom dimensions
Test common breakpoints: 320px (mobile), 768px (tablet), 1024px (desktop)

Custom responsive testing:

Drag the viewport edges to test any size
Click Responsive dropdown to quickly switch between sizes
Use the Zoom dropdown to test different pixel densities

"Is my mobile experience actually usable?"

Touch Simulation:

Enable Device Mode
Click the three dots menu → More tools → Sensors
Set Touch to "Force enabled"
Test your touch interactions

Network throttling for mobile:

In Network tab, click No throttling dropdown
Select Slow 3G or Fast 3G to simulate mobile networks
Test how your app performs on slower connections

"What's causing horizontal scroll on mobile?"

Element inspection trick:

Switch to mobile view
Right-click and Inspect Element
In Console, run:

document.querySelectorAll('*').forEach(el => {
  if (el.scrollWidth > document.body.clientWidth) {
    console.log('Wide element:', el, el.scrollWidth);
  }
});

🐛 JavaScript Debugging

"My code is throwing errors - where exactly?"

Console Tab mastery:

Red errors show exactly where code failed
Click the link on the right to jump to the exact line
Use console.trace() in your code to see the full call stack

Sources Tab debugging:

Go to Sources tab
Find your file in the file tree
Click line numbers to set breakpoints
Reload/trigger the code to pause execution
Use the Scope panel to inspect variable values

"Variables aren't what I expect - how do I inspect them?"

Live expression watching:

In Console, click the eye icon (Create live expression)
Enter variable names or expressions to watch in real-time
They update automatically as you step through code

Breakpoint debugging:

F10: Step over (next line)
F11: Step into (enter functions)
Shift+F11: Step out (exit current function)
Hover over any variable to see its current value

"Event listeners aren't firing - what's attached where?"

Elements Tab event inspection:

Select any element in the Elements tab
In the right panel, scroll to Event Listeners
See all events attached to that element
Click Framework listeners to see through library abstractions
Click the function name to jump to the code

Console event monitoring:

// Monitor all click events
monitorEvents(document, 'click');

// Monitor specific element
monitorEvents($0, 'click'); // $0 is currently selected element

// Stop monitoring
unmonitorEvents(document);

🌐 Network & API Analysis

"Which requests are failing and why?"

Network Tab filtering:

Red entries: Failed requests
Yellow entries: Redirects
Filter by status: Type status-code:404 or status-code:500
Filter by domain: Type domain:api.yoursite.com

Response inspection:

Click on any failed request
Check Headers tab for request/response details
Check Response tab for error messages
Check Preview tab for formatted JSON

"What headers are being sent/received?"

Headers analysis:

Click on any request in Network tab
Headers tab shows:
- Request Headers: What your browser sent
- Response Headers: What the server returned
- Query String Parameters: URL parameters
- Form Data: POST body content

Copy as cURL:

Right-click any request → Copy → Copy as cURL
Test the exact same request in terminal or Postman

"How do I simulate slow network conditions?"

Network throttling:

Network tab → No throttling dropdown
Choose preset (Slow 3G, Fast 3G) or Add custom profiles
Watch how your app handles slow loading

Offline testing:

Select Offline to test your app's offline behavior
Great for testing service worker functionality

🔒 Security & Privacy

"What cookies/storage does my site use?"

Application Tab overview:

Open Application tab
Left sidebar shows all storage:
- Local Storage: Persistent key-value data
- Session Storage: Session-only data
- Cookies: All cookies with expiration dates
- IndexedDB: Structured database storage
- Cache Storage: Service worker caches

Cookie inspection:

Click Cookies → your domain
See all cookies with values, expiration, and security flags
Double-click any value to edit for testing

"Are there any security warnings?"

Security Tab:

Click Security tab
See certificate details and security state
Check for mixed content warnings (HTTP resources on HTTPS page)

Console security warnings:

Red security warnings appear in Console
Common issues: mixed content, unsafe inline scripts, CSP violations

♿ SEO & Accessibility

"What accessibility issues exist?"

Lighthouse audit:

Open Lighthouse tab
Select Accessibility category
Click Generate report
Get specific recommendations with line numbers

Elements Tab accessibility:

Select any element
Accessibility panel (right side) shows:
- ARIA attributes
- Computed accessibility name
- Role and properties

Accessibility tree:

Console → Settings (gear icon) → Experiments
Enable "Full accessibility tree in Elements panel"
See how screen readers interpret your page

"How does my site appear to screen readers?"

Screen reader simulation:

Elements tab → select element
Right panel → Accessibility section
See Name, Role, and Properties
Use Computed Properties to see final accessibility values

💾 Application State & Storage

"What data is stored locally?"

Storage inspection:

Application tab → Storage section
Local Storage: Persistent data that survives browser restarts
Session Storage: Data cleared when tab closes
IndexedDB: Complex structured data storage

Quick storage clearing:

Right-click on any storage type → Clear
Or use Console: localStorage.clear(), sessionStorage.clear()

"How do I modify storage for testing?"

Direct editing:

Application tab → Local/Session Storage
Double-click any key or value to edit
Right-click to add new entries

Console manipulation:

// Set values
localStorage.setItem('key', 'value');
sessionStorage.setItem('user', JSON.stringify({id: 123}));

// Get values
localStorage.getItem('key');
JSON.parse(sessionStorage.getItem('user'));

// Remove specific items
localStorage.removeItem('key');

🎨 CSS & Visual Debugging

"Why doesn't my CSS look right?"

Elements Tab CSS debugging:

Right-click element → Inspect
Styles panel shows all applied CSS
Crossed-out styles: Overridden rules
Orange warning icons: Invalid CSS values
Computed tab: Final calculated values

Box model visualization:

Select element → Styles panel
Hover over the box model diagram
See margin (orange), border (yellow), padding (green), content (blue)

CSS changes testing:

Click any CSS property to edit
Add new properties by clicking in empty space
Changes are temporary - refresh to revert

"How do I find which CSS rule is affecting my element?"

CSS cascade inspection:

Select element in Elements tab
Styles panel shows rules in cascade order (most specific first)
Look for Inherited from sections
Use the filter box to search for specific properties

CSS specificity calculator:

Hover over any CSS selector to see specificity value
Higher numbers win the cascade battle

🔧 Advanced Debugging Techniques

"Memory leaks are suspected - how do I find them?"

Memory Tab analysis:

Memory tab → Heap snapshot
Take snapshot, interact with your app, take another snapshot
Compare snapshots to see memory growth
Look for Detached DOM nodes and Event listeners

Performance memory tracking:

Performance tab
Check Memory checkbox before recording
See memory usage over time in the timeline

"How do I debug Web Workers or Service Workers?"

Application Tab Workers:

Application tab → Service Workers
See registration status and update cycles
Sources tab to debug worker code with breakpoints

Worker console:

Worker console messages appear in main DevTools Console
Use console.log() in worker code to debug

🛠️ Console Power User Tips

"Advanced Console commands I should know?"

Element selection shortcuts:

$0 // Currently selected element
$1 // Previously selected element
$('selector') // Same as document.querySelector()
$$('selector') // Same as document.querySelectorAll()

Network monitoring:

// Monitor all XHR requests
monitorEvents(window, 'load');

// Log all function calls to an object
monitor(functionName);
unmonitor(functionName);

Performance helpers:

// Time any operation
console.time('myOperation');
// ... your code ...
console.timeEnd('myOperation');

// Performance mark for detailed timing
performance.mark('start');
// ... code ...
performance.mark('end');
performance.measure('myMeasure', 'start', 'end');

📊 Real-World Debugging Workflows

Workflow 1: "My React app is slow"

Performance tab → Record during slow interaction
Look for long yellow bars (JavaScript execution)
Click into them to see which React components are slow
Sources tab → Add breakpoints in suspicious components
React DevTools (if installed) → Profiler for component render times

Workflow 2: "API integration isn't working"

Network tab → Find the failing request
Check Status code and Response tabs
Copy as cURL to test outside browser
Console → Check for CORS errors
Security tab → Verify HTTPS issues

Workflow 3: "Mobile site looks broken"

Device toggle → Select target device
Elements tab → Inspect problematic elements
Computed styles → Check actual CSS values
Console → Run viewport debugging:

console.log('Viewport:', window.innerWidth, window.innerHeight);
console.log('Device pixel ratio:', window.devicePixelRatio);

🎯 Pro Tips for Each Tab

Elements Tab

H key: Hide/show selected element
Ctrl+Z: Undo DOM changes
Right-click → Scroll into view: Find elements in viewport
Break on → Subtree modifications: Pause when DOM changes

Console Tab

Ctrl+L: Clear console
Filter levels: Click Error, Warning, Info to filter messages
Preserve log: Keep console messages across page reloads
$_: Reference to last evaluated expression

Network Tab

Ctrl+E: Export HAR file for external analysis
Response Headers → view source: See raw headers
Timing tab: Detailed breakdown of request phases
Disable cache: Checkbox to force fresh requests

Sources Tab

Ctrl+P: Quick file finder
Ctrl+Shift+F: Search across all files
Conditional breakpoints: Right-click line number
Logpoints: Console.log without modifying code

Application Tab

Clear storage: Remove all data for clean testing
Manifest: Check PWA configuration
Service Workers: Debug offline functionality

🔍 Common Debugging Scenarios

Scenario: "Button click isn't working"

// In Console, check if element exists
$('button').length

// Check event listeners
getEventListeners($('button'))

// Test click programmatically
$('button').click()

// Check if element is actually clickable
$('button').disabled

Scenario: "CSS not applying"

Inspect element → Computed tab
Search for your CSS property
If missing: Check Styles for syntax errors (orange warnings)
If overridden: Look at specificity values

Scenario: "Form data not submitting"

Network tab → Submit form
Check if POST request appears
Headers → Request Headers → verify Content-Type
Request tab → verify form data is included

🚨 Quick Debugging Checklist

Page Load Issues:

[ ] Network tab: Any failed requests (red)?
[ ] Console: Any JavaScript errors (red)?
[ ] Performance: Any long-running scripts (yellow bars)?
[ ] Lighthouse: Performance score below 90?

Mobile Issues:

[ ] Device mode: Tested on actual target devices?
[ ] Console: Any viewport meta tag warnings?
[ ] Network: Tested on slow connections?
[ ] Touch: All interactive elements large enough (44px minimum)?

API Issues:

[ ] Network: Request/response headers correct?
[ ] Console: Any CORS errors?
[ ] Security: Mixed content warnings?
[ ] Network: Response time acceptable under throttling?

🎓 Advanced Features You Should Know

Local Overrides

Test changes without deploying:

Sources tab → Overrides
Select folder to save changes
Edit any file and changes persist across reloads

Workspaces

Edit files directly:

Sources → Filesystem
Add your project folder
Edit files directly in DevTools
Changes save to your actual files

Device Mode Advanced

Custom device profiles:

Device mode → Edit button
Add custom devices with specific:
- Screen resolution
- Device pixel ratio
- User agent string
- Touch capabilities

Performance Insights (New!)

Automated performance analysis:

Performance Insights tab (newer Chrome versions)
Automatically identifies performance opportunities
Provides specific recommendations with code examples

🔥 Console Commands Every Developer Should Know

// Clear console
clear()

// Copy any value to clipboard
copy(anyObject)

// Get all images on page
$$('img').map(img => img.src)

// Find elements with specific text
[...document.querySelectorAll('*')].filter(el => 
  el.textContent.includes('search term'))

// Monitor function calls
monitor(functionName)

// Debug function calls
debug(functionName) // Adds automatic breakpoint

// Check performance
console.time('operation')
// ... code ...
console.timeEnd('operation')

// Table format for objects
console.table(arrayOfObjects)

// Group related logs
console.group('API Calls')
console.log('Request 1')
console.log('Request 2')
console.groupEnd()

🎯 Productivity Shortcuts

Essential keyboard shortcuts:

F12: Open/close DevTools
Ctrl+Shift+C: Inspect element mode
Ctrl+Shift+J: Jump to Console
Ctrl+Shift+I: Open DevTools
Ctrl+R: Reload page
Ctrl+Shift+R: Hard reload (ignore cache)
Ctrl+Shift+Delete: Clear browsing data

Panel shortcuts:

Ctrl+[: Previous panel
Ctrl+]: Next panel
Escape: Toggle drawer (Console while in other tabs)

🏆 Pro Tips from the Trenches

Use the Command Menu: Press Ctrl+Shift+P to access any DevTools feature quickly
Screenshot any element: Right-click element → Capture node screenshot
Copy element selectors: Right-click element → Copy → Copy selector
Dock DevTools smartly: Click the three dots → choose docking position based on your task
Multi-line Console editing: Press Shift+Enter for new lines in Console
Preserve console across navigations: Settings → Preserve log
Dark mode: Settings → Preferences → Theme: Dark

🎬 Conclusion

Chrome DevTools is incredibly powerful when you know which tool to reach for in each situation. The key is thinking in terms of problems you need to solve rather than features you want to explore.

Bookmark this guide and refer back to it when you encounter these common debugging scenarios. The more you use these workflows, the faster you'll become at diagnosing and fixing issues.

Next time you're debugging, ask yourself:

What exactly am I trying to figure out?
Which DevTools tab would give me that information?
What specific metric or value am I looking for?

Master these use cases, and you'll debug faster and build better web applications.

Want to level up your debugging skills further? Practice these workflows on your current projects and you'll be amazed at how much faster you can identify and fix issues.

Tracking outbound API calls from your application: why, what worked (and what didn’t)

Sourabh Gawande — Mon, 01 Sep 2025 20:46:56 +0000

We recently had to do an on-prem deployment (i.e. our SaaS is installed and run on the customer's own physical hardware, servers, and data centers, rather than on our cloud) for a customer—a particularly paranoid one (read: fintech 🏦).

Our application is containerized, and we already had scripts and artifacts for different deployment scenarios (Helm charts for Kubernetes, CloudFormation for AWS ECS, etc.). But there was one thing we didn’t have ready:

👉 A list of all outbound API calls our application makes.

This customer had a strict outbound firewall policy, and they needed an exhaustive whitelist of API endpoints.

The Problem

Until this point, we hadn’t really thought about outbound calls. Our own infra had no outbound restrictions, so we happily used libraries, SDKs, and third-party services without tracking what domains they pinged. But for on-prem deployments with locked-down firewalls, this becomes a critical requirement.

Our first instinct was: “How hard can it be?”

Just go through requirements.txt,
Look at the SDKs we use,
Identify direct API calls in our code (e.g., requests),
Then compile the list of domains.

Sounds reasonable, right?

Except… it didn’t work.

Why? Because SDKs don’t always map cleanly to a single domain.

Many SDKs call multiple endpoints.
Some use alternative domains for redundancy.
Others make hidden calls to services you never expected.

Example: One LLM library suddenly made a call to Azure Blob Storage to fetch a file used for token calculation. Not exactly obvious from the docs.

So the manual approach = incomplete.

Exploring Approaches

We turned to ChatGPT (of course) to ask how to track all API calls made by a Python backend. We got a bunch of suggestions that sounded good in theory, but didn’t fully solve the problem in practice.

Here’s a summary:

❌ Approach 1: Monkey Patch `requests`

Idea: Patch the requests module to log every call.
Issue: Not all SDKs use requests. Some use httpx, urllib3, or even custom HTTP clients.
Result: We only saw a subset of calls.

❌ Approach 2: Use `httpretty` or `wrapt`

Idea: Intercept calls by decorating functions dynamically.
Issue: Same limitation—only works if the library is using something we patched. Anything else bypassed this.

❌ Approach 3: Logging Middleware

Idea: Wrap the app with middleware that logs outbound traffic.
Issue: Works if we control the code making requests, but useless for opaque SDKs that bypass middleware.

❌ Other Attempts

Packet capture tools like tcpdump or wireshark: noisy, low-level, and painful to parse.
Debugging proxies tied only to requests: again, incomplete.

None of these gave us the full picture.

The Solution: A Proxy for Everything

The only reliable approach turned out to be:

➡️ Force all outbound calls to go through a proxy, and log everything at the proxy.

We used mitmproxy. It’s lightweight, easy to run, and gives a clean log of every outbound request.

Making Sure All Calls Go Through the Proxy

Specifying a proxy in just the requests client wasn’t enough, because many SDKs bypass it. The trick was to use environment variables that most HTTP clients respect by default:

import os

os.environ["HTTP_PROXY"] = "http://your-proxy:port"
os.environ["HTTPS_PROXY"] = "http://your-proxy:port"

With this, requests, httpx, and many other libraries automatically route traffic through the proxy—without touching our code.

Once we had mitmproxy logging everything, we finally got a complete list of domains our backend was calling. ✅

What About Frontend Calls?

Backend calls are only half the story. The frontend may also directly hit third-party services—for example:

Intercom (support chat)
Posthog / Clarity (analytics)
Sentry (error tracking)

How do we capture these?

Super simple:

Open Chrome DevTools → Network tab.
Start recording.
Walk through all major pages and flows in the app.
Export the HAR file at the end.

That HAR file contains every outbound request the frontend made. We then parse it (with a quick script) to extract unique domains.

⚠️ The tricky part: making sure we triggered all flows. One approach is to leave the recording on while using the app normally for a day, then export the file. That way we’re more likely to catch edge cases.

Takeaways

Don’t assume you know what domains your app calls. SDKs are sneaky.
Manual inspection isn’t enough.
A proxy-based approach (e.g., mitmproxy + environment variables) gives you a complete picture for backend.
For frontend, HAR files from DevTools are the simplest solution.

If you’re doing on-prem deployments with strict firewall rules, it’s worth setting this up early—before the customer is blocked and waiting on you for a whitelist.

Mastering the Model Context Protocol (MCP): A Comprehensive Guide

Sourabh Gawande — Mon, 01 Sep 2025 20:45:17 +0000

Note: This guide presents Model Context Protocol as a proposed standard for LLM-tool integration. While the concepts and architecture described are based on emerging patterns in AI tooling, specific implementations may vary across different platforms.

Large Language Models excel at understanding and generating text, but when it comes to executing real-world tasks—running tests, fetching data, or interacting with your systems—they need a bridge to your tools. The Model Context Protocol (MCP) provides exactly that bridge, offering a standardized way for LLMs to discover, understand, and safely interact with external resources and tools.

This guide explores MCP's architecture, demonstrates practical implementations, and shows how to integrate MCP servers with modern development tools.

Understanding MCP

Model Context Protocol (MCP) is an open standard that enables secure, structured communication between LLMs and external systems. Rather than relying on ad-hoc integrations or hoping the LLM can parse documentation correctly, MCP provides machine-readable definitions of available capabilities.

MCP Architecture

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   MCP Host  │────│ MCP Client  │────│ MCP Server  │
│    (LLM)    │    │ (Protocol)  │    │(Your Tools) │
└─────────────┘    └─────────────┘    └─────────────┘

The protocol defines three core components:

MCP Host: The application containing the LLM (like Claude Desktop)
MCP Client: Maintains connections to MCP servers and translates between the LLM and the protocol
MCP Server: Runs in your environment and exposes capabilities to the LLM

MCP Capabilities

MCP supports three types of capabilities:

Tools: Functions the LLM can call to perform actions
Resources: Data sources the LLM can read from (files, APIs, databases)
Prompts: Pre-defined prompt templates with parameters

How MCP Works

Here's the typical interaction flow:

Discovery: The MCP client connects to your MCP server via configuration and requests available capabilities
Schema Exchange: The server responds with JSON Schema definitions for tools, resources, and prompts
User Request: A user asks the LLM to perform a task
Tool Selection: The LLM analyzes available tools and selects the appropriate one
Execution: The LLM calls the tool via the MCP client with structured parameters
Response: The MCP server executes the logic and returns structured results
Integration: The LLM interprets the results and presents them to the user

This approach ensures tool invocation is predictable, secure, and maintainable.

Common Questions About MCP

Where does the actual tool logic reside?

The implementation lives entirely within your MCP server. The LLM simply makes standardized calls through the protocol—it never directly accesses your infrastructure.

Does the MCP server run on my infrastructure?

Yes. The server operates in your environment, maintaining full control over your data and systems. The LLM communicates only through the standardized MCP protocol.

Why use schemas instead of documentation?

While well-structured documentation can work for human developers, machine-readable schemas provide greater reliability and eliminate ambiguity. The LLM receives precise parameter types, constraints, and expected outputs, reducing errors and hallucinations.

How does this compare to providing examples and letting the LLM adapt?

Example-based approaches can work but are fragile and inconsistent. MCP's schema-driven approach provides deterministic behavior, better error handling, and clearer boundaries for what the LLM can and cannot do.

What about security?

MCP servers run in your controlled environment and you define exactly which capabilities to expose. The protocol supports authentication mechanisms like API keys and OAuth2, with role-based access control for fine-grained permissions.

Implementation Example: Building an MCP Server

Here's a practical example using the Python SDK pattern:

import asyncio
import json
from typing import Optional, Dict, Any, List
from mcp import ClientSession, StdioServerParameters
from mcp.server import NotificationOptions, Server
from mcp.server.models import InitializationOptions
import mcp.server.stdio
import mcp.types as types

# Initialize the MCP server
server = Server("development-tools")

@server.list_tools()
async def handle_list_tools() -> list[types.Tool]:
    """List available tools"""
    return [
        types.Tool(
            name="run_test",
            description="Execute a test case against the system",
            inputSchema={
                "type": "object",
                "properties": {
                    "test_id": {
                        "type": "string",
                        "description": "Unique identifier for the test to run"
                    },
                    "environment": {
                        "type": "string",
                        "enum": ["dev", "staging", "prod"],
                        "description": "Target environment for the test"
                    }
                },
                "required": ["test_id"]
            }
        ),
        types.Tool(
            name="fetch_logs",
            description="Retrieve application logs for analysis",
            inputSchema={
                "type": "object",
                "properties": {
                    "service": {"type": "string"},
                    "start_time": {"type": "string", "format": "date-time"},
                    "level": {
                        "type": "string", 
                        "enum": ["debug", "info", "warn", "error"]
                    }
                },
                "required": ["service"]
            }
        )
    ]

@server.call_tool()
async def handle_call_tool(
    name: str, arguments: Optional[Dict[str, Any]]
) -> list[types.TextContent]:
    """Handle tool execution with proper error handling"""

    # Validate arguments exist
    if arguments is None:
        return [
            types.TextContent(
                type="text",
                text=f"Error: No arguments provided for tool '{name}'"
            )
        ]

    try:
        if name == "run_test":
            # Validate required fields
            if "test_id" not in arguments:
                return [
                    types.TextContent(
                        type="text",
                        text="Error: Missing required field 'test_id'"
                    )
                ]

            test_id = arguments["test_id"]
            environment = arguments.get("environment", "dev")

            # Execute test logic
            result = await execute_test(test_id, environment)

            if result["status"] == "failed":
                return [
                    types.TextContent(
                        type="text",
                        text=f"Test {test_id} failed in {environment}: {result['error']}"
                    )
                ]

            return [
                types.TextContent(
                    type="text",
                    text=f"Test {test_id} completed in {environment} environment.\n"
                         f"Status: {result['status']}\n"
                         f"Duration: {result['duration']}ms\n"
                         f"Details: {result['message']}"
                )
            ]

        elif name == "fetch_logs":
            # Validate required fields
            if "service" not in arguments:
                return [
                    types.TextContent(
                        type="text",
                        text="Error: Missing required field 'service'"
                    )
                ]

            service = arguments["service"]
            start_time = arguments.get("start_time")
            level = arguments.get("level", "info")

            # Fetch logs logic
            logs = await fetch_service_logs(service, start_time, level)

            return [
                types.TextContent(
                    type="text",
                    text=f"Retrieved {len(logs)} log entries for {service}\n" + 
                         "\n".join(logs[:10])  # Show first 10 entries
                )
            ]

        else:
            return [
                types.TextContent(
                    type="text",
                    text=f"Error: Unknown tool '{name}'"
                )
            ]

    except Exception as e:
        return [
            types.TextContent(
                type="text",
                text=f"Error executing {name}: {str(e)}"
            )
        ]

# Implementation functions (replace with your actual logic)
async def execute_test(test_id: str, environment: str) -> Dict[str, Any]:
    """
    Placeholder test execution function.
    Replace with your actual test runner integration.
    """
    # Mock implementation - replace with real test execution
    import random
    success = random.choice([True, False])

    if success:
        return {
            "status": "passed",
            "duration": 1250,
            "message": "All assertions successful"
        }
    else:
        return {
            "status": "failed",
            "duration": 850,
            "error": "Assertion failed on line 42"
        }

async def fetch_service_logs(service: str, start_time: Optional[str], level: str) -> List[str]:
    """
    Placeholder log fetching function.
    Replace with your actual logging system integration.
    """
    # Mock implementation - replace with real log fetching
    return [
        f"[{level.upper()}] {service}: Sample log entry 1",
        f"[{level.upper()}] {service}: Sample log entry 2",
        f"[{level.upper()}] {service}: Sample log entry 3"
    ]

async def main():
    """Run the MCP server using stdio transport"""
    async with mcp.server.stdio.stdio_server() as (read_stream, write_stream):
        await server.run(
            read_stream,
            write_stream,
            InitializationOptions(
                server_name="development-tools",
                server_version="1.0.0",
                capabilities=server.get_capabilities(
                    notification_options=NotificationOptions(),
                    experimental_capabilities={},
                ),
            ),
        )

if __name__ == "__main__":
    asyncio.run(main())

Step-By-Step Implementation Guide

1. Choose Your Technology Stack

Python: Use the MCP Python SDK for robust server development with async/await support.

Node.js: The MCP TypeScript SDK provides comprehensive type safety and modern JavaScript features.

C#: Microsoft's official SDK enables .NET integration with MCP protocols.

2. Design Your Capabilities

Define what your MCP server will expose:

Tools for actions (running tests, deploying code, sending emails)
Resources for data access (configuration files, database queries, API endpoints)
Prompts for reusable templates (code review prompts, documentation generators)

3. Implement Server Logic with Validation

Each capability requires:

A clear name and description
JSON Schema definitions for inputs and outputs
The actual implementation logic
Comprehensive error handling and input validation
Appropriate security controls

4. Configure Transport Mechanisms

MCP supports multiple transport options:

stdio: For local development and direct integration
HTTP: For remote servers and web-based tools
WebSocket: For real-time, bidirectional communication

5. Register with MCP Clients

Configure your MCP server in client tools using their specific configuration format. For example, in Claude Desktop's configuration file:

{
  "mcpServers": {
    "development-tools": {
      "command": "python",
      "args": ["path/to/your/mcp_server.py"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

6. Test and Validate

Before deployment:

Verify schema validation works correctly
Test error handling for edge cases
Ensure security boundaries are properly enforced
Validate performance under expected load

Current MCP Ecosystem

MCP adoption has grown across development tools, with several platforms providing native integration:

Tool	MCP Support	Configuration Method
Claude Desktop	Full integration	JSON config file
Cursor AI	Development workflows	Extension settings
VS Code Extensions	Various implementations	Extension-specific
Custom Implementations	DIY integration	Manual setup

Server Discovery: MCP clients typically discover servers through configuration files that specify connection details, authentication, and transport methods. Some enterprise implementations use centralized registries for automatic server discovery across teams.

MCP Server Marketplace and Discovery

The MCP ecosystem includes several discovery mechanisms:

Official Directories:

Community-maintained registries of open-source MCP servers
GitHub repositories tagged with mcp-server for easy discovery
Package registries (PyPI, npm) with MCP-specific categories

Enterprise Solutions:
Organizations build internal MCP server registries for sharing tools across teams while maintaining security and compliance requirements. These often integrate with existing service discovery infrastructure.

Community Contributions:
The open-source community develops MCP servers for popular tools like Git, Docker, Kubernetes, AWS, and database systems, making them available through standard package managers.

MCP Vs. Alternative Approaches

Traditional Documentation Approach:

Server provides: API documentation + examples
LLM parses: Unstructured text and examples
Result: Variable reliability depending on documentation quality

MCP Protocol Approach:

Server provides: Machine-readable schemas + implementations
LLM receives: Structured definitions with clear contracts
Result: Reliable, predictable tool usage

While modern LLMs can effectively parse well-structured documentation, MCP's schemas provide greater reliability and consistency, especially for complex tool chains and enterprise environments where predictability is crucial.

Best Practices and Considerations

Security: Always run MCP servers in controlled environments with appropriate access controls. Use API keys or OAuth2 for authentication and implement role-based access control for fine-grained permissions.

Performance: Design tools to be responsive and provide progress feedback for long-running operations. Consider implementing timeouts and cancellation support.

Error Handling: Provide clear, actionable error messages that help the LLM understand what went wrong and how to correct it. Always validate required inputs and handle edge cases gracefully.

Documentation: While MCP reduces the need for extensive documentation, clear descriptions in your schemas help LLMs make better tool selection decisions.

Production Considerations: For production systems, implement proper logging, monitoring, and circuit breakers. Consider using a registry-based approach for tool discovery rather than hardcoded tool names.

Getting Started Today

The concepts underlying MCP reflect emerging patterns in AI-tool integration. Here's how to begin exploring these approaches:

Choose an SDK that aligns with your preferred language and existing infrastructure
Start with a simple tool that solves a specific problem in your workflow
Test with compatible platforms to validate your implementation
Implement proper error handling and security controls from the beginning
Iterate and expand based on what works well for your use cases
Document and share your learnings with your team or the community

MCP-style protocols represent a significant step toward more reliable AI-tool integration. By providing standardized interfaces, they enable LLMs to work more effectively with existing systems while maintaining security and predictability.

Whether you're building internal development tools or creating solutions for the broader community, structured protocols like MCP offer a robust foundation for AI-powered automation that scales with your needs. The key is starting with clear schemas, robust error handling, and a security-first mindset.

What does the future of coding interviews look like in the age of LLMs?

Sourabh Gawande — Mon, 01 Sep 2025 20:42:44 +0000

Since I started working in the software industry over 11 years ago, there's been one constant in technical hiring: the coding interview. Every company might tweak their process—some add system design rounds, others throw in culture fit sessions—but the coding interview has been universal.

That's changing fast.

Now that you can generate nearly correct code in seconds using an LLM, the traditional coding interview has become both obsolete and trivial. This is especially obvious in remote settings where candidates can—and let's be honest, do—just ChatGPT their way through problems.

But the problem runs deeper than just cheating.

The fundamental flaw that LLMs exposed

Coding interviews were always broken. We just didn't want to admit it.

They weren't testing problem-solving skills. They were testing how well someone had memorized LeetCode problems. After all, interviewers weren't creating original algorithmic challenges—they were pulling from the same pool of problems everyone else uses.

At best, these interviews showed whether someone could convert thoughts into executable logic. But here's the thing: with LLMs handling that exact same task, what skill are we actually measuring?

The bigger issue is that coding interviews were never good predictors of job performance. Real software engineering requires skills that a 45-minute algorithm session doesn't touch:

Understanding complex existing codebases
Learning new technologies quickly
Actually finishing projects (not just starting them or fucking around halfway through)
Making architectural decisions that won't bite you later
Working effectively with other humans

Why LLMs killed coding interviews completely

LLMs have exposed two fatal flaws in traditional coding interviews:

Remote interviews are pointless. There's no reliable way to prevent AI usage, and frankly, why would you want to? You can be almost 100% sure candidates are just going to ChatGPT it anyway—can't really blame them.

In-person interviews test the wrong skills. Even if you force candidates into a conference room, you're asking them to manually code solutions they'd use AI for on the actual job.

You could insist on whiteboarding, but then you're testing penmanship and memorization in an era where the job requires AI collaboration.

The obvious solution nobody wants to admit

Instead of viewing LLMs as the death of technical assessment, they're actually the best thing that happened to hiring.

Here's why: a software engineer's job is to engineer software. We only settled for coding interviews because you couldn't build real projects in interview timeframes. Coding interviews were a proxy for the actual work—building complete systems.

With LLMs, that constraint is gone. You can now build a working project in hours.

So why use a proxy when you can test the real thing?

My proposal: Scrap coding interviews entirely. Give candidates a full project to complete, with the explicit expectation that they'll use AI tools.

What this actually looks like

I'm not talking about take-home assignments that sit in someone's backlog for weeks. I'm talking about time-boxed project builds that mirror real work.

And when I say "full project," I don't mean building the next Google Maps. I mean something focused but complete—like a simple blogging platform that takes markdown files and hosts them with switchable themes. Or better yet, let the candidate choose.

There's a common product interview question: "What's your favorite product and how would you improve it?" You could adapt this for engineering: "Pick your favorite product and build a barebones version—a proof of concept."

This approach is especially valuable for startups. Most early-stage work is rapid POC development. You need people who can build fast without overthinking and overengineering. This format reveals whether a candidate can make progress in ambiguous situations or if they'll get stuck internally debating which fucking datatype to use for a database column.

Here's what changes:

You see real engineering skills. How do they set up their development environment? How do they structure code for maintainability? How do they handle dependencies, build systems, maybe even basic deployment? These are the messy realities of actual software work that coding interviews completely ignore.

You evaluate AI collaboration. Like it or not, we're not going back. Even if AI only improves productivity by 50%, that's a massive competitive advantage. You want to hire people who are exceptionally good at human-AI collaboration, not people who can solve tree traversal problems from memory.

You get system design for free. A complete project forces architectural decisions. Which database? Why? How do you structure the code for extensibility? How do you handle error cases? These decisions reveal thinking that's impossible to assess in isolated coding problems.

Why this wasn't practical before (and why it is now)

The old constraints were real:

Time: Non-trivial projects needed weeks, not hours
Candidate dropout: Working professionals couldn't spend weekends building speculative projects
Interview throughput: You could do multiple coding interviews per day, but not multiple project builds

LLMs changed the math. What used to take a week now takes hours.

Plus, the time investment isn't actually worse than the current system. Most companies already put candidates through 4-5 coding rounds, and since remote interviews aren't practical anymore (thanks to AI cheating), these end up being in-person.

Do the math: 5 hours of interviews plus 1-2 hours of travel time each way. If you're in Bangalore, make that 3+ hours in traffic. You're already looking at a full day commitment for the traditional process.

A single project-based assessment that takes 4-6 hours? That's actually more efficient than the current marathon of multiple coding rounds.

What I'm seeing in practice

Some companies are already moving this direction, though most won't admit it publicly. The ones I've talked to report better hiring outcomes—fewer mismatches, better performance correlation, and candidates who actually understand what they're signing up for.

The resistance isn't technical; it's cultural. We've been doing coding interviews for so long that they feel "rigorous" even when they're not predictive.

The companies that adapt first win

Traditional coding interviews are ending whether we acknowledge it or not. Candidates are already using AI in remote interviews. The choice isn't whether to allow AI—it's whether to design assessments that account for it.

Companies that switch to project-based assessments will attract better candidates and make more accurate hiring decisions. Those clinging to LeetCode-style problems will find themselves testing memorization skills while missing the qualities that actually predict engineering success.

The future of technical interviews isn't about fighting AI. It's about embracing it to create better, more realistic assessments of what engineering actually involves.

This isn't just a trend—it's the new reality. The question is whether your hiring process will adapt or become irrelevant.

How CAPTCHAs work - The Internet's Annoying but Essential Gatekeepers

Sourabh Gawande — Wed, 19 Jun 2024 20:23:18 +0000

If you live on the internet (which is practically everyone these days), you likely come across a CAPTCHA often - those somewhat irritating puzzles asking you to pick traffic lights to prove you’re not a robot. Have you ever wondered how these things work and why they’re needed? Let’s take a deep dive into it. (P.S. There's a bonus section containing bad CAPTCHA examples at the end).

What's a CAPTCHA

CAPTCHA (which stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”) is a tool used by sites to identify whether an internet user is a human or a bot.

Around 1997, AltaVista (a primitive search engine of that decade) was having a tough time fixing the high number of auto URL assets that were hampering its website ranking process severely. To solve this issue, the then-chief scientist of AltaVista, Andrei Broder, created an algorithm that later became famous as CAPTCHA.

Because the test is administered by a computer, in contrast to the standard Turing test that is administered by a human, CAPTCHAs are sometimes described as reverse Turing tests.

Why is CAPTCHA needed?

Tl;dr - To make sure some sensitive resource is not exploited using bots

CAPTCHAs are used by any website that wishes to restrict usage by bots. For instance, if you’re running a hotel reservation site, there’s a chance that someone might try to take all the bookings using a bot and legit customers will not be left with any slots. Or you might be running an online poll and want to make sure that votes are not manipulated using bots. CAPTCHA comes in handy in these scenarios making sure only human users can perform some actions blocking access to bot users.

How it works

There are different types of CAPTCHAs available in the market these days, each a little different in its workings than the last one. But all of them work on the same principle - ask users to perform some actions that are trivial for a human to do but almost impossible to automate.

Here are some common CAPTCHA flavours and how they work -

Classic CAPTCHA (Text-based CAPTCHA)

These are the oldest variants of CAPTCHAs, as the name suggests. Classic CAPTCHAs work by asking a user to identify words. These words are shown in a distorted blurry manner with different fonts and handwriting which makes it very difficult for bots to identify them using OCR but it’s still trivial for human users to decipher.

ReCAPTCHA

Google came up with a new way to identify human users which doesn’t require users to enter anything. It just asks you to click on a checkbox.

How can you figure out if a user is a human or a bot by just looking at a checkbox click, you may wonder. The answer is not in the click but in what happens before you click the checkbox. Google has a risk analysis engine that looks at things like how the cursor moved on its way to the checkbox (organic random path/acceleration vs cursor moving in a straight line), which part of the checkbox was clicked (random places, or dead on center every time), browser fingerprint, Google cookies & contents, click location history tied to your fingerprint or account if it detects one, etc. to differentiate between organic and automated clicks.

Image-recognition CAPTCHA

For an image-recognition CAPTCHA, users are presented with square images of common objects like bikes, buses, traffic lights, etc. The images may all be from the same large image, or they may each be different. A user has to identify the images that contain certain objects. If their response matches the responses from most other users who have submitted the same test, the answer is considered "correct" and the user passes the test.

Bonus: 5 examples of terrible CAPTCHAs that will make you pull out your hair

             _You need a physics degree to solve CAPTCHAs now?_

                         _Good luck deciphering this_

                    _If "you shall not pass" was an image_

                                 _Speechless_

                      _Maybe the robots should take over_

Simplify LLM Cost Tracking with Tokencost

Sourabh Gawande — Wed, 19 Jun 2024 20:12:39 +0000

As the popularity of Large Language Models (LLMs) grows, so does the need to accurately track and estimate the costs associated with using these powerful APIs. This is where Tokencost comes in - a Python library that simplifies the process of calculating the USD cost of prompts and completions for major LLM providers.

today, and start shipping bug-free code faster!

Key Features

LLM Price Tracking: Tokencost stays up-to-date with the latest pricing changes from major LLM providers, ensuring you always have accurate cost estimates.
Token Counting: Accurately count the number of tokens in your prompts before sending requests to OpenAI, helping you optimize your usage and costs.
Easy Integration: With just a single function call, you can get the cost of a prompt or completion, making it simple to incorporate Tokencost into your existing projects.

Installation

Install Tokencost via PyPI:

pip install tokencost

Cost Estimation

Tokencost makes it easy to calculate the cost of prompts and completions from OpenAI requests. Here's an example:

from openai import OpenAI
from tokencost import calculate_prompt_cost, calculate_completion_cost

client = OpenAI()
model = "gpt-3.5-turbo"
prompt = [{ "role": "user", "content": "Say this is a test"}]

chat_completion = client.chat.completions.create(
    messages=prompt, model=model
)

completion = chat_completion.choices[0].message.content
prompt_cost = calculate_prompt_cost(prompt, model)
completion_cost = calculate_completion_cost(completion, model)
print(f"{prompt_cost} + {completion_cost} = {prompt_cost + completion_cost}")

You can also calculate costs using string prompts instead of messages:

from tokencost import calculate_prompt_cost

prompt_string = "Hello world"
response = "How may I assist you today?"
model= "gpt-3.5-turbo"

prompt_cost = calculate_prompt_cost(prompt_string, model)
print(f"Cost: ${prompt_cost}")

Token Counting

In addition to cost estimation, Tokencost provides functions for counting tokens in both message lists and string prompts:

from tokencost import count_message_tokens, count_string_tokens

message_prompt = [{ "role": "user", "content": "Hello world"}]
print(count_message_tokens(message_prompt, model="gpt-3.5-turbo"))

print(count_string_tokens(prompt="Hello world", model="gpt-3.5-turbo"))

This allows you to optimize your prompts and stay within the token limits of your chosen LLM.

Conclusion

As LLMs continue to advance and find new applications, managing the costs associated with these powerful APIs becomes increasingly important. Tokencost simplifies this process, providing accurate cost estimates and token counting for major LLM providers.

By integrating Tokencost into your projects, you can ensure that you're using LLMs efficiently and cost-effectively, helping you build better AI-powered applications without breaking the bank.

Generate assertions using AI

Sourabh Gawande — Wed, 19 Jun 2024 19:58:45 +0000

Assertions are like the rear-view mirrors of your testing process. They check whether specific conditions within the code are running as expected.

Assertions testing is based on the use of assertion functions that we have productized for you. In a single click: you can check for accuracy, reliability, and performance!

After you check the response to your request, directly generate assertions using AI! The best part? Absolutely no prompting is required from your end.

If the assertions match, the test passes. You can be rest assured your code is ready for prod.

If the assertions do not match, and the test fails, you get insight into the exact point and reason for failure. From here on, you can fix the code promptly.

Test more efficiently with GenAI

Sourabh Gawande — Wed, 19 Jun 2024 19:56:17 +0000

Run GenAI written tests for your entire codebase while you’re on a coffee break!

The era of shift left-testing arrived but our products did not change… At KushoAI, we’re bringing you a testing tool that will match pace with the dynamic shipping cycles of your team.

You have to catch issues before they reach production and impact users but since testing is so time-consuming it’s often a bottleneck.

Manual testing helps you debug specific problems but it’s painstakingly slow. AI-driven testing ensures you get consistent in-depth coverage and reduces human error.

The best part? It’s lightning fast. Kusho looks at every scenario, writes your tests, and executes them instantly.

In fact, KushoAI can auto-run relevant test suites at any stage of your CI/CD pipeline. A release that affects millions of customers? We’ve got you.

You can run tests for a single API, group some APIs together, or run tens of APIs with a single click! Writing and executing tests usually take hours. Now you can do it in a matter of minutes.

For every test, you get a request, response, assertions, and assertions results tab. You can generate assertions with GenAI and say goodbye to your testing woes forever.

With assertion testing, detecting small and subtle errors that lead to notorious bugs is possible. When an assertion returns as false, it’s a warning system like in cars when the petrol must be re-fuelled, and your test fails.

Now you know exactly where to intervene to ship pristine code in a
matter of minutes.

Add API inputs in many easy ways

Sourabh Gawande — Wed, 19 Jun 2024 19:52:40 +0000

As developers, you deserve robust tools. We understand the laundry list of items you must get to and let’s not even get into the time spent in meetings.

At Kusho, we’ve built a GenAI test automation product that adapts to the needs of your job, and can save you a couple of hours daily.

Kusho solves your testing bottleneck by simulating test scenarios, running tests, validating them, and helping you discover bugs. The best part is that you can enter API details from your existing workflow.

Choose whatever way suits you best:

Just enter API Details: you can manually enter your API details and provide basic details like HTTP method, the endpoint URL, headers, path params , query params etc. and let Kusho do the rest!
Import OpenAPI specs: if you prefer breezy documentation and swear by OpenAPI specs, you can also easily import your collection.
Import your existing Postman Collections: since you already spend so much time maintaining your Postman Collections, we ensure you can directly import them, and Kusho can generate on top of it.
Copy/paste your cURL command: If you don’t want to switch out of your environment, you can create test suites by entering a cURL command.

In the middle of a crazy workday and wish there was someone to help you test quickly and reliably? Test with Kusho and let us know if you have any feedback!

On HumaneAI: should completely new tech products be judged by their promise or on their delivery?

Sourabh Gawande — Wed, 19 Jun 2024 19:46:43 +0000

I’m sure you’re following today’s main character on tech Twitter: HumaneAI.
The TLDR is that there’s a new AI voice assistant device on the market. It’s multi-modal, wearable, and built with some pretty cool engineering. Think of it like computing on the go.

It acts as a live voice search, shadows you on calls, can capture basic photos and video, etc. Plus, it can display a screen on your hand, in case you don’t want to talk out loud.

The kicker: it costs $700 plus an additional subscription free.

Many journalists, YouTubers, and tech enthusiasts have released their honest reviews of HumaneAI. The reviews are brutal and rely on comparing this new AI pin to our smartphones — that we all wished we used less of but only truly put away when we’re asleep.

We can’t forget we have smartphones because we use them all the time. In fact, do you even remember all the big and small things you do on your phone daily? Furthermore, the computing power and affordability of smartphones make them the poster child of the global and digital economy.

For any AI native hardware device to play in the same league, it needs access to rich data, it needs to be fast, and it needs to synthesize information in a way that feels like a step forward.

And it somehow needs to do all of this on a different interface, OS, and on a device other than the one we carry around all the time.

It’s an admittedly hard problem to solve.

You can’t limit the power of your software by trying to build it on top of older hardware, but at the same time, your newer hardware can’t be a container only for your AI native software.

HumaneAI is attempting to build in uncharted territory. It’s a novel attempt. However, there is a clear gap between the current product and its ideal/ future self — the execution lags far behind the idea.

As tech enthusiasts, should we support HumaneAI for bringing a new idea to the public, or should we be pragmatic consumers? Is it our responsibility to offer an honest critique or are we killing an audacious idea before it has found its footing?

What do you all think?