Interviewing Bhupesh

📅️ Last Updated: November 17, 2024 

I help you interview me better. Here’s a list of questions that matter, with my answers, saving you the time to analyze how I think.

Disclaimers

  • This document is meant to be read by folks who take the final decision in hiring me & have an engineering background. i.e, Senior/Staff Devs, EMs, CTOs, Founders, etc. It would be great if you read this very early in the hiring process.
  • This is a live document, i.e the responses will change with time. If this was shared to you by me, assume it’s the latest version.

Questions

What makes you who you are today?

Reading & Writing, at least from a career POV. Both have had a huge impact on how I think and approach problems. I have been reading since I was a high-school kid, mostly fiction and non-fiction. I have been writing since 2019, mostly technical stuff.

I have a dedicated digital bookshelf, head over to bookshelf.bhupesh.me to see what I am reading at the moment & some of my personal recommendations.

What’s the best thing you’ve made without anybody asking?

ugit, well not exactly, people indeed asked for it. Till date its probably the most popular project I have made.

What’s the first thing you built? When and Why did you build it?

I think the first ever actual software I made was tutorialdb in 2017. Back then, I described it as a search engine for programming tutorials. The main motivation behind this to stop asking questions like “Can you share resources to learn ABC”. Now that I look back at it, it wasn’t a full-fledged search engine but more of a glorified link aggregator.

However, it did have indexing like capabilities, given a webpage URL it could detect whether it was a tutorial or not. It was built using Python and SQLite.

To be fair, the first thing I ever built was a simple calculator using Visual Basic 6.0 during my school days.

Can you build scalable systems or system design INSERT_FAMOUS_LIVE_PRODUCT?

No. “Scalable” for me means the “[Potential] Business” & “Team” is changing (in either direction), so we need to account for that in the engineering decisions we make. It’s not an exercise to put a bunch of boxes and arrows on a whiteboard.

Let’s talk about scalability once the product you work for is going through an exponential growth. However, I am eager to build stable systems.

So no, I cannot design a system for a product that scales to million magical users a day. If you see me doing (or talk about) this, don’t trust me.

Do you prefer working on coding projects alone or with a team?

Both, both is good. I require alone time to be productive solo, and I need a team to get things done faster. I am very much open to brainstorming sessions, pair programming, etc.

What sets you apart from other applicants for ABC position?

Nothing, honestly. I consider myself as an average human with average skills. I am not going to sit here gloat about things that can change your perspective. A lot of public stuff that I have, like my blog, digital garden, github justifies my skills & knowledge. If you disagree, you are free to reject. At the end of the day, hiring humans is basically a trust exercise.

Do you know how to use INSERT_DEVTOOL?

Probably not, I use tools to the extent it helps me get the job done. As much us devs cherish our devtools, I believe that we create problems for ourselves with each new tool we add to our stack.

If the tool you are talking about is something that is absolutely necessary for the job (like shit will go down if this tool didn’t exist), you can assume that I will learn to use it or adapt to it to a point where we can discuss it.

Do you know about INSERT_PRACTICE or INSERT_PRINCIPLE?

I might have heard about it, but I am not sure. I am not a big fan of practices or principles, However I am always reading, so expect a generic answer about the practice or principle. My work gets influenced by an amalgamation of real world experiences:

  • My failed attempts at introducing something new I learned at my workplace.
  • Tools & Practices the team at my workplace collectively decides.
  • Occasional FAFO (Fuck Around & Find Out) concepts.

How does an ideal codebase look like?

  1. Has unit-tests.
  2. Has monitoring data exposed (memory/CPU usage).
  3. Has tools in place to check for security vulnerabilities.
  4. Automated/Low-effort linting in place.
  5. Config files don’t exceed 1000 lines (don’t ask the backstory for this).
  6. Documentation is handled right inside the codebase in forms of “Diagrams As Code” i.e, Sequence & ER diagrams are checked into VCS.
  7. Makefiles (or related) setup to get ready with codebase in a new machine.

How often do you contribute to Open-source?

  • Rarely, I need strong motivations to help upstream. Either I get paid or I realize project XYZ doesn’t have something I require. If you combine both of these motivations, you can expect me to contribute to OSS when I work with your team.
  • I do however relate to the maintainer/author side of the ecosystem, having maintained a few projects of my own.

How good are you with Infra or DevOps?

  • Good enough to get the job done, given realistic contraints.
  • Not good enough to do it quickly or efficiently enough in comparison to someone whose career has been in these domains.

What are you working on right now?

This is documented on my now page.

More about me