DEV Community: Srinivas VJ

Surviving the Technical Interview

Srinivas VJ — Tue, 21 Jul 2026 19:11:08 +0000

Coding interviews are scary, especially in the age of LLMs, where cheating has spiked and interviewers are implicitly sus of every movement you make. I wanted to write about my experience with coding interviews. Am I really qualified to write about this? Well, obviously not, my success ratio isn't great. But I've got some experience under my belt (13 coding interviews so far in my relatively short career), and I wanted to jot down what actually works for me.

Preparation

Figure it out. The technical prep you need varies drastically by level and company, and I have no interest in covering that here.

The preparation I do want to talk about is mental. What do you do on interview day when everything you learned suddenly feels obsolete, and your brain just goes, "Fuck, what do I do?"

Performing Under Pressure

This is probably easy for you if the interview is low-stakes, you don't really want the job, or you're the NeetCode guy.

What I struggle with more than the technical part is staying calm. I easily enter panic mode no matter how solid my technical prep is. The goal is to remain composed and be in top mental shape to perform. Here are the essentials I focus on to give it my best shot:

1. Allocate Prep Time and Be Ready

Make sure you have ample time before the interview to prepare not just your environment, but your mind. Block out the time. Even if you think you have nothing to do, you'll find something that gets you better prepared. I keep a two-hour buffer minimum. (If it's an in-person interview, don't show up two hours early—that's just weird. I'll focus on remote interviews here since they make up the majority of my experience.)

You never know when your webcam will decide to stop working, your headphones will refuse to connect to Google Meet or Zoom, or your Wi-Fi will ghost you. Ensuring your setup is dialed in and familiarizing yourself with the tools you'll use will definitely help keep you grounded.

Drink enough water. Even a 1% drop in hydration is linked to measurable declines in cognitive performance, mood, and mental clarity. Just time your hydration properly so you aren't fighting a full bladder mid-interview—that will absolutely wreck your focus. Keep a water bottle nearby. You'll definitely need it, and taking a sip is a great silence filler when you need a second to think.

2. Clear Your Mind

I like to meditate beforehand. It clears my head, at least for a bit. What I've also found incredibly helpful (courtesy of my sister) is journaling. Jot down what you're feeling and get it out of your head. It's a powerful practice—putting worries on paper or a screen gives you a sense of peace. Plus, if you're having crazy, fictional anxieties about worst-case scenarios, seeing them written down makes them seem a lot less believable. I highly advocate for both meditation and journaling. If you catch yourself stressing out, try the physiological sigh. It's scientifically shown to immediately reduce anxiety by activating the parasympathetic nervous system.

3. Remember

Whether you prepared or not, if you skipped DP cause it was hard, you had 2 hours of sleep, you didn't have time to meditate or journal, and you have your interview in 10 minutes—doesn't matter. It's not going to help worrying about how unprepared or unqualified you feel for this interview, or what you could've done better. It's all done and in the past, right now, all you can do is, make the best use of the ability you currently have.

"Do what you can, with what you have, where you are."

You can't control if the interviewer is going to be on time or 20 minutes late, if you control the question he/she is going to ask, you can't control the mood of the interviewer, you can't control the difficulty of the problem, you can't control your network, or even your mic not working, or the interviewer not showing up. All you can control is how you respond to these situations. You can either panic and crumble, or acknowledge that things can go wrong and accept whatever the situation is. You've got to be calm no matter what happens.

4. It's Show Time

Make sure you've prepared a good introduction that clearly represents you. Give them a smile to show them you're human.
I liked the excerpt from "Cracking the Coding Interview" on this, so I'll use parts of that here.

REMEMBER: Interviews are supposed to be difficult. If you don't get any answer immediately, that's okay! That's the normal experience, and it's not bad.

You're not an LLM that spits out the optimal solution in one prompt, you are bound to make mistakes, miss things, get stuck, give suboptimal solutions—it's normal.

During problem solving:

