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.

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.

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.

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.

>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.

> 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.

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.

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.

Very few are novelists, most are ghostwriters.

Sure. But at work, I know what I need to prepare for. Interviews don't exactly give you the questions ahead of time allowing you to prepare. So, preparation is not something they are testing for.

The idea of screening for a software engineering gene is patently absurd. In an ideal scenario, we screen for the ability to do the work the job requires. In the normal scenario, we screen for some mix of that and the ability to apply cookie-cutter techniques to (hopefully) novel problems in the space of ~45 minutes. Some companies also ask you to do a sample practical problem either on site or on your own time. None of this indicates anything about someone's "innate genetic talent", if there is any such thing.

To imagine that genetics do not play a role in intelligence (or any talent) is horribly naive, otherwise we could teach our dogs to program.

And it’s illegal to try and screen on anything except ability to do the job. Be very careful if you find yourself thinking in terms of software engineering interviews being a general intelligence test — you are setting yourself up for a discrimination suit.

https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co.

As you clearly demonstrate, intelligence has a genetic basis. However, it does not follow that there is variation among humans at the relevant genetic loci. The variation may have become fixed in an ancestral population of modern humans.

What I gave there is an absolutely standard assessment of the situation from the point of view of population genetics. Of course intelligence "is genetic" in some sense: that's why dogs and cucumbers are less intelligent than humans for most definitions of "intelligent". The question is about the phenotypic significance of current intraspecific genetic variation.