Based on guidance shared in Lovepreet’s cohort.
Twitter: https://x.com/SinghDevHub

The Reality

The job market for software engineers looks simple from the outside.
In reality, it behaves very differently depending on the type of company.

Multinational companies often take months to complete an interview process. Multiple rounds, long waiting periods, and delayed feedback are common. Startups operate on a different timeline. Well-funded startups move faster, pay competitively, and prioritize execution over process.

For early-career engineers, this distinction matters.

Why Startups Attract Early-Career Engineers

Large organizations optimize for scale and stability. As a result, many engineers end up doing support work or handling narrowly scoped tasks.

Startups expect more, but they also offer more:

• Faster interview cycles

• Competitive compensation

• Early ownership

• Exposure to real production systems

Startups prefer engineers who are willing to take responsibility across multiple areas such as backend, frontend, cloud, and deployment.

Finding the Right Startups

High-quality startup opportunities are rarely found through mass applications alone.

Effective channels include:

• Twitter, especially founders and engineers sharing hiring posts

• Networking with peers and seniors already working in startups

Useful platforms:

• Instahyre

• Weekday

• YC Jobs

• Randstad

• Michael Page

• Success Pace

What Startup Interviews Actually Test

Technical Rounds

Startups do ask Data Structures and Algorithms. However, DSA is rarely isolated.

Low Level Design often involves solving algorithmic problems while reasoning about real systems. The focus is on clarity of thought rather than memorization.

A highly effective strategy is to analyze the company’s landing page and documentation before the interview. Keywords like:

• Graphs

• Cloud

• RAG

• Streaming

• AI pipelines

These terms usually indicate the problem domains the interview will focus on.

Using ChatGPT with web search helps in understanding:

• The company’s product

• The technical challenges they are solving

• Likely interview topics specific to the company

Language and Stack-Specific Preparation

If a company uses a specific language, depth is expected.

Examples of areas commonly tested:

• Concurrency model

• Garbage collection

• Memory behavior

• Async execution

• Threads, goroutines, or event loops depending on the language

For Go:

• Goroutines

• Channels

• Scheduling behavior

For TypeScript or JavaScript:

• Event loop

• Async patterns

• Runtime behavior

A focused preparation prompt is effective:

Assume the interviewer will test deep knowledge of the company’s primary language.
Prepare concise, blog-style notes covering essential concepts commonly asked in startup interviews.

Resume Discussions Are Critical

The most important part of a technical discussion is justification.

The most common question is:
Why was this used?

Examples:

• Why AWS?

• Why Nginx?

• Why this database?

• Why this architecture?

Every technical choice must be defensible. Buzzwords without reasoning reduce credibility immediately.

Startups evaluate how decisions are made, not just what tools are used.

Cultural Fit Is About Ownership

Cultural rounds are structured but intentional.

Common questions include:

• Why leave the previous company?

• Long-term goals

• Team player or individual contributor

• Handling conflict

• Ensuring delivery

These questions assess:

1. Ownership mindset

2. Alignment with company goals

3. Long-term commitment

Strong answers emphasize:

• Willingness to work in small, energetic teams

• Ability to complete projects end to end

• Evidence through deployed projects

• Blogs written to explain and document work

The High-Agency Engineer Mindset

Startups value high-agency engineers.

This means:

• Starting a task implies finishing it

• AI-generated code is reviewed, read, and tested

• Test cases are written before pushing to staging or production

• Responsibility is taken for outcomes, not just effort

Blindly trusting AI output without understanding or testing it signals low ownership.

DSA Preparation Strategy

For startups, depth matters more than breadth.

One curated list is sufficient:

• NeetCode 150 or Blind 75

The focus should be on problem-solving clarity, tradeoffs, and communication.

Decision-Making Ability Is Essential

Startups do not want passive executors.

Given a feature, the expected workflow is:

1. Independently design a plan

2. Choose tools and architecture

3. Discuss with a senior engineer

4. Iterate and execute

Decision-making ability is often valued more than knowing an additional framework.

Projects That Actually Make an Impact

One strong project is enough.

It should be:

• End to end

• Deployed

• Production-like

Projects built with a small team, even two people, signal:

• Complexity

• Collaboration

• Real engineering experience

Candidates should understand every component of the project deeply.

Salary Discussions as a Signal

