I’ve worked in startups with different management and product development styles.

With mandatory reports and without them.
With task trackers and without them.
With required office presence and fully remote.
With long-term planning and decisions made on the fly.

Often processes develop around a leader’s idea of what normal work should look like. Some find offices, reports, and tight syncs natural. Others deliberately choose remote work, flexible schedules, and asynchronous communication. Breaking the system into many independent parts might seem like the only healthy path even early on. Keeping everything in one codebase might seem like the only way to move fast. These beliefs are fueled by past projects, positive outcomes, and success stories they’ve observed. Each genuinely believes their setup is normal and can list dozens of reasons why their approach is right. That’s why changing these views is hard.

Different ways of working become different worlds, and each world seems uniquely stable to those within it. But no management or product development style guarantees survival or failure.

When I worked as a developer and team lead, I went through a lot of interviews. Over time, I built up a list of odd and unhelpful questions. There were many, but here are the ones that stood out the most. I’m not trying to guess what the interviewers were thinking. I’m just showing how these questions sound in conversation and the impression they leave.

The Quirky Ones

• What’s your favorite color and why?
• What animal do you associate yourself with?
• How would you describe your perfect day?

These questions sound unusual, but they don’t tell you anything about how a person works. The answers are wide open to interpretation, so the focus shifts from real experience to guessing the right image. A candidate either recites something they’ve prepared or improvises a response, and neither option says much about how they approach problems. It’s hard to draw any conclusions about work behavior or decision-making from answers like these. More often than not, they add noise rather than help with evaluation.

Passive-Aggressive Traps

• Aren’t you worried you won’t keep up with our pace?
• Don’t you think you might be overqualified for this role?
• How do you explain the long gaps in your career?
• How much were you making before?

These questions often feel like an attempt to uncover a hidden problem. They focus less on professional experience and more on external circumstances, which rarely help you understand how someone will work in a team. This stands out even more in startups. A person’s past salary doesn’t reflect their current motivation or expectations. A long career break might have nothing to do with competence. And a concern about being overqualified means nothing without context about the role. It’s easy to misread signals like these and turn down someone who might actually be a great fit.

There’s one question that sits on the edge of what’s fair: “Why have you changed jobs so often?” It can be a reasonable one — if you understand that the answer often reflects the natural lifecycle of projects, not the candidate’s behavior. That’s exactly how it was in my case. I worked at startups, and most of them shut down in their first year.

Not Quite Therapy

• What do you think your friends would say about you?
• What about your personality makes you doubt yourself?
• How do you handle situations when things don’t go as planned?

These questions seem like an attempt to assess maturity and self-awareness. In practice, they shift the conversation into personal reflection under observation. The candidate doesn’t have time to think it through or ask for context. They came to talk about work — and suddenly they’re expected to quickly explain their own reactions and motives. Without a prepared answer, they start guessing what kind of response is expected. That forces them to improvise. In the end, the interview ends up measuring not how well they’d do the job, but how well they handle being put on the spot.

The Culture Fit Game

• Why do you believe you’re a good fit for this role?
• How do you think your experience could benefit our team?
• Why do you want to work with us specifically?
• Which of our company values resonate with you?

These questions assume the candidate made a deliberate choice and took the time to learn about the company. In reality, many people apply to dozens of roles at once and only start learning the details after they get an interview. Their understanding of internal processes and values is limited, so their answers tend to reflect not a real connection with the company, but an attempt to sound motivated without much to go on. As a result, the answers come out generic and don’t say much about how the person actually works.

The Last Job Focus

• What kind of tasks did you handle in your last role?
• What challenges did you face on that project?
• Why did you leave that company?
• What was your role in the team at the time?

These questions are reasonable on their own, but interviews often end up focusing almost entirely on the candidate’s most recent project. That project might have been short, irrelevant to the role, based on a different level of responsibility, or simply untypical in terms of tasks. As a result, the conversation revolves around a fragment that says little about the candidate’s broader experience. The person may have led a larger team before, worked on a different scale, or operated in a different environment — but that gets lost if all attention goes to the last job.

I’ve often tried to zoom out and explain that what matters is the full arc of experience, not just the latest entry. But the conversation kept circling back to that one last project, as if it had to explain everything. This focus skews the outcome. If the last project is an outlier — the easiest one, the least successful, or simply the odd one out — then the answers reflect a random moment in someone’s career. It’s easier to talk about, but it says very little about the actual experience.

At the end of the interview, it comes down to a simple question: did you understand the person — and did they understand you?

In startups, something often seems more urgent than backups: a new release, user growth, the next round of funding. When resources are scarce, the team focuses on building the product, not the infrastructure. And every day, shipping wins. Backups keep getting postponed. Not just because there’s no time, but because thinking about them means admitting how fragile everything is, and how much rests on the people behind it. In the early stages, it’s often just a single manual backup. No automation, no established processes. Beneath it lies a belief that disasters happen to others — until the first failure shatters that illusion within seconds, and you discover there are no copies, access is lost, and nothing can be recovered.

You don’t learn how resilient your system is until it breaks. Even the most reliable systems are not immune to rare, unpredictable events. Sometimes a single accident is enough to put everything at risk. A fire, a flood, or a lightning strike can destroy both originals and backups if they’re stored in the same place.

The loss of code, documents, and databases erases not only a project’s memory but the time that went into it. It feels like everything is gone — until you manage to recover at least part of the data. What comes after is relief, and a realization of how close everything came to being lost. Sometimes recovery never comes, leaving only emptiness.

After something like this, you never think about your systems the same way. It’s the point where a founder starts caring not just about growth, but about what’s already running. Making a backup means accepting that the system is vulnerable. But at least you’ve done something about it. It brings back a sense of control that’s easy to lose when you’re focused on shipping.

Catastrophes don’t start in code; they start in the decisions around it — running the wrong command, deleting the wrong file, acting in moments of haste or fatigue. One mistake can erase years of work. Sometimes it’s human error; sometimes it’s a system we trusted too much. Technology creates the illusion of safety: when everything is stored in the cloud or syncs automatically, it instills confidence that nothing will go wrong. As long as it works, we think we’re in control. But any protection weakens the moment it stops being tested. Security isn’t about feeling in control. It’s about having a plan for when you’re not.

Data loss isn’t just a technical failure. It’s a breach of trust. Even if the data can be recovered, restoring reputation is much harder. A single failure can erase years of credibility in the eyes of investors or users.

Security is a habit of taking care of what you’ve built. It doesn’t demand perfection, only attention. Imperfect protection is better than none. And a tested backup is better than the illusion of stability. Sometimes all it takes is one evening — make a backup, test restoring it, and finally sleep soundly.

Technology evolves. Complacency endures.
Building something means taking responsibility for its survival.
It’s respect for time that can never be regained.