Please stop the coding challenges

Did you ask why they chose the take home?

I'd favor 1 and 2 over 3, because I feel that you understanding the problem I'm solving gives a better context to appreciate my approach.

If I take it home and hand it later, you can compare my solution to yours (or others) and better grasp my coding style, even if it's different to yours, since we worked on essentially the same task.

If we're working as a pair, you can observe my thought process. I can better express my reasoning for picking certain idioms.

With past code, there's almost no context. It's just code that was written for some other project. In my opinion, this can be very useful in preliminary steps, when I'm sending out my resume and you need to validate that I can indeed write code. In later stages, I think it can be impressive if I have a working app and can walk you down the code for a particular feature. But who has working software laying around? We all have code that works with a few hacks, sorta...

I'd favor 1 over 2, because it reduces the probability to blunder. Between spending 2 hours on-site with a higher risk to mess up (due to pressure, Murphy's law, etc) and take the assignment home to work on it for an extra 2 hours, with ample time to freely research whatever I don't understand. It's a no-brainer for me.

When I was hiring, resume quality was often a negative signal. I could sometimes tell when someone used a resume preparation service. They were good at what they did, the resumes really were much better, and the candidates correspondingly worse.

The problem is that there is financial pressure to game the system, which means it's worth spending time and money on getting through the hoops but not on improving your work after that. Resume preparation, leet code grinding, even references are tainted when the reference is aware of the financial pressure (this person wasn't that great, but do I want to impoverish their family? or they'll scratch your back in exchange for you scratching theirs).

I think the analogy by Steve Yegge still holds: if you claim you're a juggler, you should be able to juggle in front of people at any time. So, yeah, coding challenges is a good filter, at least.

The problem is not coding challenge per se, but that people can now cram it on sites like leetcode. See, before we had leetcode, only two types of people could solve a large number of algorithmic problems organically: those who were naturally talented, and those who were so geeky that they devoured the works of Martin Gardner, Knuth, and the like. Excelling those challenges showed raw talent in old days.

And companies like the young Microsoft and young Google absolutely loved such talent, and such talent did shine in those young companies.

Not to share here. I was at boring places my parents had the interesting experiences but those aren't my stories to share.

It had lots of small industry specific solutions, lots of hardware/software tied together solutions (so a large 'tech' community where 'tech' was the title for hardware technicians that hand built/designed/produced the hardware devices/circuit boards/etc). I'm surprised you never heard of the Santa Cruz software scene. Some examples:

Victor Technologies (specifically Victor 9000 Computer)

Texas Instruments had a fab/facility there.

Digital Research had a presence (CP/M, PDP)

Seagate

SCO

Borland

EMU Systems (hardware music samplers) (lots of cool musicians used to visit their facilities)

(current) Antares (Auto tune/music tools)

(current) Plugin Alliance (music tools)

(current?) Plantronics

But mainly it was smaller obscure companies. For example Parallel Computers working on parallel computing early on. IDX working on radio tags in the 80s. Triton doing sonar imaging with SGI boxes.

It was very much it's own sub-scene with people who picked it for lifestyle so a bit different mindset (more hippie, schedules around the tides so people could surf, everyone going to the Wednesday night sailing races together). I was just a kid but it seemed cool. And it was open and friendly (I always had summer jobs as a kid starting from duplicating floppies for CP/M or PDP software as a 10 year old). Plus just a cool vibe. I remember next door to where my mom worked going and talking to Lorenzo Ponza (inventor of the pitching machine) when I got bored of playing Trek or Rogue on the VAX at her office (she was a workaholic always working weekends and dragging me along) or skating the ramp (for the stoner tech(nician) crowd) in the parking lot.

Yeah, that's fair, and I'm guessing your decision made a lot of sense in that context.

Though in an interview situation, it's reasonable to not point out that you shouldn't ever do the thing that you're being asked to do. Some amount of artificiality is to be expected. I do agree that stating that one should never do it is a purely good sign. It's just that not stating it isn't necessarily a bad sign.