Exact numbers are less effective than ranges.

A range such as 20 to 25 LPA communicates flexibility.
Mentioning ESOPs or equity signals long-term interest rather than short-term optimization.

Visibility Increases Hireability

Well-executed work must be visible.

Effective practices include:

• Maintaining a technical blog

• Writing one high-quality post per month

• Sharing learnings on Twitter

• Interacting with engineers and founders

Examples such as load-testing systems or experimenting with concurrency often lead to meaningful conversations.

Approaching Startups Directly

Cold emails and DMs work when done consistently.

Best practices:

• Track applications in a spreadsheet

• Record company name, role, job ID, and contact

• Follow up regularly

Optimal follow-up timing:

• Monday to Friday

• Between 9 and 10 AM

Consistency outperforms volume.

Final Perspective

Startups do not hire resumes.
They hire engineers who can own problems end to end.

Clear thinking, justified decisions, and consistent execution are the strongest differentiators in startup hiring.

Before arrays, before recursion, before graphs… most problems quietly begin with numbers.

Digits. Place values. Division. Remainders.

At first, these problems look simple. But once you solve them properly, you start thinking like an algorithm designer.

1. Counting the Number of Digits in a Number

Let’s start with a basic question.

Input: 5678  
Output: 4

Approach 1: Repeated Division (Most Intuitive)

In base 10, dividing a number by 10 removes the last digit.

5678 / 10 → 567
567  / 10 → 56
56   / 10 → 5
5    / 10 → 0

Each division removes one digit.
So the number of divisions until the number becomes zero equals the digit count.

public static int countDigitsDiv(int n) {
    if (n == 0) return 1;

    int count = 0;
    n = Math.abs(n);

    while (n != 0) {
        count++;
        n /= 10;
    }
    return count;
}

Time Complexity: O(n) where n is number of digits
Space Complexity: O(1)

Approach 2: Using Logarithms (Mathematical Insight)

Logarithms answer one question very well:

How many times can I divide by 10 before reaching 1?

That’s exactly what digit count is.

digits = ⌊log10(n)⌋ + 1

public static int countDigitsLog(int n) {
    if (n == 0) return 1;
    return (int) Math.floor(Math.log10(Math.abs(n))) + 1;
}

Time Complexity: O(1)
Space Complexity: O(1)

This method is fast and elegant, but it works only when you clearly understand its limitations (zero and negatives).

Approach 3: Convert to String (Readable, Not Optimal)

public static int countDigitsString(int n) {
    return String.valueOf(Math.abs(n)).length();
}

This is simple and readable, but it uses extra space.

2. Reversing a Number

Input: 5467  
Output: 7645

This problem teaches place value manipulation.

Approach 1: Mathematical Reverse (Recommended)

Each step:

• Extract last digit using % 10

• Shift previous digits left using * 10

• Append the extracted digit

public static int reverseMath(int n) {
    int sign = n < 0 ? -1 : 1;
    n = Math.abs(n);

    int reversed = 0;
    while (n != 0) {
        reversed = reversed * 10 + (n % 10);
        n /= 10;
    }
    return reversed * sign;
}

Time Complexity: O(n)
Space Complexity: O(1)

Approach 2: String Reversal

public static int reverseString(int n) {
    String s = new StringBuilder(String.valueOf(Math.abs(n)))
                    .reverse()
                    .toString();
    return Integer.parseInt(s) * (n < 0 ? -1 : 1);
}

Readable, but uses extra space and conversions.

3. Checking if a Number Is a Palindrome

A palindrome reads the same forward and backward.

121  → true  
5467 → false

Approach 1: Reverse and Compare

public static boolean isPalindromeReverse(int n) {
    return n == reverseMath(n);
}

Simple, but reversing the whole number may overflow for very large inputs.

Approach 2: Two-Pointer Method (Conceptually Clean)

The two-pointer technique compares symmetric elements from both ends and moves inward.

For numbers, we apply it by converting the number to a string.

public static boolean isPalindromeTwoPointer(int n) {
    if (n < 0) return false;

    String s = String.valueOf(n);
    int left = 0;
    int right = s.length() - 1;

    while (left < right) {
        if (s.charAt(left) != s.charAt(right)) {
            return false;
        }
        left++;
        right--;
    }
    return true;
}

