Comment by indymike | Hacker News Reader

Comment by indymike | Hacker News Reader

Parent Full thread

> I’ve been a software engineer and now architect for 15 years. Studying leetcode like problems won’t help me at my current job or a future employer once I get past their interview processes.

Perhaps. I've been building software for over 30 years and I still find that I learn a lot when I practice and push myself to work quickly and efficiently.

> If you haven’t seen a particular problem before or had time to research it, it’s unrealistic to expect a candidate to solve it in twenty minutes in a high pressure situation.

Someone just slipped a bug into production. We now have $12,399 per minute in transactions that will not be processed. CEO needs a report for a board meeting in 20 minutes. Junior dev didn't show up and four team members were waiting for the commit he was supposed to have in yesterday. Dealing with high pressure problem solving is really every day, and practicing against the clock is a great way to learn to be calm and focused when it matters.

> For example, I work 50+ hours a week with two kids and a parent with cancer.

So sorry that you are dealing with cancer in your family's life. Cancer sucks.

If you have a major bug in production and have to report to the CEO in 20 minutes, all kinds of soft skills that you can show in interviews are going to serve you vastly better than knowing a leetcode algorithm.

> Someone just slipped a bug into production. We now have $12,399 per minute in transactions that will not be processed. CEO needs a report for a board meeting in 20 minutes. Junior dev didn't show up and four team members were waiting for the commit he was supposed to have in yesterday.

While it's helpful to have rockstar devs that fix that kind of situation in 5 minutes, I'd say you still have to have boring people who test thoroughly, document properly, and have deployment procedures and rollbacks figured out, none of which is something you identify from a Leetcode type test; yet these practices which lower the chances for that scenario to happen in the first place.

Hey Mr CEO, I have no idea how that bug slipped into production but I see you have a whiteboard here… let me show you how to invert a binary tree.

> $12,399 per minute in transactions

> Junior dev didn't show up

Why is the junior dev in charge of something so important? What were the senior people working on instead that was more important than this? Sounds like he cracked under the pressure. Where was leadership?

> Why is the junior dev in charge of something so important?

I think you are blending all of those problems together (there are three - hopefully not all of them at the same time... that would be a worst day ever). It's pretty normal that someone can't get to work, and you end up with a last second scramble to get something fixed. When something ships into production and is buggy, what matters is fixing it quickly.

The point is that most developers do end up having to work under pressure from time to time, and the higher up you get, actually, the more critical it will be.

The situation you describe is not what you face in leetcode. The key here is "a problem space not seen before". Bugs in production by definition are problems in a domain on which you are currently working and are familiar with. So yes in that case I would expect someone to work efficiently even under pressure. But a problem in a completely new problem space no. Someone may know for example that a presented problem can be seen as graph traversal problem but may be blocked for the moment on the actual implementation of it. This is a context switching problem and not a performance problem.

I don't think it is fair that you are downvoted, the parallel you are presenting is a real question, eg. how much does being good at leetcode correlate with being good at solving production issues timely and efficiently? (Even if real life production issues are _not_ leetcode problems, but nobody said that.)

I don't think that there are any conclusive studies covering this, so both sides might be correct for all we know.

Sounds like an organization problem to me. Roll back to the last working state. You have CI right... right?

Roll back prod?

What do you do when that fails?

If you don't occasionally test your rollback capabilities, you don't really have any.

Reply on news.ycombinator.com