Getting started with technical interviews can feel like staring at a brick wall, but the trick is to master the patterns, not just the syntax. These three problems cover the fundamental data structures (Arrays, Strings, and Hash Maps) that crop up in almost every interview.

Subscribe now

1. Two Sum

The Goal: Given an array of integers and a target, return the indices of the two numbers that add up to that target.

This is arguably the most famous coding problem because it teaches the Hash Map optimization.

def twoSum(nums, target):
    prevMap = {} # val : index

    for i, n in enumerate(nums):
        diff = target - n
        if diff in prevMap:
            return [prevMap[diff], i]
        prevMap[n] = i

Approach: Use a Hash Map to store values we’ve already seen. This allows us to find the “complement” (target - current) in O(1) time, making the total algorithm O(n).

2. Valid Palindrome

The Goal: Determine if a string reads the same forward and backward, ignoring non-alphanumeric characters and casing.

This problem tests string manipulation and the Two-Pointer technique, which is a vital pattern for more complex problems.

def isPalindrome(s):
    # Clean the string: remove non-alphanumeric and lowercase everything
    l, r = 0, len(s) - 1
    
    while l < r:
        while l < r and not s[l].isalnum():
            l += 1
        while r > l and not s[r].isalnum():
            r -= 1
        
        if s[l].lower() != s[r].lower():
            return False
        l += 1
        r -= 1
        
    return True

Pro Tip: Instead of creating a reversed copy of the string (which takes extra memory), we use two pointers to meet in the middle. This keeps our space complexity at O(1).

3. FizzBuzz

The Goal: Print numbers from 1 to n. For multiples of 3, print “Fizz”; for multiples of 5, print “Buzz”; for multiples of both, print “FizzBuzz”.

This is the classic “smoke test” to ensure a candidate understands basic loops and conditionals.

def fizzBuzz(n):
    result = []
    for i in range(1, n + 1):
        if i % 3 == 0 and i % 5 == 0:
            result.append("FizzBuzz")
        elif i % 3 == 0:
            result.append("Fizz")
        elif i % 5 == 0:
            result.append("Buzz")
        else:
            result.append(str(i))
    return result

Pro Tip: The order of the if statements matters! If you check for % 3 first, “FizzBuzz” numbers (like 15) will incorrectly stop at “Fizz.”

Where to practice these?

I highly recommend LeetCode or HackerRank. Most of these are categorized as “Easy” on those platforms.

Which of these concepts feels the most intimidating to you? The logic of the problem itself, or the time/space complexity part?

Resources

• https://leetcode.com

• https://www.hackerrank.com

Git commit: add salt to taste

If you cook at home, there’s probably a massive pot on your stove that’s been going for three hours. You’ve tasted it four times. You added a pinch of something, waited, tasted again. “It’s still not done yet? Ugh.” But it’s closer than it was. And somehow, you already know you’ll make it differently next time.

That pot is also, whether you realize it or not, a version control system.

Stay with me here.

The Commit History You Never Knew You Had

In software development, version control is how engineers track changes to a codebase over time. Every edit, every fix, every experimental tweak gets logged: who changed what, when, and why. The most popular tool for this is Git, and its core unit is something called a commit: a snapshot of the project at a specific moment in time.

Your slow-cooked sauce works the same way. Every time you lift the lid and adjust? Add more salt? A splash of wine? Turn the heat down? Add the herbs later this time? That’s called a commit. A small, deliberate change to an evolving “thing.”

In a real codebase, it looks like this:

git add .

git commit -m “added anchovy paste, reduced heat to low, let rest 20 min”

That message? That’s your personal margin note. The sauce you’re serving tonight isn’t the one you started this morning. It’s the accumulated result of every decision, every taste, every correction. So then, you can see the whole story:

git log --oneline

a3f9c21 added anchovy paste, reduced heat to low, let rest 20 min

b81e04d splash of red wine, stirred in slowly

c29d17a salt adjustment — too flat, added more

e14a882 initial commit — base sauce, onions, tomatoes, olive oil

Some cooks keep a recipe notebook. Recipe notebooks consist of recipes that do not necessarily look like the original. It’s just the cook’s own version of it, with notes in the margins. Less sugar next time. Add anchovy earlier. Don’t skip the rest. That notebook is your commit log.