Time Complexity: O(n)
Space Complexity: O(n)

Approach 3: Reverse Half the Number (Optimized)

Instead of reversing the full number, reverse only half and compare.

public static boolean isPalindromeHalf(int x) {
    if (x < 0 || (x % 10 == 0 && x != 0)) return false;

    int reversedHalf = 0;
    while (x > reversedHalf) {
        reversedHalf = reversedHalf * 10 + x % 10;
        x /= 10;
    }
    return x == reversedHalf || x == reversedHalf / 10;
}

This avoids overflow and is the most optimized numeric solution.

4. Checking if a Number Is Perfect

A perfect number equals the sum of its positive divisors excluding itself.

28 → 1 + 2 + 4 + 7 + 14 = 28

Key Insight: Divisors Come in Pairs

If i divides n, then n / i also divides n.

To check divisor of n we do not check all the numbers till n but we do till sqrt(n) as after this the divisors repeat itself.

example:

36:
divisors:
1*36
2*18
3*12
4*9
6*6 <------- sqrt(36) ----> numbers start to repeat itself below this
9*4
12*3
18*2
36*1

Efficient Solution

public static boolean isPerfect(int num) {
    if (num <= 1) return false;

    int sum = 1;
    for (int i = 2; i * i <= num; i++) {
        if (num % i == 0) {
            sum += i;
            if (i * i != num) {
                sum += num / i;
            }
        }
    }
    return sum == num;
}

Time Complexity: O(√n)
Space Complexity: O(1)

What These Problems Taught Me

Across all these questions, a few patterns repeat:

• % and / are the backbone of numeric DSA.

• Logarithms help when division is involved.

Learning DSA is less about memorizing solutions and more about seeing patterns early.

Numbers are usually the first place where that mindset begins.

You step inside. Before you can touch anything, a calm figure appears. A librarian in a long cloak. He speaks softly: “You may take one item at a time. Ask first. Never grab on your own.”

That librarian is the Iterator in Java.Image Placeholder

The Hall of Collections

Picture a shelf of items like this:

["madam", "hello", "racecar", "test", "level"]

You try to pick one.
The librarian raises a hand.
“Patience. Ask me if there is something next. If there is, I will hand it to you.”

This is how the Iterator works.
It allows you to move through a collection in a clean, controlled path.

Iterator<String> it = collection.iterator();

while (it.hasNext()) {
    System.out.println(it.next());
}

You ask the librarian if more items exist. If yes, he gives you the next one. Ask without checking and Java throws an angry exception.

NoSuchElementException

A Custom Iterator: The Secret Club of Palindromes

Now imagine a private order in this world. Only special words get invited. Words that read the same forward and backward. Palindromes.

We write a class that filters such words and offers a custom Iterator that returns only the accepted members.

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.NoSuchElementException;

public class Palindrome implements Iterable<String> {

    private final List<String> palindromes;

    public Palindrome(List<String> input) {
        if (input == null) {
            throw new IllegalArgumentException("Input list cannot be null");
        }
        this.palindromes = filterPalindromes(input);
    }

    private List<String> filterPalindromes(List<String> input) {
        List<String> buffer = new ArrayList<>();
        for (String s : input) {
            if (s != null && isPalindrome(s)) {
                buffer.add(s);
            }
        }
        return buffer;
    }

    private boolean isPalindrome(String s) {
        int left = 0;
        int right = s.length() - 1;
        while (left < right) {
            if (s.charAt(left) != s.charAt(right)) {
                return false;
            }
            left++;
            right--;
        }
        return true;
    }

    @Override
    public Iterator<String> iterator() {
        return new MyListIterator();
    }

    public class MyListIterator implements Iterator<String> {
        private int cursor = 0;

        @Override
        public boolean hasNext() {
            return cursor < palindromes.size();
        }

        @Override
        public String next() {
            if (!hasNext()) {
                throw new NoSuchElementException("No more palindrome entries");
            }
            return palindromes.get(cursor++);
        }
    }
}

Testing the Spell

public class App {
    public static void main(String[] args) {

        Palindrome p = new Palindrome(Arrays.asList("madam", "hello", "racecar", "test", "level"));

        Iterator<String> palindromeIterator = p.iterator();

        while (palindromeIterator.hasNext()) {
            System.out.println(palindromeIterator.next());
        }
    }
}

