[closeparen]

Software engineering does not consist of preparing for and then giving short/intense performances.

Plenty of fields do - performing arts, film, trading, etc. all involve some form of short, intense, expensive activity to which you show up prepared and work in a burst of superhuman activity. But software isn’t like that at all - you get a problem and you dig into it, mull it over, research, etc. at your leisure until it’s done. We’re novelists, not actors.

[Blazespinnaker]

This is true if you have very junior level responsibility, but as soon as you need to take any kind of leadership role others will be looking to you to contribute in a manner that is not ad hoc.

Also, you mention research. Research and preparation are synonymous.

[closeparen]

Nope, not even slightly. Research is something you do after you know the problem at hand, to see if you find anything helpful. Preparation is something you do before you know the problem to minimize reaction time once the problem is revealed. Preparation is wildly inefficient, as it involves studying a bunch of material that will not turn out to be needed, just in case.

If you're writing software under the kind of time pressure where consulting reference material is unacceptable, something is deeply wrong. Most software engineers, most of the time, should be able to research topics as they come up rather than prepare (beyond the standard preparation in college).

Making long-term plans, building consensus around them, etc. is important, but is nothing like practicing for whiteboard interviews.

[Blazespinnaker]

So wrong in so many different ways. The questions you research / prep for may be needed at some point in your career.

Much like programming. You program for all relevant edge cases, as one might be used at some point.

People who don’t prep are horribly lazy and are terrible at enumerating edge cases. The have buggy code that fails at some point. Laziness is by far the way worse quality? Though not the only sin.

Lack of sincere desire to be helping the team succeed and no innate talent are bad too.

[closeparen]

>The questions you research / prep for may be needed at some point in your career.

And most people, most of the time, can and should research them as needed.

>You program for all relevant edge cases, as one might be used at some point.

Yes, because a program doesn't get to pause execution and defer to the human mind to ask "hmm, what do I do in this case?" A programmer does so all day every day.

>are terrible at enumerating edge cases

Any attempt to pre-compute the edge cases of all possible programming situations will be hopelessly inadequate. Enumerating edge cases requires analytical thinking in the moment, essentially the opposite of preparation.

[thaumasiotes]

> Research and preparation are synonymous.

This is wrong. If I want to handle a problem by researching it, I have a goal in mind ("solve problem X"), and I'll look for things that will help with it.

Interview preparation specifically avoids that approach. Instead, you're supposed to become familiar with every possible problem, in case it comes up during the interview. Most of them, obviously, won't, and from a "research" perspective that means that nearly 100% of the time you spent in preparation was wasted.

[xstartup]

One more thing is that, research takes time. Companies want ability to cut short this time which is required from inception to delivery of a product. They prefer a candidate who already has prepared linear algebra, if you are going to work on deep learning at the company.

[yeukhon]

Like every other field, you need to practice and you need experience to do well. Maybe you can dive into a new framework without trying out any tutorials, but not everyone.

[expertentipp]

Very few are novelists, most are ghostwriters.