LISTEN CAREFULLY — Make sure you heard it correctly, and ask questions if you don't understand any part of it. Record unique information about the problem. While solving, ask yourself if you've used all the information in the problem. If possible, write down key points as comments so you don't forget during implementation.
RUN THROUGH EXAMPLE — Either the existing one or create your own that tries to cover a broader range of test cases.
BRUTE FORCE — State a brute force solution even if it's obvious, so that the interviewer knows you're at least capable of coming up with the brute force approach. Explain space and time complexity.
OPTIMISE — Steps:
1. Look for unused information in the problem.
2. Try using a fresh example—might give you a fresh view.
3. Think about best conceivable runtime.
WALKTHROUGH — Walkthrough the algorithm, solidify the implementation details. This is crucial as the clearer you are here, the smoother the implementation.
IMPLEMENT — Write beautiful code to showcase your ability. Write modularised code.
TEST — Mentally compile and run the code once on an input, identify flaws, fix the root cause and not the immediate fix, look at the issue at a deeper level.

Don't just code, explain your thinking as you go and treat it as a conversation. And don't rush into implementation. Yes, the interview is time bound, but unless you're sure your approach is correct and have a clear picture of what the code will look like, jumping straight to implementation will cost you more time than it saves.

If you need a minute, just ask: "Hey, can I get a moment to think about this?" The interviewer will almost always say yes, and now it's not awkward silence, it's silence you have permission to use.

Hopefully, you've managed to do your best (that's all you can ask for). To leave a strong impression, ask a good question at the end. Prepared questions are great, but if something genuinely interesting came up during the chat, ask about that.

Once it's over, hope for the best, prepare for the worst, and move on to the next one.

Why My Portfolio Website Still Doesn't Exist

Srinivas VJ — Fri, 03 Jul 2026 18:36:16 +0000

I've noticed something about myself. It's become much harder to get things done. I see less movement compared to my previous self. And sometimes, when I see people get so much done, tasks, projects, anything, I wonder why I can't make progress like that. Now I'm not comparing myself to Elon Musk here, I'm just wondering if I'm doing my best.

For the longest time, I've wanted to build a portfolio website. But for some reason or another, I never actually ended up making it, or should I say, starting it. Whenever I had a free block of time, I wouldn't know where to start. I also have this side project I've been wanting to work on. I started it, then never made any more progress beyond the initial feasibility analysis. Why did I never allocate time to either?

The Overthinking Starts Early

I wanted the portfolio website to be really good. I wanted cool additions, beyond the usual "about me" and "projects" sections, I wanted things like "songs I'm obsessed with right now" and "last night I slept at." I was also looking if my fitbit has an API to show my live heart-rate on my portfolio (why would someone do that?). I was obsessed with the features, and with using the right tech to make it as efficient as possible. What stack should I even use for a portfolio?

Same story with this very blog. Before writing a single word, I was wondering what stack to use. I looked into a ton of existing blogs for inspiration, how do I track views, what about comments, how do I stop a DDoS from flooding my DB if I'm storing comments, should I require auth just to leave a comment, should I support font and background color changes, themes, what's the best tool to do all of that?

I've noticed this pattern with almost everything I do. I'm so obsessed with doing things right on the first attempt that I never actually make the first attempt, because "doing it right" is just too demanding. Or a related trap, when I want to do something perfectly, I discover prerequisites, and those prerequisites chain into more prerequisites. Let me show you what I mean.

Circus Maximus

My task was simple, apply for jobs.

Let me head over to LinkedIn and apply to jobs.

Wait. Manually search and click through job after job, only to realize half of them want 7 years of experience? I'd have to read every single description just to know if it's worth applying to. Hell nah. I should automate this.

Let me figure out how to automate this with AI. Oh, there's this tool, n8n, I can build a workflow and hook it up to an LLM. Let me set that up.

All set. Now I just need to scrape the jobs from LinkedIn.

Crap. LinkedIn has strict bot filtering and rate limiting. It doesn't allow scraping. What's a reliable way to get LinkedIn job data?

Five hours of searching later... fine, let me just pay Apify to pull the listings.

Five minutes of being ready to pay later... wait, WHAT, no. I'm an engineer. How am I about to pay someone to scrape an API that already exists? What a failure that would be.

Fast forward 10x. The workflow is finally set up. But wait, I can't run this on my Mac Mini forever. I need to host it. Let's grab Oracle's free VPS tier.

The free tier is in high demand, I can't get one. Only option is to upgrade to pay-as-you-go. Fine, I'll do it, I won't actually get charged anyway. My card gets declined. Let me raise a support ticket.

Fast forward 15x. (International transaction issue, fixed.) Yay, VPS is live. Now let's host n8n on it. Three hours of configuring a reverse proxy, grabbing a free domain, and setting up ingress rules later, voilà, n8n is hosted and the workflow is running.

