Interviews Suck, But Here We Are
I’ve been through hundreds of interviews. I’ve given around 40 myself. I’ve seen it from both sides and let me tell you, it’s a mess.
Some interviews were smooth, some were awkward, and a few were downright painful. Same goes for the ones I ran myself. But after doing this for years, across different teams, stacks, and roles, I’ve picked up a few things worth sharing.
This isn’t going to be some generic list of tips like “practice whiteboarding” or “dress smart.” You’ve got enough of that junk floating around. I’ll just share what’s worked for me, what I’ve noticed over time, and where the process often breaks dow, both as a candidate and as an interviewer.
Maybe it helps someone. Maybe it just helps me reflect a bit. Either way, let’s start at the beginning: getting your foot in the door.
Getting Your Foot in the Door
This part’s all about step one, getting noticed, landing that first call, and giving yourself the best shot before the interview even starts.
Build a portfolio that speaks for you
Whether it’s your own apps, open source contributions, Medium posts, public talks, or even side projects no one ever used , build and share your work. Over time, it stacks up. A good portfolio saves you from having to explain everything. It shows people who you are and how you think before you even speak.
It doesn’t have to be perfect. It just has to exist and be maintained. My best interviews often came from people who already saw something I built or wrote. Makes the whole process smoother.
Check if they even looked at it
This is a personal one. If your portfolio means something to you, ask if the interviewers looked at it. If they didn’t, that’s already a small red flag for me. It shows they might be box-ticking instead of actually hiring humans.
If you care about what you build, you want to work with people who care enough to check it out.
Go to meetups or conferences (yes, even awkwardly)
Networking is underrated. Start small, maybe one or two events a year. Meet people. Talk about Android, tech, or whatever else is going on. Not only can this lead to job opportunities, but it helps you get better at talking about your work, sharing ideas, and just being more confident in uncomfortable situations. It’s a good leadership muscle to build.
Don’t obsess over your CV
CV advice on the internet is a black hole. I won’t add to the noise. Just keep it simple, honest, and easy to read. That’s it.
Short cover letters actually work
I noticed I had better luck when I wrote short, direct cover letters. Just a few lines that show I actually looked into the company. Downloaded the app, used it, maybe even reverse engineered it a little. You’d be surprised how many companies respond well to that effort.
Research the team and the product
Before applying, I dig a little. Who’s on the team? What’s their background? Is the product something I’d use or find interesting? It helps me filter out the noise and focus on two things I care about most: the team and the project.
I’ve joined teams just to work with certain people. No regrets. Good people make everything better, even messy codebases.
Project quality used to be a dealbreaker for me, not anymore
I used to be picky. Clean architecture, modern stack, the whole thing. These days, I’ve learned to let go. I still care about simplicity and writing good code, but if the team shares that mindset, even if the current codebase doesn’t, that’s good enough for me. It’s about where it’s heading, not where it is today.
Culture > Code
Give people space to speak. Let them have their word. Share your thoughts, but don’t bulldoze. I’ve learned to let others try their ideas, even when I disagree. And I’ll support them fully. If they’re wrong, they’ll learn. If I was wrong, I’ll learn. Tech changes. People matter.
Take-Homes, Red Flags & The Application Process
Once you’ve made contact, the real circus begins. Tasks, emails, interviews, sometimes a coding challenge that eats your weekend. This part’s about knowing where to push forward and where to walk away.
Take-home assignments: only when worth it
I’ve done plenty of them. Some were great, others were just companies trying to get free work. These days, I only bother if the task is actually interestin, something that lets me learn or go deep into a topic I haven’t explored yet. Otherwise? No thanks.
If they’re stubborn about it being “required” for fairness, that’s a red flag. Usually means they’re rigid about other things too. Flexibility is important. If a company can’t budge at the interview stage, imagine how it’ll be once you’re in.
What I look for in a company
Two things:
- The team
- The project
That’s it. If I get along with the team, everything else is fixable. Good communication, shared values, a bit of humor that goes a long way. I’ve literally taken jobs just to work with specific people I respected. Always a good move.
As for the project, I like working on stuff I’d actually use. Or at least find interesting. But I’ve also taken on some boring products if the team made it worth it.
Experience over trivia
I don’t retain every detail I read. I forget how String works internally. I don’t care about memorizing coroutine internals. But I’ve worked on over 20 projects. I know what shipping code looks like. I know how to work in a team. I know how to spot bad patterns and fix them.
If an interview leans heavily into “gotcha” trivia, that’s another red flag. The goal is to find a good developer, not a walking Kotlin reference doc.
The shortcut nonsense
One interviewer told me that using keyboard shortcuts in Android Studio is “a strong sign of experience.” I’ve been programming for nearly a decade across almost every platform and IDE. I barely use shortcuts. Old habit, maybe. But I’m fast. I ship. I fix problems. If that’s a dealbreaker, then we’re not a match. Simple as that.
Live coding is broken
I hate live coding interviews. Watching someone fumble through a task while being judged in real time is not a useful signal. It’s stressful, it’s awkward, and it doesn’t reflect how real dev work gets done.
If you’re hiring for a remote position where 90% of the work is async and solo, then why are you watching people type with three faces staring at them on a Zoom call? Makes no sense.
That said, I get that companies need filters. I’ve worked with devs who barely knew how to code. But there has to be a better way than live coding or cookie-cutter take-homes.
If someone has a strong portfolio with working apps, writing, and open source work, then trust that. Give them a chance to explain what they built. Don’t treat everyone like they’re lying. Let’s bring back some trust.
The Interview, It’s a Two-Way Street
Most people treat interviews like an exam. I don’t. It’s a conversation. I want to find out if I want to work with them, just as much as they want to find out if they want to work with me.
It’s not just about answers, it’s about questions
Some of the best feedback I’ve gotten was because of the questions I asked, not the answers I gave.
Questions like:
- What’s the test process like?
- Do you use any code quality tools?
- Is security or accessibility something you care about?
- How often do you do releases?
- What’s the team structure like?
- Do designers and devs actually talk to each other?
Not only do these help me figure out if this is a good place to work, but they also show them that I know what I’m doing and that I care about more than just writing code.
Don’t buy the brochure
I’ve had interviews where they sell you on the company, the team, the app. You sign on, only to find out everything they pitched was nonsense.
The app is a mess, the culture is toxic, and the roadmap is just a bunch of Jira tickets nobody understands. That’s why I ask real questions. If they can’t answer them honestly, I already know how it’s going to be.
I’m not here to perform, I’m here to talk
I’m not trying to impress anyone with fancy talk. I speak the way I code, clear and straight to the point. I’ll happily talk about my past work, share what I learned, how I’d do things differently today.
I’m also open about what I don’t know. That’s not a weakness, it’s a reality. Nobody knows everything, and pretending otherwise is just ego.
Watch how they behave too
It’s not just about your performance. Watch them. Are they on time? Are they engaged? Did they read your CV or portfolio?
If they seem distracted or didn’t bother to look into your work, that’s a red flag. If they keep cutting you off or acting like they’re testing you, not talking to you, red flag. If you mention something you’re passionate about and they don’t even react, red flag.
Good interviews feel like a back-and-forth. A bit of tech, a bit of shared stories, some laughs. That’s the kind of team I want to work with.
When I’m the One Interviewing
After going through hundreds of interviews myself, I’ve also been on the other side of the table, interviewing around 40 people over the years. And let me tell you, that experience is just as revealing.
The goal is simple: make it human
My top priority when I interview someone is to make them feel comfortable. I want us to talk like devs, not like a judge and contestant. No performance. No intimidation. Just a chat about what we both love, building stuff.
I’ve had candidates visibly relax after 2–3 minutes just because I treat them like people, not some threat to the team’s “bar.” That helps both sides get a more honest read.
No portfolio? No problem, but then I go deeper
Not everyone has a public repo full of projects, articles, or talks. That’s fine. But if there’s nothing to go on, I ask more technical questions just to understand how they think, what their experience level is, and how they approach problems.
I’m not looking for perfect answers. I care more about their reasoning, curiosity, and humility. If someone says, “I’m not sure, but I’d look it up like this,” I respect that a lot more than someone pretending they know everything.
Interview != Trivia Quiz
I’ve been in interviews where I got grilled on String internals or forced into a coroutines black hole. None of it felt like stuff you’d actually need in your day-to-day. Guess what? I bombed those.
And I don’t do that to candidates. I’m not here to play “gotcha.” I’m here to find out if you can work with us, think critically, ask the right questions, and write good, clean code when needed.
If you want to see how someone works, read their work
If someone has a blog, open-source repo, or personal app? That tells me 10x more than any algorithm test. I’ll spend time reading through that and ask questions about it.
Not because I want to nitpick, but because it’s a better conversation starter than asking someone to build a shopping cart from scratch under pressure.
Let people grow, even if they’re wrong
When I don’t agree with a candidate’s approach, I’ll usually let them talk it out. I’ll ask questions. I’ll challenge gently. But if we hit a deadlock, I don’t need to “win” the argument.
Sometimes I’ll even say, “Cool, go with your approach, let’s see what it looks like.” If it works, I learn something. If it doesn’t, that’s fine too, we both learned.
That’s how I work with teams too. Support first, correct later (if needed). People remember that.
The Interview Tasks That Waste Everyone’s Time
Let’s talk about the “evaluation” phase, where a lot of companies show their true colors.
Take-homes: love–hate territory
I used to be okay with take-home assignments. I’ve done a ton. Some were actually fun, I learned things, tried out patterns I’d been meaning to, even reused parts for future projects.
But I’ve hit a point where I’ve built enough and shared enough that I don’t feel the need to do them unless:
- It’s really interesting
- It’s a deep dive into something I haven’t played with
- It feels like a genuine two-way thing, not just free work
If you’ve got a portfolio, articles, apps, whatever, you’re not “skipping the line.” You’ve already done the work. If a company insists on “fairness” by making everyone do the same take-home, even if your public work proves your skills, that’s a red flag for me.
“Fair” isn’t making everyone jump through the same hoops, it’s adjusting based on context.
If they’re rigid here, they’re probably rigid elsewhere too. Trust me, that’ll show up in code reviews, deadlines, and process. Pass.
Live coding challenges are garbage
If there’s one thing I despise in interviews, it’s live coding. Especially when:
- You’re asked to code something trivial
- While being watched by 2–3 people
- On a call
- In a totally unnatural setup
- While they silently judge every keystroke and facial expression
That’s not how we work. That’s not how anyone works. Especially not remotely.
You wouldn’t stand behind your teammate at their desk, arms crossed, watching them try to implement a RecyclerView adapter from scratch with zero help. But somehow in interviews, it’s fine?
I’ve been doing this for nearly 10 years. I don’t have every keyboard shortcut memorized. I don’t care. I’m still fast, I still ship great code, and I don’t need to pass some twisted version of a school exam to prove that.
It’s lazy filtering. If the company doesn’t trust their own judgment based on your past work, conversation, and vibe, they’re probably not worth your time.
Make some damn leeway
I get it. Bad hires are expensive. Nobody wants to get burned. But you know what else is expensive? Losing out on solid people because your interview pipeline is designed to weed out everyone who doesn’t thrive under pressure.
I’ve worked with devs who could barely write a loop, and I’ve worked with brilliant people who just couldn’t deal with the test circus. It happens.
So here’s a radical idea: If someone has real work out there, apps, open source, content, a track record, use that. Trust a bit more. Talk like humans.
Getting Better at Interviews (Without Turning Into a Robot)
There’s no shortcut here if you want to get better at interviews, you just need to do more of them. That’s it. Each one teaches you something: how to present yourself better, what kind of questions to expect, what you should be asking, how to tell when something’s off. It’s a skill like any other. And it compounds.
Ask more questions than you answer
This one’s underrated. One of the best impressions I’ve ever left in interviews had nothing to do with how I answered their questions, it was about what I asked them.
Smart questions show:
- You’re experienced
- You care about the team/product/process
- You’re not desperate, you’re evaluating them too
A few of my go-to questions:
- What’s the testing process like?
- Are you using any code quality tools?
- Is security a big topic for you?
- How much time is allocated to refactoring/tech debt?
- What does the onboarding look like?
- How do code reviews work?
These aren’t just checkbox questions, they spark real discussions and often reveal a lot more about how the company works day to day. And they show that you’re thinking beyond your IDE.
You can also flip this: ask questions based on your strengths. If you care about accessibility, ask how they handle it. If you write articles, ask how knowledge sharing is done internally. Show who you are by what you care about.
Also, verify what you’re walking into
You’d be surprised how often people sugarcoat the app, team, or process. I’ve been sold “greenfield Kotlin project” only to find a Java codebase duct-taped together with zero tests and a three-week sprint backlog of legacy bugs.
So yeah, ask. Push gently. Do your research. Look into the team. Download the app. Reverse engineer it if you’re into that kind of thing. If something feels off, it probably is.
It’s a two-way street
You’re not there to beg for a job. You’re there to find out if it’s a match. Don’t forget that.
Don’t be afraid to walk away if something doesn’t sit right. Whether it’s the process, the team, the product, or just your gut telling you no, listen to that.
And on the flip side, if you feel like you clicked with the people, and they seem motivated and sane, that can outweigh a lot. I’ve taken jobs just to work with specific people. Never regretted it.
Your Interview Story Matters Too
Looking back at all these interviews, the good, the bad, and the downright weird, I’m glad I went through them. Not because they were fun (they weren’t), but because each one gave me a clearer idea of what I value, what kind of team I want to be part of, and how I want to show up as a developer.
It’s easy to get stuck thinking you have to follow someone else’s formula: nail the algorithms, memorize trivia, act like a machine. But that’s not what this is about. We’re all human, and interviews should be a way to find good matches, not just filter out people who fumble under pressure.
If there’s one thing I’d say to anyone going through this process: build your own path. Try different things. Reflect after each round. Keep a little journal if you have to. And don’t be afraid to turn things down.
Now I’m curious about your experience. What’s worked for you? What drove you crazy? Any moments that made you realize, “Yeah, this ain’t it”, or ones that made you think, “Damn, I want to work here”?
Drop a comment, write a post, share your own take. We need more honest, unfiltered stories about what this side of the dev world really looks like.
Let’s make the interview process suck a little less, together.