MVP mindset hurts me at job interviews, lol

Some business would love for you to have that mindset. If it hurts you in a Job interview, maybe that Job is not a good fit for you.

They're not all the same, but interview for smaller start-ups I think they're more likely to appreciate someone who has the whole business in mind.

Your experience is correct. I struggled with finding a job in bigger companies and couldn’t wrap my head around it for a long time. A lot of comments here have the right ideas but I want to add my 2 cents as well.

I’ve interviewed with hundreds of companies of different sizes. It ranges from super early-stage startups to FAANG companies. What I can tell you is that people often want a product-oriented engineer. They want someone who cares about the product and has skills beyond a typical technical role. What they don’t want is a quick & dirty MVP person. Because at the end of the day, dozens if not hundreds of people will have to maintain that bad code. And if something goes wrong with that code, It will likely cost the company more than your annual salary. That’s why they don’t mind spending an extra week on creating a better technical solution with unit tests and whatnot.

I don’t know the companies you interviewed with but if there are, say, more than 100 engineers in that company working on the same product, it becomes much more important to be able to scale the engineering organization through good code and good architecture. Because that’s how companies go faster these days. An engineer spending a month on a task instead of a week doesn't hurt them, because they have hundreds of engineers. Multiple features are being delivered simultaneously and have to be A/B tested. It’s better to test a robust feature one month later than to do it today and risk messing up all the other tests. Because then it becomes a real-time loss for a lot of people.

I think your heart is in the right place. I suggest you find a middle ground between the mindsets and consider their mindset as a learning experience if you want to get one of those jobs.

You can't come in and teach business to someone managing a business. Sometimes it can be perceived as offensive. If you are being hired as a developer you should behave as such.

I'd kill to have somebody with your mindset interview with me. All I get are developers very with very narrow perspective who would spend happily weeks on optimizing a 4 KB bundle size reduction for a frontend. I'm not saying that those developers are bad, but some companies like the one I work for are searching for people who can deliver, not people who just write code.

I am sure you will find a company who will value your mindset and skillset. Maybe a lower seed level startup?

I have a similar theory: https://www.karllhughes.com/posts/farmers-pioneers

Some engineers are "pioneers" who get shit shipped and create starting points. Others are "farmers" who cultivate and optimize existing codebases. Most of us sit somewhere in the middle.

While you can learn to be more one way or the other, you'll find the most success in jobs that need your strengths.

" this will likely break at some point, but even it if breaks, the main business flow will not be affected"

LMAO. The balls on you to actually say this out.

But we SaaS entrepreneurs know this to be a fact.

It can be stitched together with duct tape, but, as long as it "basically" works, your MRR could be increasing month after month.

That said. I'm working on a full-site code refactoring right now to make things smoother -- it's all under the hood, but it's a long-term investment when things get bigger and potentially out of hand!

To play devil's advocate here someone in a hiring position may interpret your answers differently (I realize you might just be paraphrasing so everything I say might not apply).

I want to be clear that I'm not attacking your thoughts or even saying you're wrong. However, from a different point of view perfectly valid ideas can be taken the wrong way.

yeah, this code is not optimized, but unless we have traffic like Amazon, this will not be a problem

This could sound like "I know I could write this code better, but I don't feel like and I can just tell you that it's not a problem." I haven't met very many people that can look at a piece of code and tell you if it needs to be optimized. It always depends on a variety of factors like how often a piece of code is run or if it's a user interaction or nightly process. From a hiring perspective, I'd probably rather hear something like "I know this code could probably be optimized better, but I think this is a good place to start until we can profile it and understand the implications.

it's a dirty solution, but it will work and we can develop this fast

This might sound like "I like taking shortcuts and can't be bothered to think about the long term implications." If I thought you meant that and it's an established business I'd be pretty unhappy. Dirty solutions cost me a lot more money over the next couple of years than a well thought out solution now. Of course, if I wanted to hire you to build an MVP I'd probably love that answer.

this will likely break at some point, but even it if breaks, the main business flow will not be affected

Someone might take this as "I write bad code and it breaks". However, if they did then you don't want to work for that person anyway. Everyone's code is going to break at some point since software is never done. To me, this is just showing good awareness. It would probably be beneficial to follow it up with some idea on how you'll know when it does break so you can do something about it. Unknown bugs are worse than known bugs.

Developers want to have the perfect code. Entrepreneurs want to get things done quickly and long term consequences aren't as much of a problem. Hiring managers will lie somewhere in between based on the company, their experiences, and biases. I also think the software interview process is completely broken, and a terrible predictor of how good someone will be. People in the process will most often have to play the game somewhat to make it through. That's one of the main reasons I'm an aspiring indie hacker.

Interesting post. In my experience startups look for the MVP mindset in product managers / product owners. They look for engineers who can build scalable software - even if the startup is tiny.

I've totally been in your shoes! As others have said, the contrast between what early stage startups and well-funded startups/big corporations look for in a developer is enormous.

It would seem that developers who only show proficiency in one or the other - being business oriented vs deeply technical - are only useful in the fringes: early stage startups where everything is quick n dirty or later stage companies where engineering specialization and quality takes priority over fast movement and experimentation.

My visualization of "the perfect candidate" is someone who is able to show off their business mindset and technical prowess in parallel by suggesting/implementing multiple solutions to a problem, explaining for each solution the context that would call for it.

"My first approach would be a solution like THIS. It's dirty, but it will work and will allow us to iterate quickly ... Once the feature is proven and we care about speedy performance, I would rewrite it like THIS ... As we begin to scale, memory consumption could become an issue, so to optimize there I'd iterate to an approach like THIS" etc etc :)

When hiring, a company usually looks for the best professionals who are best fit for the specific role.

The company you interviewed may look for a hard core developer very specialized in some skills. In large companies, the trend is more obvious

Lean startup or whatever startup mindset is of no value to the company.