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.
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.
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.
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.
Also, you mention research. Research and preparation are synonymous.