Branching: When You Try Something New

In version control, branching is what you do when you want to experiment without breaking the main project. You spin off a copy, try something risky, and either merge it back in or abandon it, all without touching the original.

Cooks do this constantly. Maybe you want to try a version with white wine instead of red. Or make it spicier for the friend coming to dinner who “likes heat.” So you ladle some into a smaller pot and experiment there.

In Git, you’d do this:

git checkout -b spicy-version

# now experimenting freely — the main sauce is untouched

If it works, you bring it back:

git checkout main

git merge spicy-version

If it doesn’t, you walk away. The original is still on the stove, low and slow, unbothered. And saving a cup of the base before you start experimenting? That’s git stash. Your flavors are now set safely aside.

Merge Conflicts: When Something Goes Wrong

In Git, a merge conflict happens when two versions of the same file have been changed in incompatible ways, and the system can’t reconcile them automatically. A human has to step in.

CONFLICT (content): Merge conflict in sauce.txt

Automatic merge failed; fix conflicts and then commit the result.

In a slow-cooked sauce, that’s the moment you over-salted it. Or reduced it too far. Or added the cream before the acid and now everything’s curdled and you’re standing in your kitchen at 7pm slightly panicked. Your vision and your pot are no longer in sync. You have to intervene. Add a potato to absorb the salt, thin it with stock, start negotiating.

Sometimes you can salvage it. Sometimes you reach for the base you set aside earlier and start from there:

git reset --hard e14a882

# back to the beginning. we try again.

Forks: Passing the Recipe On

Open-source software projects get forked all the time. Someone takes the existing code, copies it, and builds something entirely new on top of it. The original continues. So does the fork. They share a common ancestor but diverge from there.

When you share your recipe with a friend, you’re forking it. She’ll make it in a different kitchen, with different instincts, different adjustments. Her version will drift from yours over time. There will be different commits, different margin notes. Same origin story, different changelog.

On GitHub, a fork looks like this:

gigi/sunday-sauce ← original

clara/sunday-sauce ← forked, now evolving independently

Some family recipes have been forked across generations. Your grandmother’s Sunday sauce, your mother’s version, yours. All related, all distinct. A lineage of slow, careful iteration that no repository could fully hold.

The Real Point

What version control and a slow-cooked recipe share isn’t just a clever metaphor; it’s a philosophy rather. Both are built on the understanding that nothing is finished on the first try, that history matters, that you should always be able to trace how you got here, and that sometimes the best move is to go back two steps and adjust.

Both also require patience. You can’t rush merging a code branch. You can’t rush braising a curry stew.

And both, when tended carefully over time, produce something that feels like it could only have come from you.

Even if only one of them pairs well with a glass of wine.

References & Further Reading

∙ git commit → Git Documentation

∙ git log → Git Documentation

∙ git branch → Git Documentation

∙ git merge → Git Documentation

∙ git stash → Git Documentation

∙ git reset → Git Documentation

∙ Forking a repository → GitHub Documentation

I am not here to take that away from you entirely, but rather to tell you that the story is significantly more complicated, and that the part of your digital life that is actually destroying the environment has nothing to do with your screen brightness.

Your “cloud” is actually a building

Let’s start with the thing almost no one pictures when they hear the world “cloud.” The cloud is not a diffuse, weightless phenomenon. It is not floating somewhere above your city, passive and efficient. The cloud is a warehouse. Often many warehouses, stacked with servers, running at a full capacity around the clock, generating enormous amounts of heat, and requiring industrial-scale cooling systems to keep from melting. These facilities are called data centers, and they are among the most energy-intensive structures humans have ever built.

There are data centers in the desert outside of Phoenix. There are data centers in the hills of Virginia. There are data centers in Ireland, Singapore, and rural North Carolina, and other places, chosen partly for their cheaper land and power costs, and partly because the local governments were willing to offer tax incentives in exchange for the promise of infrastructure investment. You’d think they are glamorous, but in actuality, they don’t even show up in the marketing materials for the apps they power. They just run, continuously, consuming electricity at scale that rivals mid-sized cities.

According to the International Energy Agency’s 2025 Energy and AI report, data centers globally consumed roughly 200 to 250 terawatt-hours of electricity in recent years. This figure has continued to climb as synthetic media app workloads, video streaming, and cloud storage demand accelerate. To put that in terms that are slightly more legible, that is roughly the annual electricity consumption of some entire countries and it is not even close to a rounding error. It is a structural feature of the digital economy that the digital economy prefers not to discuss.

