if you want to get actual value out of a coding “interview”, trash your “leet code” dick measuring contest and give me code to refactor, debug, or even… write docs or tests for.
we all know that “write a dijkstra shortest path algorithm” test (looking at you google) is more of an indication of your inability to understand people and jobs, as well as some way for you to feel better about yourself.
also, as someone who actually took classes with dijkstra, i still have ptsd from it.

@petrillic

I've heard 2nd-hand Dijkstra horror stories from my grad. school department head. Yike!

@danmcd he was neither a nice person nor a good teacher.

@petrillic

Definitely jives with the stories I heard, then.

@petrillic to be fair, it's also a great way to filter out people who didn't get CS degrees from particular schools!

...

@cliffle which, if we're honest, is pretty much the main use case.

which is how you get every company building its own build system and thinking _that_ is where time should be spent.

@petrillic

I used to shadow interviews at Google from time to time. Between that and hiring committee I saw some stuff.

One interview, the interviewer noticed that he and the candidate (also a he) both played lacrosse in college. No technical questions asked, hire recommended.

Anyway, I'm agreeing with you in a roundabout fashion.

@petrillic this is literally what I do. At my last job I would give people this awful C multithreaded echo server I banged out in an hour once. It didn't even compile and had both logic and concurrency issues. Started off with "you've just been hired and your first task is to rehabilitate this code someone who just left the company was working on. Help me figure out what it is and then get it working."

Always got great results out of it. Very open ended, candidates could lean into their talents, but you always learned a bunch about them.

I wouldn't be able to do it properly at my current job and it's made me not want to even do interviews here.