Muhammed Gazali Yeşilmen @mgy_programmer

I’m building DevMarathon around this idea: evaluating developers through real software challenges. You can try it here: devmarathon.com

Many companies still rely heavily on resumes and a 30 minute interview to hire software developers. But I don’t think that’s a strong enough signal. What matters more is how a developer thinks, approaches problems, makes trade offs and works through real challenges. What do you think is the best way to evaluate a software developer?

@naval When everyone has a genius in the loop, intelligence stops being the differentiator. Taste, judgment, and the ability to tell great output from convincing mediocrity become the real edge

CVs and interviews don’t always show how a developer actually works. That’s why we’re building DevMarathon around real coding challenges, GitHub activity, and evidence-based AI evaluation. If there isn’t enough evidence, the AI doesn’t force a score. Real code. Real evidence. Better hiring decisions. devmarathon.com #devmarathon #technicalhiring #softwareengineering #ai #hiring

@paulg Maybe that's the real flex: no dramatic scaling, no chart gymnastics, just 8x growth 😊

@foundr Pressure doesn’t create culture. It exposes the culture that was already there. Same with founders.

@lightsilver323 Evaluation :)

This belief is actually one of the reasons I built DevMarathon. I think developers should be evaluated by what they can actually build, how they think, and how they execute, not just by what’s written on a CV. The AI era makes building more accessible than ever. So build. Ship. And create proof of what you can do.

A piece of advice for every software engineer and CS student: Build something of your own. It doesn’t have to become a startup. It doesn’t have to make money. It doesn’t even have to be perfect. But in the AI era, building products has become dramatically easier. If you’re employed, don’t let your entire career depend on one company. One day, you may leave, get laid off, or simply want something different. Having a product of your own gives you leverage, experience, proof of your skills, and optionality. If you’re a student, start even earlier. Use AI, experiment, ship products, fail, rebuild, and learn. I genuinely believe that in this era, no software engineer, computer engineer, or aspiring entrepreneur should be without something they are building themselves. Don’t just have a job. Own something you built.

@erenbali Eren, this is pretty much why I started DevMarathon. Seeing how someone actually thinks and builds through a real problem feels way more useful than trying to match their CV to the exact same job :)

@erenbali As the founder of Capilens, I have mixed feelings about this business idea 😂

For anyone curious, here’s the original Hacker News post from 2022: news.ycombinator.com/item?id=300119… What makes this story even more interesting to me is that the lesson isn't simply “keep going.” It's knowing what to keep and what to change. The product changed dramatically. The willingness to build, ship, listen, learn, and iterate didn't. That distinction matters a lot for founders.

In 2022, this was @cursor_ai. Not an AI code editor. Not a company redefining how developers write software. A Chrome extension that used AI to help people write emails faster. They shared it on @hackernews. The post got: 4 points. 5 comments. That’s it. Today, Cursor is one of the products shaping how developers think about writing software with AI. And I think there’s a powerful startup lesson hidden in this screenshot. We usually discover successful companies after the story has already become interesting. The product looks polished. The positioning makes sense. People are talking about it. Users are growing. Competitors are paying attention. Then we look at our own early-stage product and wonder: “Why doesn’t mine look like that?” Because we’re comparing our beginning to someone else’s later chapter. Cursor’s first idea didn’t have to be its final idea. Its first users didn’t have to be its final market. Its first product didn’t have to define the company forever. Your first product can fail. Your first positioning can be wrong. Your landing page can be terrible. Your launch can get almost no attention. You can post on Hacker News and have only a handful of people care. None of that necessarily means the game is over. One of the most valuable skills in entrepreneurship is not staying blindly loyal to an idea. It’s staying committed to learning long enough to discover what actually deserves to be built. Build. Ship. Watch. Learn. Change direction when reality tells you to. Then ship again. People sometimes talk about “pivoting” as if it’s a nicer word for failure. I think it can be the opposite. A good pivot is a founder choosing reality over ego. And this screenshot reminds me of something early-stage founders forget too easily: The current version of your product does not determine what the company can become. Maybe 10 people use it today. Maybe nobody shares it. Maybe your launch goes nowhere. Maybe six months from now the product looks completely different. That’s okay. Your job is not to predict the future perfectly on your first attempt. Your job is to learn fast enough to stay in the game. Sometimes the thing that feels like failure isn’t the end of the company. It’s just Version 0.1. So maybe the better question isn’t: “Did this idea work?” Maybe it’s: “What did this attempt teach me that makes the next version better?” Looking at this old Cursor post, that’s what stands out to me most: Never underestimate what a small, imperfect first version can become after enough iteration. A lot of companies that look inevitable today once looked like tiny experiments that almost nobody noticed. Keep building.

@1nkfy @Elijah1473589 @getneurofocus Good luck guys

@fin465 AI compressed the cost of getting to “does anyone care?” But it hasn’t compressed the need to actually talk to users. At least not yet :)

@StartupArchive_ It’s easy to mistake acquisition for progress when the retention curve is still telling you the product isn’t sticky yet. More traffic just makes that truth arrive faster.

Building a product changes the way you read feature requests. At first, every request sounds like a feature to add. Later, you start asking what problem produced the request. Sometimes the best implementation is a new feature. Sometimes it’s deleting one step from an existing flow.

AI-assisted coding is making me rethink what “I know this” means. If I can recognize a good solution after an agent writes it, that’s useful. But it’s different from being able to design, debug, and explain that solution without the agent. I’m trying not to confuse the two.

The more I think about developer evaluation, the more interesting scope decisions become. Given the same deadline, one developer may cut the right feature and deliver a coherent product. Another may attempt everything and leave the core flow fragile. Both can write good code. Only one managed the constraint well.

A product can work exactly as designed and still have the wrong definition of “success.” A user clicking “Start” looks like activation. But if nothing happens after that, it was just a click. I’m learning to define product events by the behavior they predict, not by the buttons users press.