But wait, I was using free open-weight models, and they have brutal rate limits too. What's a model with generous limits? Screw it, let's use Gemini Pro. Quota exhausts almost instantly. Screw it, let's get a Claude subscription. Okay, that finally works.

Finally. Let me apply to these jobs now.

...Wait. Are these LinkedIn job links even any good?

(they were not)

I learned a lot on that adventure. I also realised I might be doing something deeply wrong.

Enter the Yak

Then I came across the blog [Don't Shave the Yak](https://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_the.html)_, whose idea is simple. The example given goes something like this.

"I want to wax the car today."

"Oops, the hose is still broken from the winter. I'll need to buy a new one at Home Depot."

"But Home Depot is on the other side of the bridge, and getting there without my EZPass is miserable because of the tolls."

"Wait! I could borrow my neighbor's EZPass..."

"Bob won't lend me his EZPass until I return the pillow my son borrowed, though."

"And we haven't returned it because some of the stuffing fell out, and we need yak hair to restuff it."

And the next thing you know, you're at the zoo, shaving a yak, all so you can wax your car.

Sounded painfully familiar. One line from it has stuck with me since.

Doing it well now is much better than doing it perfectly later.

And maybe one more line to sum up the whole tendency.

"Only limitations you'll ever have, are those that you place upon yourself." ~ some Kendrick song

Realising I'm a Perfectionist (Surprise)

This made me notice the pattern everywhere, and made me aware of my own tendency to want things done as perfectly as possible. I was familiar with the word "perfectionist," I just never thought it applied to me, because my results are never actually perfect. (I'm aware that assessment is, itself, a very perfectionist thing to think.)

Looking back, I realise how ridiculous I was being. For this blog, I was genuinely debating Astro versus other frameworks, agonising over rendering MDX just right, and researching how to DDoS-proof a comments database, for a blog with zero readers. No, scratch that, for a blog that didn't even exist yet.

I started to fear something. What if my perfectionism is just fancy procrastination? Is this all an elaborate excuse my monkey mind (shoutout Wait But Why) invented to talk me into doing something easier?

But then again, is wanting to do things correctly (or, fine, perfectly) actually a bad thing? Maybe wanting to do things well isn't the problem. So which is it, strive for perfection on the first try, or just raw-dog it and see what happens?

The Quantity Group Wins

In Atomic Habits, James Clear tells a story about photography professor Jerry Uelsmann. Uelsmann split his class into two groups on day one. Half were in the quantity group, half in the quality group.

The quantity group would be graded purely on volume. On the last day, Uelsmann would simply count how many photos each student turned in. More photos, higher grade. The quality group would be graded purely on excellence. One photo, submitted at the end of the semester, could earn an A, but it had to be nearly flawless.

The result was surprising, and also not surprising at all. Every single one of the best photos came from the quantity group.

Makes sense once you sit with it. The quantity students were out shooting constantly, experimenting, failing, adjusting, learning. The quality students spent the semester theorizing about the perfect photo, and most of them had exactly one mediocre print to show for it by the end.

So Maybe...

Maybe the first version of my portfolio doesn't need the perfect stack. Maybe the blog doesn't need comments on day one. Cutting the ambition down for the first attempt might be exactly what gets me started, and having something real, even something small, might give me the dopamine hit to keep going, instead of stalling out chasing one perfect, mythical final version.

Maybe my project never becomes "perfect" and just settles at "good enough." That's still infinitely better than the project that never existed at all, right?

Good enough is good enough.

There's also a nagging voice that says, if I have to go back and change something later, because I made a bad call early on, isn't that just repeated work? Partially true. But going back to fix something isn't repetition, it's iteration. You don't build something, learn nothing, and rebuild it identically. There's feedback each time. Each pass gets better because of the last one.

Every time I get cautious about making a mistake and freeze up in analysis paralysis, maybe the actual move is to just accept that mistakes are coming, and iterate through them. Maybe that's where the real learning happens anyway.

Just Do It

So if you're thinking about doing or building something, don't wait until you have all the knowledge, and don't wait until you know exactly how to do it best.

Just do it. (shoutout Nike)

And I absolutely did not send this draft to Gemini, Claude, and GPT at the same time asking them to spellcheck and critique it, even though I know damn well only two of my friends are ever going to read this. (I did.)

I wanted to throw in a dozen more examples to really convince you and myself, to stop chasing perfection. But I'm going to follow my own advice for once and end it here.

Until next time, my fellow fancy procrastinators.