[lumost]

As an experienced engineer Apple I'm sure that you've noticed a few trends such as.

1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.

2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.

3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.

4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly, which is a much better approach to hiring than looking for Go + AWS engineers with 20 years of experience ;)

As an interviewer/hiring company hiring many engineers you then have to decide whether you should have a different process for hiring experienced engineers compared to junior engineers or otherwise deal with the awkward circumstance that an experienced candidate maybe isn't just rusty but doesn't have the knowledge or execution ability to code. When hiring an internal transfer it's fairly easy to vet the latter criteria, but when hiring externally it's substantially harder.

[b20000]

1) that is extremely unlikely for any engineer who has produced open source projects or commercial products succesfully

2) again, see 1)

3) they don’t need to remember everything about all algorithms and data structures, just like lawyers don’t remember all details about the law either. that is what books and the internet are for. you just need to know what exists and where to find it, and should have implemented some of it in your career and while in college.

4) i think that that is a typical mistake made by managers and HR. it takes years of work to enter a particular niche and gain experience in it, and it’s unrealistic to think you can just quickly train someone on the job. apple is the example here - most people there are highly specialized in exactly one thing and have long careers related to that.

passing on experienced people because they don’t care about your stupid binary tree trick question or are just tired of going through another leetcode circus act is a costly mistake - there are only a very limited number of highly specialized people available in the market, and it is these people who will make the difference between a “meh” product and something truly incredible.

hiring is broken and will remain so until the coding interview bullshit is replaced with something better.

[goodrubyist]

I also think it's broken in the way you describe, but also find it amazing that it can remain broken for so long given the costs associated with it.

[ChrisMarshallNY]

> find it amazing that it can remain broken for so long given the costs associated with it.

For the same reason that hazing has lasted as long as it has.

"I got hazed, so you will, too!"

[ChrisMarshallNY]

> 1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.

That's me! But...wanna see something cool?[0] That's a link to the maintenance manual for my very first engineering project, started in 1986-7 (PDF doc). I wrote it, as well as the project it describes. It contains full source code for the firmware OS, strategic discussions, user guidance, chassis, and electrical diagrams.

My very first project. At the time, I was a high school dropout, with a GED, and some tech training school. I'd never attended one single "core comp sci" class. In fact, I had no idea that "core comp sci" even existed. The engineering team I worked with were all EEs. The firmware team was separate (and a bit arrogant -hard to work with), and my team liked having their own firmware geek, who was quite grateful, for being given the chance.

Not too shabby.

> 2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.

I code every single day. How's that work out for you? In my experience, others have a hard time, keeping up with me.

> 3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.

Define "the basics."

If you mean LeetCode school curriculum algorithms, then, guilty as charged. Also, guilty of not being particularly interested in "a little practice." These represent things that I have seldom encountered, In Real Life. I won't bother wasting time practicing them, if the only place they have utility, is in a conference room that I'll never enter.

If you mean "the basic structure of iOS applications," "device I/O concepts," "Shipping to the App Store," or "idiomatic Swift," then, you're in luck! Since these inform the work that I do every single day, I happen to be pretty up on them. No practice necessary.

Although, TBPH, I frequently google even the most basic stuff. This will continue for the rest of my life. If you can't deal with that, then we're better off not interacting with each other. I forget stuff, all the time. I google it.

This Internets Tubes thing is the pants!

> 4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly

People who solve difficult problems -every single day- can also be pretty fast on the uptake.

Just sayin'...

[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf