The interviewer isn’t just checking if you are a “good manager.” They are checking if you can be trusted with a critical slice of the business, manage other managers, and make expensive decisions autonomously.

The “I” vs. “We” Balance

• The Trap: Candidates often say “We decided” or “The team built.”
• The L6 Fix: You must distinguish between your team’s output and your specific leverage.
• Instead of: “We decided to use DynamoDB.”
• Say: “The team initially proposed Postgres. I challenged that decision because of our write-throughput projections. I asked the Principal Engineer to benchmark DynamoDB, which proved 40% cheaper at scale. I then signed off on the migration.”

Mechanisms Over Good Intentions

At L6, you cannot rely on “heroics” or “checking in.” You build systems (Mechanisms) that ensure success even when you aren’t in the room.

• L5 Answer: “I talked to the team to make sure they were testing their code.”
• L6 Answer: “I noticed quality was slipping. I implemented a mechanism: a mandatory ‘Operational Readiness Review’ (ORR) gate before any Phase-2 rollout. This automated the checklist and reduced Sev-2 incidents by 30% in Q4.”

Story Selection: Complexity & Ambiguity

Don’t pick stories where the problem was clear and you just had to code it. Pick stories where:

• The Business Problem was unclear: “Sales wanted feature X, Product wanted Y, and Engineering said both were impossible. Here is how I navigated that…”
• The Stakes were high: “The platform was going down during Prime Day…”
• The conflict was lateral or upward: Disagreeing with a Director, another Senior SDM, or Product Leadership.

The “Manager of Managers” (MoM) Lens

Even if you haven’t managed managers yet, you need to show you think like one.

• Hiring: Don’t just talk about hiring smart people. Talk about fixing the hiring process (e.g., “I noticed we were biased against non-CS degrees, so I revamped the loop…”).
• Performance: Don’t just talk about PIPs. Talk about coaching high performers to get promoted, or coaching a new manager on how to handle their team.

Demonstrate “Technical Judgment”

You are not coding daily, but you are the “Chief Risk Officer” for your software.

Show that you know when to dive deep.

• Example: “My team told me the migration was on track. However, looking at the burndown chart and the latency metrics in the staging environment, my gut instinct (bias for action) told me something was wrong. I audited the logs myself and found…”

The “So What?” (Results & Learnings)

Every story must end with:

Hard Metrics: Dollar impact, latency reduction, headcount saved, adoption % (Avoid “the customer was happy”).

Strategic Learning: This is crucial for L6.

• Good: “We launched on time.”
• Better: “We launched on time, but I learned that our reliance on manual QA is a bottleneck. As a result, for the next roadmap, I allocated 20% of headcount specifically to automation infrastructure to prevent this crunch mode from happening again.”

You can also connect me if you need mentoring/guidance/Mock Interview!

Ensuring thread safety during code reviews is critical for applications that involve concurrent or parallel execution. Here’s a structured approach to systematically identify and address thread safety issues:

1. Look for Shared Resources (Shared Mutable State)
2. Identify Unsafe Collections
3. Check for Proper Synchronization
4. Look for Race Conditions
5. Identify Deadlocks
6. Verify usage of Volatile variables
7. Examine Thread Safety of Libraries
8. Look for Proper Lock Granularity
9. Watch for Improper Exception Handling

Lets cover first 3 points in more detail:

Look for Shared Resources,unsafe collections and synchronization

Any resource (e.g., variables, collections, or objects) that is accessed and modified by multiple threads is a potential risk.

Example

private int counter = 0;

public void increment() {
    counter++; // Non-thread-safe
}

What are different ways to add thread safety here?

1. Use Synchromized Block

private int counter =0;

public synchronized void increment(){
  counter++;
}

• The synchronized keyword ensures that only one thread can execute the increment method at any given time.

Trade-Off:

• This approach is simple but can lead to contention, as threads are blocked while waiting for access to the synchronize

2. Use Atomic Variable

Java provides AtomicInteger, a thread-safe class for managing integer values without explicit synchronization.

import java.util.concurrent.atomic.AtomicInteger;

private AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();
}

• The incrementAndGet method atomically increments the counter and returns the new value.
• Internally, it uses low-level atomic operations (e.g., CAS — Compare-And-Swap inmemory operation).

Trade-Off:

• More efficient than synchronization for simple atomic operations.
• Limited to specific operations (e.g., increment, decrement).

3. Use Locks (Reentrant Lock)

Explicitly use locks to protect critical section

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

private int counter = 0;
private final Lock lock = new ReentrantLock();

public void increment() {
    lock.lock();
    try {
        counter++;
    } finally {
        lock.unlock();
    }
}

• The ReentrantLock ensures mutual exclusion. Only one thread can hold the lock at a time, allowing it to safely modify counter.

Trade-Off:

• Provides more flexibility than synchronized (e.g., try-locks, timed locks).
• Slightly more verbose and complex to manage.

4. Use ThreadLocal

Add Threadlocal if each thread can have its own counter

private ThreadLocal<Integer> counter = ThreadLocal.withInitial(() -> 0);

public void increment() {
    counter.set(counter.get() + 1);
}

public int getCounter() {
    return counter.get();
}

• Each thread gets its own isolated counter, eliminating contention entirely.

Trade-Off:

• Not suitable for a shared global counter.
• Use this only when thread-specific counters are acceptable.

5. Use Long Adder

For scenarios with high contention LongAdder is better which is designed for concurrent envs and frequent updates.

import java.util.concurrent.atomic.LongAdder;

private LongAdder counter = new LongAdder();

public void increment() {
    counter.increment();
}

public int getCounter() {
    return counter.intValue();
}

• LongAdder maintains a set of counters internally, which are updated independently by threads and aggregated when needed.
• Reduces contention compared to AtomicInteger in high-concurrency scenarios.

Trade-Off:

• Slightly more memory overhead due to internal counter array.
• Best for counters that are updated frequently but read less often.

What if we are using collections like Lists, map and Sets. How do we make them thread safe ?

• Lists: CopyOnWriteArrayList
• Maps: ConcurrentHashMap
• Sets: ConcurrentSkipListSet

Even with thread safe collections, compound actions (check-and-act) can be unsafe.

Best Practices

Use the Right Data Structure:

• Match the collection type (e.g., CopyOnWriteArrayList, ConcurrentHashMap) to the workload.

Understand Access Patterns:

• Optimize for read-heavy or write-heavy scenarios.

Avoid Explicit Synchronization:

• Use concurrent alternatives instead of wrapping with Collections.synchronizedXXX.

Test Concurrent Code:

• Use tools like JUnit or concurrency testing libraries to validate thread safety.

We will add rest points of race conditions, deadlocks etc in next part

Follow to saty tuned for more articles like this!

Lets review the code of a cache system. The cache is supposed to store key-value pairs and automatically remove entries after a certain expiration time. Additionally, it must handle concurrent access in high traffic/ requests env.

import java.util.HashMap;
import java.util.Map;

public class ExpiringCache<K, V> {
    private final Map<K, V> valueMap = new HashMap<>();
    private final Map<K, Long> timestampMap = new HashMap<>();
    private final long expirationTimeMillis;

    public ExpiringCache(long expirationTimeMillis) {
        this.expirationTimeMillis = expirationTimeMillis;
    }

    public void put(K key, V value) {
        long timestamp = System.currentTimeMillis();
        valueMap.put(key, value);
        timestampMap.put(key, timestamp);
    }

    public V get(K key) {
        if (!valueMap.containsKey(key)) {
            return null;
        }
        long timestamp = timestampMap.getOrDefault(key, 0L);
        if (System.currentTimeMillis() - timestamp > expirationTimeMillis) {
            valueMap.remove(key);       // Remove from value map
            timestampMap.remove(key);  // Remove from timestamp map
            return null;
        }
        return valueMap.get(key); // Return the cached value
    }

    public void remove(K key) {
        valueMap.remove(key);
        timestampMap.remove(key);
    }

    public static void main(String[] args) throws InterruptedException {
        ExpiringCache<String, String> cache = new ExpiringCache<>(5000); // 5 seconds expiration
        cache.put("key1", "value1");

        System.out.println("Initial value: " + cache.get("key1"));

        Thread.sleep(6000); // Wait for expiration
        System.out.println("After expiration: " + cache.get("key1"));
    }
}

Spend sometime to figure out the review comments, before you scroll down..!

Above code is functionally correct. However, it can be improved based on below aspects:

Thread Safety

if multiple threads try to get and put the items in cache, it can lead to race conditions and may lead data inconsistency. Either you can use concurrent hashmap or add your logic to handle concurrency.

Eviction Logic is tightly coupled

Eviction logic is written within the get method, In future if we have to change the logic of expiring keys then it will modify the main expring cache class and violaets the Open Closed principle.

Redundant Remove method

Cache remove key is already getting called in get method.

Missing Logs

There are no logs in the code which impacts debugging during issues in production

Lack of Input Validation

The put() method does not validate the input, allowing null keys or values, which could cause unexpected behavior or NullPointerException.

Unbounded Cache Size

There is no limit to cache size It can grow indefinately and this might not be the expected behavior.

Lack of Evictions if items are not accessed

If any items is not accessed via get method it will not be removed from cache as well. This will keep cache size getting increased if not expired via some background job

Inefficient use of Hashmap

HashMap uses a default capacity of 16, which might waste memory if the cache size is small.

Higher Memory Footprint

Additional Map<K,Long> timestamp can be avoided if we save value as an object with key.

Lets see fulfill gaps!

Reduce Memory Footprint

import java.util.HashMap;
import java.util.Map;

public class ExpiringCache<K, V> {
    private final Map<K, V> cache = new HashMap<>();
    private final long expirationTimeMillis;

    public ExpiringCache(long expirationTimeMillis) {
        this.expirationTimeMillis = expirationTimeMillis;
    }

    public void put(K key, V value) {
        long timestamp = System.currentTimeMillis();
        cache.put(key, new cacheItem(V));
    }

public V get(K key) {
        if (!cache.containsKey(key)) {
            return null;
        }
        long timestamp = cache.get(key).timestamp;
        if (System.currentTimeMillis() - timestamp > expirationTimeMillis) {
            cache.remove(key);       // Remove from value map
            return null;
        }
        return cache.get(key); // Return the cached value
    }

private static class cacheItem<V>
  {
    V value;
    Long timestamp;
    publc cacheItem(V value)
    {
      this.value = value;
      this.timestamp = System.currentTimeMillis();    

    }

  }

    public void remove(K key) {
        valueMap.remove(key);
        timestampMap.remove(key);
    }

With above code we have reduced one hashmap and memory footprint.

Now lets add thread safety and reduce tight coupling

Implement Eviction Policy interface to reduce tight coupling. Interface defines the methods for any eviction policy.

public interface EvictionPolicy<K> {
    void recordAccess(K key);    // Record a key access
    void removeKey(K key);       // Remove a key from the policy
    K evict();                   // Decide which key to evict
}

LRU (Least Recently Used)Eviction Policy

import java.util.LinkedHashMap;
import java.util.Map;

public class LRUEvictionPolicy<K> implements EvictionPolicy<K> {
    private final LinkedHashMap<K, Boolean> accessOrder;

    public LRUEvictionPolicy() {
        this.accessOrder = new LinkedHashMap<>(16, 0.75f, true); // true = access order
    }

    @Override
    public void recordAccess(K key) {
        accessOrder.put(key, true);
    }

    @Override
    public void removeKey(K key) {
        accessOrder.remove(key);
    }

    @Override
    public K evict() {
        // Remove the oldest entry (first in the linked map)
        if (!accessOrder.isEmpty()) {
            return accessOrder.keySet().iterator().next();
        }
        return null;
    }
}

Least Frequently Used (LFU) Eviction Policy

import java.util.HashMap;
import java.util.Map;

public class LFUEvictionPolicy<K> implements EvictionPolicy<K> {
    private final Map<K, Integer> frequencyMap;

    public LFUEvictionPolicy() {
        this.frequencyMap = new HashMap<>();
    }

    @Override
    public void recordAccess(K key) {
        frequencyMap.put(key, frequencyMap.getOrDefault(key, 0) + 1);
    }

    @Override
    public void removeKey(K key) {
        frequencyMap.remove(key);
    }

    @Override
    public K evict() {
        // Find the key with the lowest frequency
        return frequencyMap.entrySet().stream()
                .min(Map.Entry.comparingByValue())
                .map(Map.Entry::getKey)
                .orElse(null);
    }
}

Added changes in Expiring Cache class

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class ExpiringCache<K, V> {
    private final Map<K, CacheItem<V>> cache = new ConcurrentHashMap<>();
    private final long expirationTimeMillis;
    private final int maxSize;
    private final EvictionPolicy<K> evictionPolicy;

    public ExpiringCache(long expirationTimeMillis, int maxSize, EvictionPolicy<K> evictionPolicy) {
        this.expirationTimeMillis = expirationTimeMillis;
        this.maxSize = maxSize;
        this.evictionPolicy = evictionPolicy;
    }

    public void put(K key, V value) {
        if (key == null || value == null) {
            throw new IllegalArgumentException("Key or value cannot be null");
        }

        if (cache.size() >= maxSize) {
            K evictKey = evictionPolicy.evict();
            if (evictKey != null) {
                cache.remove(evictKey);
                evictionPolicy.removeKey(evictKey);
                System.out.println("Evicted key: " + evictKey);
            }
        }

        cache.put(key, new CacheItem<>(value, System.currentTimeMillis()));
        evictionPolicy.recordAccess(key);
    }

    public V get(K key) {
        CacheItem<V> item = cache.get(key);
        if (item == null) {
            return null;
        }

        if (System.currentTimeMillis() - item.timestamp > expirationTimeMillis) {
            cache.remove(key);
            evictionPolicy.removeKey(key);
            return null;
        }

        evictionPolicy.recordAccess(key); // Update access in eviction policy
        return item.value;
    }

    public void remove(K key) {
        cache.remove(key);
        evictionPolicy.removeKey(key);
    }

    private static class CacheItem<V> {
        V value;
        long timestamp;

        CacheItem(V value, long timestamp) {
            this.value = value;
            this.timestamp = timestamp;
        }
    }

    public static void main(String[] args) {
        // Example with LRU Policy
        EvictionPolicy<String> lruPolicy = new LRUEvictionPolicy<>();
        ExpiringCache<String, String> lruCache = new ExpiringCache<>(5000, 3, lruPolicy);

        lruCache.put("key1", "value1");
        lruCache.put("key2", "value2");
        lruCache.put("key3", "value3");
        lruCache.get("key1"); // Access key1 to make it recently used
        lruCache.put("key4", "value4"); // Evicts key2 (least recently used)

        System.out.println(lruCache.get("key2")); // Should print null (evicted)
        System.out.println(lruCache.get("key1")); // Should print value1 (still in cache)

        // Example with LFU Policy
        EvictionPolicy<String> lfuPolicy = new LFUEvictionPolicy<>();
        ExpiringCache<String, String> lfuCache = new ExpiringCache<>(5000, 3, lfuPolicy);

        lfuCache.put("key1", "value1");
        lfuCache.put("key2", "value2");
        lfuCache.put("key3", "value3");
        lfuCache.get("key1"); // Access key1
        lfuCache.get("key1"); // Access key1 again (highest frequency)
        lfuCache.put("key4", "value4"); // Evicts key2 (least frequently used)

        System.out.println(lfuCache.get("key2")); // Should print null (evicted)
        System.out.println(lfuCache.get("key1")); // Should print value1 (still in cache)
    }
}

Key Features of the Refactored Code

Eviction Policy Configurable:

• The client can choose between LRU, LFU, or any custom policy by passing the desired EvictionPolicy implementation

Flexible Design:

• The EvictionPolicy interface allows easy addition of new policies.

Cache Size Management:

• Ensures the cache doesn’t grow beyond its configured size.

Thread Safety:

• Uses ConcurrentHashMap for safe concurrent access.

Efficient Eviction:

• Eviction logic is encapsulated in the EvictionPolicy, making the cache simpler.

Follow to get saty tuned for such articles!

This article is linked to previous one.

To address the gaps in the earlier version we are adding below changes to the code.

Thread Safety:

• Used ConcurrentLinkedQueue for the message queue to handle concurrent modifications safely.
• Used ConcurrentHashMap for retry counts to avoid race conditions when updating retry attempts.

Logging with SLF4J

• Replaced System.out.println and System.err.println with logger.info() and logger.error() for structured and production-ready logging.
• Included contextual information (e.g., message content) in log messages.

Graceful Shutdown

• Added logging for shutdown steps to indicate the state of the consumer during termination.
• Dynamic Message Processing:
• Ensured messages are processed in parallel using an ExecutorService.

ConsumerConfig Class

public class ConsumerConfig {
    private final int maxRetries;

    public ConsumerConfig(int maxRetries) {
        this.maxRetries = maxRetries;
    }

    public int getMaxRetries() {
        return maxRetries;
    }
}

MessageQueue Class (Thread-Safe):

import java.util.concurrent.ConcurrentLinkedQueue;

public class MessageQueue {
    private final ConcurrentLinkedQueue<String> queue = new ConcurrentLinkedQueue<>();

    public void addMessage(String message) {
        queue.add(message);
    }

    public String pollMessage() {
        return queue.poll();
    }

    public boolean isEmpty() {
        return queue.isEmpty();
    }
}

RetryPolicy Class

import java.util.concurrent.ConcurrentHashMap;

public class RetryPolicy {
    private final ConcurrentHashMap<String, Integer> retryCounts = new ConcurrentHashMap<>();
    private final ConsumerConfig config;

    public RetryPolicy(ConsumerConfig config) {
        this.config = config;
    }

    public boolean shouldRetry(String message) {
        retryCounts.putIfAbsent(message, 0);
        int count = retryCounts.get(message);
        if (count < config.getMaxRetries()) {
            retryCounts.put(message, count + 1);
            return true;
        }
        return false;
    }
}

MessageProcessor

public class MessageProcessor {
    public void process(String message) throws Exception {
        // Simulate message processing
        if (message.contains("error")) {
            throw new Exception("Processing error for message: " + message);
        }
        // Actual processing logic here
    }
}

MessageQueueConsumer

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class MessageQueueConsumer {
    private static final Logger logger = LoggerFactory.getLogger(MessageQueueConsumer.class);
    private final MessageQueue queue;
    private final RetryPolicy retryPolicy;
    private final MessageProcessor processor;
    private final ExecutorService executor;

    public MessageQueueConsumer(MessageQueue queue, RetryPolicy retryPolicy, MessageProcessor processor, int threadPoolSize) {
        this.queue = queue;
        this.retryPolicy = retryPolicy;
        this.processor = processor;
        this.executor = Executors.newFixedThreadPool(threadPoolSize);
    }

    public void consumeMessages() {
        while (!queue.isEmpty()) {
            String message = queue.pollMessage();
            if (message != null) {
                executor.submit(() -> processMessage(message));
            }
        }
    }

    private void processMessage(String message) {
        try {
            processor.process(message);
            logger.info("Successfully processed message: {}", message);
        } catch (Exception e) {
            logger.error("Error processing message: {}", message, e);
            if (retryPolicy.shouldRetry(message)) {
                logger.info("Retrying message: {}", message);
                queue.addMessage(message);
            } else {
                logger.error("Max retries reached for message: {}", message);
            }
        }
    }

    public void shutdown() {
        executor.shutdown();
        logger.info("Consumer shutdown initiated. Waiting for tasks to complete.");
    }
}

Main Class

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Main {
    private static final Logger logger = LoggerFactory.getLogger(Main.class);

    public static void main(String[] args) {
        try {
            MessageQueue queue = new MessageQueue();
            queue.addMessage("message1");
            queue.addMessage("message2");
            queue.addMessage("error1"); // This will cause an exception
            queue.addMessage("message3");

            ConsumerConfig config = new ConsumerConfig(3);
            RetryPolicy retryPolicy = new RetryPolicy(config);
            MessageProcessor processor = new MessageProcessor();
            MessageQueueConsumer consumer = new MessageQueueConsumer(queue, retryPolicy, processor, 4);

            consumer.consumeMessages();
            consumer.shutdown();
        } catch (Exception e) {
            logger.error("An unexpected error occurred", e);
        }
    }
}

Follow to get more such articles!

You are reviewing the implementation of a messaging queue consumer in Java. The code is supposed to consume messages from a queue, process them, and log the results. It also handles retries for failed messages.

Lets identify the issues with below code!

import java.util.*;
import java.util.concurrent.*;

public class MessageQueueConsumer {

    private final Queue<String> messageQueue = new LinkedList<>();
    private final Map<String, Integer> retryCount = new HashMap<>();
    private static final int MAX_RETRIES = 3;

    public void consumeMessages() {
        while (!messageQueue.isEmpty()) {
            String message = messageQueue.poll();

            try {
                processMessage(message);
                System.out.println("Processed message: " + message);
            } catch (Exception e) {
                System.err.println("Error processing message: " + message);

                // Retry logic
                int count = retryCount.getOrDefault(message, 0);
                if (count < MAX_RETRIES) {
                    retryCount.put(message, count + 1);
                    messageQueue.add(message); // Re-add to queue for retry
                } else {
                    System.err.println("Max retries reached for message: " + message);
                }
            }
        }
    }

    private void processMessage(String message) throws Exception {
        // Simulate message processing
        if (message.contains("error")) {
            throw new Exception("Simulated processing error");
        }
        // Message processing logic here
    }

    public void addMessage(String message) {
        messageQueue.add(message);
    }

    public static void main(String[] args) {
        MessageQueueConsumer consumer = new MessageQueueConsumer();
        consumer.addMessage("message1");
        consumer.addMessage("message2");
        consumer.addMessage("error1"); // This will cause an exception
        consumer.addMessage("message3");

        consumer.consumeMessages();
    }
}

Write down your points before you scroll down!

Below are few improvements in the above code!

Thread-Safety:

• The messageQueue and retryCount are not thread-safe. In a real-world scenario, the consumer may run in a multi-threaded environment, leading to race conditions or inconsistent states.
• Fix: Use thread-safe data structures such as ConcurrentLinkedQueue for the queue and ConcurrentHashMap for retry counts.

Hard-Coded Retry Logic:

• While you mentioned separating the retry logic into a config class, the retry count is directly tied to the messageQueueConsumer logic.
• Fix: Decouple retry logic into a separate RetryPolicy class, allowing flexible retry strategies.

Error Handling:

• Errors are logged but not propagated. If the consumer encounters persistent errors, there is no mechanism to alert or escalate issues.
• Fix: Introduce custom exceptions and callback hooks for handling critical failures.

Scalability:

• Processing messages synchronously limits scalability. High-throughput systems often process messages in parallel using worker threads.
• Fix: Use an ExecutorService or a thread pool for concurrent message processing.

Separation of Concerns:

The MessageQueueConsumer class is doing too much:

• Managing the queue
• Managing retry counts
• Processing messages

Fix: Separate responsibilities into distinct classes:

• MessageQueue for queue operations.
• RetryPolicy for retry logic.
• MessageProcessor for message handling.

Logging:

• System.out.println and System.err.println are used for logging, which is not suitable for production.
• Fix: Replace with a proper logging framework like SLF4J or Log4j.

Graceful Shutdown:

• There’s no mechanism to stop the consumer gracefully. In production systems, this could lead to lost messages or incomplete processing.
• Fix: Add support for shutting down the consumer cleanly.

Will add the improved version of code in the next article! To be Continued..

Many companies have started taking code review rounds. So lets go through one code review problem

UserService with Caching and Search Functionality — InMemory

You are reviewing a Java implementation for fetching user data from a database and using a cache for improved performance. The code also supports searching for users by their name using a filter.

import java.util.*;
import java.util.stream.Collectors;

public class UserService {

    private Map<Integer, String> userCache = new HashMap<>(); // Caches user data with userId as the key
    private Database database = new Database();

    // Fetch user by ID
    public String getUserById(int userId) {
        if (userCache.containsKey(userId)) {
            return userCache.get(userId);
        }

        String user = database.fetchUserById(userId);
        userCache.put(userId, user);
        return user;
    }

    // Fetch all users whose names contain a specific string
    public List<String> searchUsersByName(String keyword) {
        List<String> allUsers = database.fetchAllUsers();
        return allUsers.stream()
                .filter(name -> name.contains(keyword))
                .collect(Collectors.toList());
    }

    public static void main(String[] args) {
        UserService userService = new UserService();

        // Simulate fetching user data
        System.out.println(userService.getUserById(1)); // Fetch from DB and cache it
        System.out.println(userService.getUserById(1)); // Fetch from cache

        // Search for users
        System.out.println(userService.searchUsersByName("John"));
    }
}

// Mock Database class
class Database {
    private Map<Integer, String> userData = Map.of(
            1, "John Doe",
            2, "Jane Smith",
            3, "Alice Johnson",
            4, "Bob Brown"
    );

    public String fetchUserById(int userId) {
        return userData.getOrDefault(userId, "User not found");
    }

    public List<String> fetchAllUsers() {
        return new ArrayList<>(userData.values());
    }
}

What are the problems with above code? Spend a minute before you scroll further!….

Code Review Observations

1. Null Handling and Exception Handling

• Issue: If the user ID does not exist in the database, the fetchUserById method returns "User not found". This is inconsistent with how such cases should be handled in real-world applications.
• Fix: Throw a custom exception (UserNotFoundException) to handle cases where a user is not found by ID or name.

2. Inefficient Search for searchUsersByName

• Issue: The searchUsersByName method retrieves all users from the database and performs an in-memory filter. This is inefficient, especially for large datasets.
• Fix: Use a more suitable data structure, such as a Trie or an inverted index, to optimize search operations.

3. Improper Cache Management

• Issue: The cache is unbounded and can grow indefinitely. This can lead to memory issues over time.
• Fix: Use a bounded cache with an eviction policy (e.g., LinkedHashMap or a library like Guava's Cache).

4. Adherence to OOP Principles

• Issue: The Database class is tightly coupled to the UserService. It doesn't follow the dependency inversion principle.
• Fix: Use an interface for the database and inject it into the service for better testability and scalability.

Here is the improved version of code!

import java.util.*;
import java.util.stream.Collectors;

// Custom exception for User Not Found
class UserNotFoundException extends RuntimeException {
    public UserNotFoundException(String message) {
        super(message);
    }
}

// Interface for the database
interface UserDatabase {
    String fetchUserById(int userId);
    List<String> fetchAllUsers();
}

// User service with improved caching and search
public class UserService {

    private static final int CACHE_SIZE = 100;
    private final Map<Integer, String> userCache;
    private final UserDatabase database;

    public UserService(UserDatabase database) {
        this.database = database;
        this.userCache = new LinkedHashMap<>(CACHE_SIZE, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<Integer, String> eldest) {
                return size() > CACHE_SIZE;
            }
        };
    }

    // Fetch user by ID with null handling
    public String getUserById(int userId) {
        if (userCache.containsKey(userId)) {
            return userCache.get(userId);
        }

        String user = database.fetchUserById(userId);
        if (user == null) {
            throw new UserNotFoundException("User with ID " + userId + " not found.");
        }
        userCache.put(userId, user);
        return user;
    }

    // Optimized search using a Trie structure for names
    public List<String> searchUsersByName(String keyword) {
        if (keyword == null || keyword.isEmpty()) {
            throw new IllegalArgumentException("Search keyword cannot be null or empty.");
        }

        List<String> allUsers = database.fetchAllUsers();
        // For demo purposes: Simple in-memory search, replace with Trie or database query for real-world use
        return allUsers.stream()
                .filter(name -> name.toLowerCase().contains(keyword.toLowerCase()))
                .collect(Collectors.toList());
    }

    public static void main(String[] args) {
        UserDatabase database = new InMemoryDatabase();
        UserService userService = new UserService(database);

        // Test fetching users
        try {
            System.out.println(userService.getUserById(1)); // Fetch from DB and cache it
            System.out.println(userService.getUserById(1)); // Fetch from cache
            System.out.println(userService.getUserById(5)); // Should throw UserNotFoundException
        } catch (UserNotFoundException e) {
            System.err.println(e.getMessage());
        }

        // Test searching for users
        try {
            System.out.println(userService.searchUsersByName("John")); // Search by name
            System.out.println(userService.searchUsersByName(""));      // Should throw IllegalArgumentException
        } catch (IllegalArgumentException e) {
            System.err.println(e.getMessage());
        }
    }
}

// Mock implementation of UserDatabase
class InMemoryDatabase implements UserDatabase {
    private Map<Integer, String> userData = Map.of(
            1, "John Doe",
            2, "Jane Smith",
            3, "Alice Johnson",
            4, "Bob Brown"
    );

    @Override
    public String fetchUserById(int userId) {
        return userData.get(userId);
    }

    @Override
    public List<String> fetchAllUsers() {
        return new ArrayList<>(userData.values());
    }
}

Improvements Summary:

Null Handling:

• Custom exception UserNotFoundException for cases where a user ID or name is not found.

Search Optimization:

• While a simple in-memory search is shown, a Trie or inverted index would be better for efficient keyword-based searching.

Bounded Cache:

• The LinkedHashMap is being used to implement a Least Recently Used (LRU) Cache. It automatically removes the oldest entry (the least recently used one) when the cache size exceeds the specified limit.

OOP Design:

• Introduced an interface UserDatabase and an implementation InMemoryDatabase for flexibility and better testing.

Input Validation:

• Validated the search keyword to avoid null or empty searches.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

if you are interested in how we can add Trie data structure in above code, Adding Trie Code below:

class Trie {
    private final TrieNode root = new TrieNode();

    // Insert a word into the Trie
    public synchronized void insert(String word) {
        TrieNode current = root;
        for (char c : word.toCharArray()) {
            current.children.putIfAbsent(c, new TrieNode());
            current = current.children.get(c);
            current.addWord(word);
        }
        current.isEndOfWord = true;
    }

    // Search for words with a given prefix
    public synchronized List<String> searchByPrefix(String prefix) {
        TrieNode current = root;
        for (char c : prefix.toCharArray()) {
            current = current.children.get(c);
            if (current == null) {
                return Collections.emptyList();
            }
        }
        return current.words;
    }
}

UserService Class

public class UserService {

    private static final int CACHE_SIZE = 100;
    private final Map<Integer, String> userCache;
    private final Trie trie = new Trie();
    private final UserDatabase database;

    public UserService(UserDatabase database) {
        this.database = database;

        // Initialize bounded cache
        this.userCache = new LinkedHashMap<>(CACHE_SIZE, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<Integer, String> eldest) {
                return size() > CACHE_SIZE;
            }
        };

        // Prepopulate the Trie with all user names
        database.fetchAllUsers().forEach(trie::insert);
    }

    public String getUserById(int userId) {
        if (userCache.containsKey(userId)) {
            return userCache.get(userId);
        }

        String user = database.fetchUserById(userId);
        if (user == null) {
            throw new UserNotFoundException("User with ID " + userId + " not found.");
        }
        userCache.put(userId, user);
        return user;
    }

    public List<String> searchUsersByName(String keyword) {
        if (keyword == null || keyword.isEmpty()) {
            throw new IllegalArgumentException("Search keyword cannot be null or empty.");
        }
        return trie.searchByPrefix(keyword.toLowerCase());
    }

    // Add a new user dynamically
    public synchronized void addUser(int userId, String name) {
        if (name == null || name.isEmpty()) {
            throw new IllegalArgumentException("Name cannot be null or empty.");
        }

        // Add to the database (simulated here)
        database.addUser(userId, name);

        // Add to the cache and Trie
        userCache.put(userId, name);
        trie.insert(name.toLowerCase());
    }
}

UserDataBase and Inmemory Class

interface UserDatabase {
    String fetchUserById(int userId);
    List<String> fetchAllUsers();
    void addUser(int userId, String name); // New method for adding users
}

class InMemoryDatabase implements UserDatabase {
    private final Map<Integer, String> userData = new HashMap<>(Map.of(
            1, "John Doe",
            2, "Jane Smith",
            3, "Alice Johnson",
            4, "Bob Brown"
    ));

    @Override
    public String fetchUserById(int userId) {
        return userData.get(userId);
    }

    @Override
    public List<String> fetchAllUsers() {
        return new ArrayList<>(userData.values());
    }

    @Override
    public synchronized void addUser(int userId, String name) {
        userData.put(userId, name);
    }
}

Key Changes in above code:

Dynamic Name Addition:

• The addUser(int userId, String name) method allows new users to be added to the database, cache, and Trie.

Concurrency Handling:

• Trie methods (insert and searchByPrefix) and the addUser method are synchronized to make them thread-safe.

Database Update:

• The UserDatabase interface and its implementation now include an addUser method for dynamic updates.

Cache Update:

• New users are added to the cache if they fit within the CACHE_SIZE limit.

Consistent Trie Updates:

• The Trie is updated whenever a new user is added to maintain accurate search functionality.

Follow for more such updates!

To gain a comprehensive understanding of the scope and design requirements for the Rule Engine Service, asking the right questions will clarify functional needs, technical constraints, and performance expectations. Here are key questions you might want to ask:

Functional Scope and Use Cases

What is the primary purpose of the rule engine?

• Is it mainly for decision-making (e.g., fraud detection) or customer engagement (e.g., personalized offers)?

Who will be defining the rules, and how complex can these rules get?

• Are the rules configured by technical users or business users? Will complex rules (e.g., nested conditions, multiple dependencies) need to be supported?

Do we need to support specific domains (e.g., banking, e-commerce)?

• Each domain could require different types of rules and data. For instance, banking might need stricter compliance-related rules.

How often do rules change, and what kind of versioning is required?

• If rules change frequently, you may need easy version control, validation, and rollback capabilities.

Rule Execution and Evaluation

How should the rule engine handle execution requests?

• Will execution be synchronous, asynchronous, or a mix of both? When is each mode preferred?

Are there any external dependencies for rule evaluation (e.g., APIs for user data or external validation services)?

• Understanding external dependencies will inform timeout policies, retries, and handling for failed calls.

What level of complexity is expected for condition evaluations?

• Are rules simple (e.g., single conditions) or complex (e.g., conditional chains, multi-level dependencies)?

Will there be a need for priority-based execution for certain rules?

• Knowing if certain rules have higher priority will help in designing throttling and resource allocation strategies.

What is the expected latency for rule evaluation?

• Do specific use cases (like fraud detection) have strict latency requirements? If so, this could impact the infrastructure, caching, and prioritization.

Access Handling , Data Storage and Results

Will the rule engine need to store results of rule evaluations?

• Storing results may be essential for auditing, compliance, analytics, or feeding into a machine-learning model.

What data retention policies apply?

• Knowing data retention requirements will guide storage strategies and compliance needs (e.g., storing rule results for regulatory audits).

How long do rule results need to be stored, and are there privacy or compliance requirements

• Especially for banking or other regulated industries, understanding privacy needs will impact storage, encryption, and data access policies.

What level of access control is required for rule definitions and execution?

• Do different teams need different permissions (e.g., view-only vs. rule-editing permissions)?

Are there security or encryption requirements for data in transit or at rest?

• This is critical for sensitive data, especially in banking or healthcare, to ensure data privacy and integrity.

Should the rule engine support multi-tenancy?

• If multiple business units or clients use the same rule engine, you may need tenant-based isolation and access control.

We will continue on the design in the next article!

Running an engineering team is much like conducting an orchestra, where different characters play different roles. Each person is unique, bringing their own flair to the collective performance, but understanding the common archetypes can help you tailor your leadership style for maximum impact. Here’s a quick look at the types of people you’ll often find in your teams.

1. The “Why I am here”
Inexplicably, some individuals don’t seem to belong in the team at all will end up in your team. No one really understands how they passed the hiring bar, and they themselves appear clueless about their role. It’s a phenomenon that defies even the strictest recruitment process.

2. The “Blind Follower”
These are the team members who do exactly as they’re told. Thy either lack of curiosity to understand “what customer value” they are really delivering, or they are still new to the role. While they are dependable, they don’t contribute to growth or innovation.

3. The “Complainer”
They’re the seasoned members that always spot problems and are never shy to voice their concerns. However, they seldom have solutions. Their knack for identifying issues might make them good candidates for QA roles, compliance/security/operational best practice auditors, or just whistle blowers. Leaving them uncontrolled, they could become the source of negative energy force.

4. The “Fixer”
These individuals love troubleshooting. They are the “firefighters” who excel at solving immediate issues but they often lack the vision to redesign systems for long-term sustainability.

5. The “Shiny Toy Chaser”
Always on the lookout for the latest technologies, they’re quick to propose new tools and methodologies. However, their desire for novelty can distract from the team’s core objectives of efficiency and value delivery.

6. The “Dreamer”
They’re the visionaries who can see a grand future but lack the engineering finesse to chart a path to it. Their big ideas often remain just that — ideas.

7. The “Hard-Working Doers”
Always swamped with projects, these are your execution powerhouses. They’re so good at what they do that they often don’t have time to look for more efficient alternatives.

8. The “Ideal Engineer”
The ultimate engineer is a cocktail of the best qualities: visionary yet pragmatic, problem-spotter yet solution-finder. They keep one eye on the horizon and another on the immediate task at hand.

It’s tempting to label people and place them in boxes, but these archetypes should serve as a starting point to understand your team, not to pigeonhole them. By appreciating the diversity of skills and perspectives, understanding our behaviors both consciously and unconsciously, we not only strengthen our teams but also build robust, scalable systems that stand the test of time.

Referenced from Vadim kravcenko.

Me: Hey, did you attend the API interface review of your team?

Tommy: Nope, it sounded like a job for the engineers, not a SDM like me. Aren’t we micromanaging by getting into that level of design discussions?

Me: Ah, that’s a common thought. But the truth is, your perspective as an SDM is invaluable for crafting interfaces that are genuinely intention-revealing.

Tommy: “intention-revealing”? Can you explain?

Me: Sure. In a nutshell, Intention-Revealing Interfaces from Domain Driven Design are designed so that just by looking at the method names or properties, you can immediately understand what that part of the system is supposed to do. No need to delve into the code or documentation.

Tommy: Okay, so like changing a generic `update()` method to something more specific like `updateCustomerAddress()`?

Me: Exactly! By making the name more descriptive, the interface immediately reveals its intent to anyone who interacts with it, including non-engineers. That’s where you come in.

Tommy: How so?

Me: Well, engineers are amazing at figuring out how to do things, but they’re often so close to the technical aspects that they might pick names that make sense to them but not to anyone else. Like, instead of `securePassword()`, they might go for `hashAndStorePassword()`.

Tommy: Ah, that second one does give away a bit about the underlying technology.

Me: Precisely. It’s important to have interfaces that speak the language of the business domain, the ‘What’, not ‘How’

Tommy: That’s an eye-opener. So my role would be to guide the naming and design to make sure it’s aligned with business objectives and customer understanding?

Me: Bingo! You’ve got the big picture and the business objectives in mind, so you can help ensure that the interface doesn’t just make technical sense but is also aligned with what the company and the customer actually care about. For instance, imagine you’re dealing with a data synchronization operation in a big, distributed system. Engineers might think `initiateDataSync()` is enough. But what if it’s specifically about inventory? A more intention-revealing name might be `synchronizeInventoryAcrossStores()`.

Tommy: That’s a great point. `synchronizeInventoryAcrossStores()` speaks more about what the actual business operation involves.

Me: Exactly! So never underestimate your role in this. You’re the one who can help make these interfaces truly intention-revealing by bridging the gap between the technical and the business aspects. Remember, focusing on “what” and hiding “how” as much as possible makes for a stronger, more effective system. And that starts Intention Revealing Names in Interface

Tommy: Can’t wait to put this into practice. Thanks again for the valuable insights!

Me: You’re welcome! Keep pushing for clarity and simplicity. That’s how we elevate our game.

Its a pretty general question aseked to me by peopele who are in mid level -management in service based company!

Lets Understand the role first:

The Senior Technical Program Manager (TPM) role:

The Senior Technical Program Manager (TPM) role at Amazon is a leadership position with increased responsibility and impact. As a Senior TPM, you would be expected to demonstrate the following qualities:

1. Technical expertise: Deep understanding of the technology domain and the ability to guide technical architectural discussions, make informed decisions, and provide guidance to the engineering team.

2. Program management mastery: Extensive experience in managing complex and large-scale programs. Proficiency in project planning, execution, risk management, and resource allocation. Ability to drive initiatives from concept to delivery.

3. Leadership and mentorship: Act as a leader within the TPM community, inspiring and guiding others. Mentor junior TPMs and help them develop their skills. Lead by example, setting high standards and fostering a culture of excellence.

4. Cross-functional collaboration: Excel at building relationships and collaborating with stakeholders across different teams and departments. Drive alignment, manage dependencies, and ensure effective communication to achieve project goals.

5. Strategic thinking: Ability to align program objectives with long-term business and customer goals. Think strategically, anticipate future needs, and propose innovative solutions to address complex challenges.

6. Decision-making and problem-solving: Make informed decisions based on data, analysis, and sound judgment. Proactively identify and resolve issues, leveraging a combination of technical expertise, critical thinking, and collaboration.

7. Influence and negotiation: Skilled in influencing without authority and driving consensus among diverse stakeholders. Excellent negotiation skills to achieve alignment on priorities, resources, and timelines.

8. Operational excellence: Drive operational efficiency by implementing best practices, optimizing processes, and continually improving program management methodologies. Ensure projects are delivered with high quality and within established timelines.

9. Customer obsession: Demonstrate a deep understanding of customer needs and strive to deliver exceptional experiences. Advocate for customer-centricity and incorporate customer feedback into program planning and decision-making.

10. Continuous learning: Stay abreast of industry trends, emerging technologies, and best practices. Continuously develop your own skills and knowledge through learning opportunities and actively share knowledge with the team.

The Senior TPM role at Amazon requires a blend of technical expertise, program management skills, leadership abilities, and a customer-focused mindset. It is a challenging and rewarding position that plays a crucial role in driving the successful delivery of complex initiatives at scale.

What are the interview rounds for a TPM role in Amazon?

The interview process for a Senior Technical Program Manager (TPM) role at Amazon typically consists of several rounds designed to assess your technical expertise, program management skills, leadership abilities, and fit within Amazon’s culture. The specific interview rounds may vary based on the team and location, but here are some common rounds you can expect:

1. Phone/Screening Interview: This initial interview is typically conducted by a recruiter or a TPM from the team. It serves as an opportunity for the recruiter to assess your background, experience, and fit for the role. It may involve questions about your previous work experience, technical knowledge, and program management skills.

2. Technical Interview: This round focuses on assessing your technical skills and depth of knowledge in relevant areas. You may be asked to solve technical problems, design scalable systems, or discuss specific technical concepts related to the role. The interviewers may include TPMs or technical leaders from the team.

3. Leadership/Behavioral Interview: This round evaluates your leadership abilities, problem-solving skills, and alignment with Amazon’s leadership principles. You can expect questions about your experience in leading cross-functional teams, handling challenging situations, and driving results. The interviewers may include senior leaders from different teams.

4. Program Management Interview: This round assesses your program management skills, including your ability to plan, execute, and deliver complex projects. You may be asked to discuss your experience in managing programs, handling risks and dependencies, prioritizing tasks, and ensuring timely delivery. The interviewers may include TPMs or program managers from the team.

5. Bar Raiser/Leadership Bar Interview: This final round is conducted by an experienced Amazon leader who acts as a “bar raiser” to ensure the highest hiring standards. They assess your overall capabilities, alignment with Amazon’s leadership principles, and potential for long-term success in the role. This round may include a mix of technical, behavioral, and leadership questions.

It’s important to note that the interview process at Amazon is rigorous and highly focused on evaluating the candidate’s technical and leadership abilities. Demonstrating alignment with Amazon’s leadership principles is crucial throughout the interview process. Preparing for each round by studying technical concepts, practicing behavioral interview questions, and understanding Amazon’s leadership principles will increase your chances of success.

How to transition from a management role in a service-based company to a Technical Program Manager (TPM) role at Amazon?

Transitioning from a management role in a service-based company to a Technical Program Manager (TPM) role at Amazon requires a combination of technical expertise, program management skills, and familiarity with Amazon’s leadership principles. Here are some steps to help you prepare for the transition:

1. Enhance your Technical Skills: As a TPM at Amazon, you’ll need a strong technical foundation. Invest time in learning relevant technical concepts and tools used in the industry. Familiarize yourself with programming languages, cloud computing platforms, software development methodologies, and other technologies commonly used in your target role.

2. Develop Program Management Skills: TPMs are responsible for managing complex programs and projects. Focus on enhancing your program management skills, including areas such as project planning, risk management, stakeholder communication, and Agile methodologies. Seek opportunities to lead or contribute to projects with increasing complexity and scope.

3. Familiarize Yourself with Amazon’s Leadership Principles: Amazon places great emphasis on its leadership principles. Study and understand these principles as they will guide your behavior and decision-making as a TPM. Reflect on your past experiences and identify instances where you demonstrated alignment with these principles.

4. Highlight Relevant Experience: Update your resume and LinkedIn profile to highlight projects or initiatives where you played a TPM-like role, such as coordinating cross-functional teams, managing stakeholders, driving technical delivery, or solving complex problems. Emphasize your ability to lead, influence, and deliver results.

5. Prepare for Behavioral Interviews: Amazon’s interview process includes behavioral interviews that assess your alignment with the leadership principles. Practice answering behavioral interview questions that demonstrate your experience in decision-making, problem-solving, customer obsession, bias for action, and other key leadership principles.

6. Leverage Your Network: Reach out to individuals who are currently working as TPMs at Amazon or have transitioned from a similar background. Seek their advice, ask for informational interviews, and learn from their experiences. They can provide valuable insights and guidance throughout your transition process.

7. Be Persistent and Patient: Transitioning to a TPM role at Amazon can be competitive. Be persistent in your efforts, continue to learn and develop your skills, and apply for suitable opportunities. It may take time to secure the role, so be patient and keep refining your approach based on feedback and insights gained along the way.

Remember that each candidate’s journey is unique, so tailor your preparation to your specific background and goals. Stay focused, continue learning, and leverage your experience to showcase your potential as a successful TPM at Amazon.

All the Best!

You can connect me at Topmate or LinkedIn for any guidance!