So when you tap “back up photos to iCloud” without a second thought, you are not doing something weightless. You are writing to a physical server in a physical building that is consuming physical energy. The photos from 2019 that we occasionally look at from time to time is sitting in a rack somewhere, costing a fraction of a cent to store, multiplied by billions of similar decisions made by billions of similar people, adding up to something that matters.

The dark mode situation, spoken honestly

Back to the toggle.

Dark mode does save battery life but only on OLED and AMOLED screens, where dark pixels are achieved by turning off individual LEDs rather than filtering a backlight. On an older LCD screen, dark mode saves essentially nothing because the backlight stays on regardless. Even on OLED, the savings are highly dependent on brightness. Purdue University researchers who built one of the first accurate OLED power profiling tools found that at typical indoor brightness levels of 30-50%, switching to dark mode saves only 3-9% of screen power on average. At maximum outdoor brightness, those savings climb to 39-47% percent depending on screen brightness and usage, which is a range wide enough to tell you that context matters enormously. That is a narrow scenario: screen power, or what the girls like to call “screen time,” is a small slice of your device’s total energy consumption to begin with.

The more important point is this: screen power consumption is a tiny fraction of the energy story of your device, which is itself a tiny fraction of the energy story of the services your device connects to. You could run your phone screen at maximum brightness 24 hours a day and it would still be negligible compared to the server infrastructure required to deliver the feed on your favorite video-doomscrolling app.

Dark mode is not nothing. But it is also not the variable that matters most. It is a local optimization on a system that has much larger ineffective upstream.

The actual problem: software as physical infrastructure

Here is the part that does not get nearly enough attention, and the part I find genuinely fascinating as someone who works in engineering.

Software has weight.

No, not literal weight, obviously. But software that is written inefficiently, that makes more computational requests than it needs to, that stores more data than it needs to, that runs more processes simultaneously than the task requires, consumes more energy to execute. And at scale, that difference is physically measurable in the output of power plants.

This is the discipline of green software engineering, and it is an emerging field that sits at the intersection of performance optimization and environmental accountability. The core argument is simple: a leaner, faster application is almost always a greener one, because efficiency in computation maps directly to efficiency in energy use.

Consider what happens when a developer writes a database query that retrieves ten thousand records when the application only needs fifty. That query runs on a server somewhere. The server uses electricity to execute it. The electricity was generated somewhere, possibly from a gas-fired plant, possibly from a coal plant. The developer will never see that connection. Instead, they are looking at a screen in an office, thinking about load times. But the connection still exists.

Green software engineering asks developers to hold that connection in mind. It involves practices like: reducing the number of API calls an application makes, optimizing algorithms so they complete tasks with fewer computational steps, designing systems that scale down during low-traffic periods rather than running at full capacity by default, and choosing data storage architectures that mining redundancy without sacrificing reliability.

The inverse of this looks like software designed not for efficiency but instead designed for maximum engagement, and that has a measurable physical cost. Short-form video platforms are the most intrusive case. According to a 2024 analysis by Greenly, a carbon accounting firm, video-heavy platforms consumes significantly more energy per minute of use than text or image-based ones. The gap is a direct consequence of the platform’s architecture: continuous video streaming, autoplay that never pauses to ask if you want to continue, and an algorithm engineered to maximize time spent. The cumulative result across the category is an emissions footprint that rivals the annual output of mid-sized countries.

The platforms most responsible for this design pattern have also been the least transparent about its cost. The Greenhouse Gas Protocol, the dominant emissions reporting framework, does not require social media platforms to disclose their full environmental impact. That means the companies that most aggressively redesigned how a generation consumes content have largely have been able to opt out of accounting for what that redesign costs the atmosphere. Carbon neutrality pledges exist. Meaningful, verifiable progress toward them is harder to find.

None of this is glamourous. It is simply the kind of engineering work that rarely gets celebrated because it produces invisible results, like the absence of wasted energy rather than the presence of a shiny new feature. But the Green Software Foundation, an industry consortium whose Software Carbon Intensity specification became an ISO standard in 2024, has documented real-world cases where efficiency improvements produced measurable emissions reductions. One implementation across 60 applications achieved an average 15 percent reduction in CO₂ output. The gains do not require new hardware, new infrastructure, or new supply chains. They require better decisions at the code level.