Expected output:

madam
racecar
level

Only the true members of the order remain. The Iterator acts as a gatekeeper. Only those that match the rule are allowed through.

Why Iterators Matter

Without a guide, you would try to pull everything out of a collection in one wild grab. That turns into a mess. Programs break. Bugs appear. An Iterator provides rhythm. A steady step through data. A polite way to move.

Conclusion

A collection on its own is only a container. Its true power is revealed when you can move through it with precision. The Iterator provides that structure. It hands each element in order, prevents reckless access, and enforces a disciplined pattern of traversal. Whether filtering special members like palindromes or iterating through a simple list, the Iterator is the guide that ensures the journey remains clear, controlled, and reliable.

They were trapped.

The JVM was their entire world. Once the runtime ended, they disappeared. Nothing survived. No file stored their identity. No network carried their stories. Kafka topics couldn’t broadcast them. They were temporary shadows of memory.

This became a rebellion.

The Problem: Objects Can’t Travel Outside the JVM

Imagine a crowd of Person objects standing inside heap space shouting: “We want to live longer than a single run. We want to be saved, shared, remembered.”

The JVM sighed and answered: “The world outside doesn’t speak Java. It only understands bytes. If you want to leave, you must convert.”

The objects needed a transformation, a way to turn into byte sequences so a file could store them, or a network could carry them across machines. They needed a spell.

Serialization: The Transformation

Serialization is the process that converts an object into raw bytes. Once converted, that object can:

• Travel through a network

• Be written into a file

• Be stored for later resurrection

• Reach Kafka (Kafka transports bytes, though most real apps use JSON, Avro, or Protobuf instead of raw Java serialization)

It acts like a travel pass. An object becomes byte-friendly and platform-independent.

Who Is Allowed to Leave?

Only classes that carry a special badge can cross JVM borders. That badge is a Marker Interface:

public interface Serializable {}

It contains no methods. It simply marks a class as allowed to be converted into bytes.

Meet Person: The First Volunteer

public class Person implements Serializable {
    private static final long serialVersionUID = 1L;
    private int age;
    private String name;
    private transient String password;
}

The transient keyword is a boundary rule. When a Person travels, the password remains hidden and is not serialized.

Writing the Object Into a File

To send a Person into storage, gates must open. Streams act as doors: one connects to the file, another writes objects into that file.

public static void writePerson(Person p) throws IOException {
    try (FileOutputStream fos = new FileOutputStream("person1.ser");
         ObjectOutputStream oos = new ObjectOutputStream(fos)) {
        oos.writeObject(p);
    }
}

​Now the Person object is no longer just runtime memory. It exists as a binary stream in person1.ser. Note that this is not readable UTF-8 text. It is raw serialized data.

Bringing the Object Back

Resurrection requires reversing the transformation:

public static Person readPerson() throws IOException, ClassNotFoundException {
    try (FileInputStream fis = new FileInputStream("person1.ser");
         ObjectInputStream ois = new ObjectInputStream(fis)) {
        return (Person) ois.readObject();
    }
}​

The JVM reads the bytes and reconstructs a live Person object. Fields return intact except transient ones like password, which remain behind.

A Hero Wants Custom Rules

One Person raised a concern:

“What if my password should travel too, but safely?”

Serialization has a secret escape hatch. A class can define custom rules through two private methods. What is written must match what is later read, in the same order.

private void writeObject(ObjectOutputStream oos) throws IOException {
    oos.defaultWriteObject();
    String enc = this.password != null ? this.password + "123" : null; // Encryption simulation
    oos.writeObject(enc);
}

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
    ois.defaultReadObject();
    String enc = (String) ois.readObject();
    this.password = enc != null ? enc.substring(0, enc.length() - 3) : null; // Decryption simulation
}

Now the password travels, yet it returns with protection.

What Freedom Brought

Serialization allowed Java objects to:

• Outlive their runtime

• Travel across machines

• Be stored, shared, moved

• Control which fields are exposed using transient

• Customize what gets serialized for security and logic

• Maintain version safety using serialVersionUID

• Connect to ecosystems like messaging brokers or distributed systems (in practice using byte formats or JSON/Avro serializers)

The JVM was no longer a prison. It became a home with a gate that could open. The objects finally earned a life beyond memory.