Software efficiency improvements could represent one of the most scalable levers available for reducing the tech sector’s environmental footprint.

Digital hoarding is an environmental behavior

I also want to stay practical for a moment, because I think it matters that this does not feel “abstract.”

Most of us have a digital accumulation problem, mainly because the systems we use are designed to make storage feel free and infinite. Gmail has trained us to archive everything. Google Photos offers unlimited backups. Slack retains message history indefinitely on paid plans. Streaming services keep our watchlist and viewing histories going back years. The default is always to keep, to store, and to retain, and honestly that is because storage is cheap, and the cost of that cheapness is externalized somewhere we cannot see.

The average person’s email inbox contains thousands of unread newsletters, promotional messages, and automated notifications that are never opened and never deleted. Those emails exist on servers. Those servers use electricity. This is a small thing, but small things are what scale looks like from the inside.

Some concrete things that are genuinely not nothing:

Unsubscribing from emails lists you do not read reduces the number of automated messages being generated, stored, and delivered to your account. Deleting photos and videos you will never use (especially cloud-baked ones) reduces active storage. Streaming video at resolutions appropriate to your screen size (you do not need 4K on a laptop) reduces the amount of data required from content delivery networks. Losing browser tabs you are not using reduces the active compute load on your machine and, marginally, on the servers those tabs are pinging.

None of this will solve the problem, yes. The structural solutions are more upstream. The structural solutions live in policy, in how data centers are powered, in what standards we hold cloud providers to, in whether green software engineering becomes a professional expectation rather than a personal preference of conscientious developers. BUT the individual behaviors are worth naming because they correct the misperception that the digital world exists outside the physical one.

The design problem

I want to close with something that I think gets lost in a lot of sustainability discourse.

The reason most people do not think about the environmental cost of their digital behavior is not ignorance or apathy. It is simply the design. The interfaces we use are deliberately built to make accumulation feel effortless and disposal feel laborious. Signing up for a newsletter takes one click. Unsubscribing requires finding the link, waiting for the confirmation page, sometimes confirming a second time. Uploading a photo to a cloud storage happens automatically in the background. Deleting it requires you to find it, delete it, then go find the “recently deleted” folder and delete it again. This is intentional. Systems architects and solution engineers design this asymmetry because it serves the direct-consumer-business interests of platforms that monetize data storage and engagement. And it means that the idea that individual digital hygiene (“personal responsibility“ framing) is the solution, is doing a lot of work to cover for a structural design.

The more honest conversation is about what we should expect from the companies building these systems. We should expect them to default to energy-efficient infrastructure. We should expect them to default to energy-efficient infrastructure. We should expect them to pursue renewable energy procurement aggressively and transparently. We should expect software engineers to be trained in efficiency as a professional standard, not as an optional extra. And we should expect the companies that market themselves on their environmental commitments to be held accountable for the energy consumption of the products they ship.

Dark mode is fine. It is a reasonable preference. But the planet’s future is not going to be decided by your screen settings. Actually, it’s going to be decided by whether the systems powering your screen are built by people who treat energy as a real cost with real consequences, rather than an abstraction to be optimized away in the next fiscal quarter.

That’s more of a design question. And just know, the design questions have the real answers.

Her Code Kitchen

A publication all about cooking, coding, and making music where the recipe is the algorithm, the kitchen is the studio, and well, engineering is quite in everything.

Sources & References

1. International Energy Agency — Energy and AI (April 2025). Global data center electricity consumption and growth projections.

2. Purdue University — Y. Charlie Hu & Pranab Dash, OLED Power Modeling Study (2021). Dark mode energy savings research; also published in ACM MobiSys conference proceedings.

3. Pew Research Center — What We Know About Energy Use at U.S. Data Centers Amid the AI Bloom (October 2025). Virginia data center concentration and household cost impact figures.

4. Fortune — Doomscrolling Has Reportedly Made TikTok’s Annual Carbon Footprint Almost the Same as the Entire Country of Greece (December 2024). Reporting on Greenly’s The Hidden Environmental Cost of Social Media analysis.