There are people who literally say this and then you hire them -- they turn out to be complete duds. I'm genuinely curious because I'm hiring right now: by what mechanism would I discover that you have these skillsets and are good at what you do?

I was somehow reminded of this guy who once wowed me in an interview by coding up a small graphics demo rather quickly. Turns out later that that was the exact one program he could code without being hand-held EVERY SINGLE MOMENT. I laugh whenever I remember that incident (from early on in my career, in my defense).

You have to build a repertoire of questions that defeat rote memorization, prove real experience, and show genuine ability to solve unseen problems...

I remember TA'ing African exchange students in Haskell.

They could remember the exact type signature of standard library functions.

They could define a Monad instance from memory at the speed they could type.

But you couldn't ask them a single question outside of what was presented at lectures.

They couldn't solve a single assignment. They were stuck on rote learning.

I'd blame their educational system, because it was quite consistent (sample size = 3).

The classical example: Teacher says X, the whole class repeats in choir X.

There's an interesting bit in "surely you're joking, mr Feynmann" where he is amazed how primary school kids are learning physics. Only, as it turns out, nearly noone in the entire country has any actual understanding of physics, because from elementary school upwards all they do is memorize the material.

https://v.cx/2010/04/feynman-brazil-education

I've had a lot of success asking about fuckups, worst thing they've had to debug, and general "fuzzy" questions that specifically do not have a single answer, or the answer is so relatable/specific to a person's experience. Then you have to watch them as they answer.

What's so bad about getting a feel for someone and hiring them on a probationary basis? See how they go on discrete - but real - tasks for a week or two, and then make the call on going forward or not. It's how most hiring has always worked (and continues to work) in almost all other fields.

Also, re technical questions, I don't think anyone is saying that you can't ask any technical questions whatsoever, I think the concern is about giving people abstract, theoretical CS problems that will never actually come up on the job, on the very iffy assumption that their performance while being asked to dance for a committee in high-pressure job interview situation is going to be reflective of their actual skills. (And more broadly, that a good programmer must be quick on their feet with schoolboy-style CS puzzles that are basically irrelevant to most roles.)

I have no idea if this is accurate or not, but there is this general stigma from both sides that "no decent programmer worth hiring fulltime in hotter markets/companies would/should agree to a contract/temp/trial job".

I think de-facto fulltime jobs i've seen end up kind of like that - if you don't work out in X months, nobody will shed a tear about kicking you out - but this is still perceived as a more expensive operation that should be avoided by having a "proper" interview process. On which nobody can ever agree, but that's the sentiment.

A trial period is part of every permanent employment contract herearound. No matter the job.

Both parties can terminate the employment agreement within a week for (usually) the fist three month of employment.

No stigma involved.

I think it’s fair for both parties, they both need evaluate each other.

IMO this is where a comprehensive System Design interview weeds out the hopeless. Minimum 2 hours, don't just use a "design facebook/twitter/insta" scenario because anyone can memorise those, dig into the weeds as and when it feels appropriate, and keep the candidate talking through trade offs, thought process etc so you can really peak inside their head. The catch is that you also need to be very competent and know the design and all permutations of it inside and out.

Leetcode et al. are just testing rote memory, there's no need to have candidates actually type out solutions its a waste of time. So long as they can articulate what solution they would use, why, and what other solutions they considered that's all you really need to be concerned with.

So to preface, I'm not looking for a job (trying to build my own company)

When I do interviews (probably limited compared to you but some) I do it like I wish someone would interview me.

I focused purely on curiosity. how many things disparate things are they interested in, the things that overlap with my knowledge I probe deep. I believe in Einsteins quote.

"I have no special talents. I am only passionately curious."

If someone knows about how RDMA and GPU MIGS work they are probably pretty damn interested in how HPC clusters function. More importantly can they compress this information and explain it so that a non technical person could understand?

There are so many endless number of questions I could ask someone to prob their knowledge of a technical field it kind of upsets me that most of the time people ask the most shallow of questions.

I believe this is because most people actually study their fields a very limited amount, because most people are honestly not truly interested in what they do.

The biggest implication of this is that I may be able to tell if someone has this trait but I understand that the majority of people could not as they literally don't know the things they could ask.

Asking system designs of me if you aren't knowledgable of the field would probably be the easiest to see the complexity of systems I can build.

It depends on the role. In web development, for example, there are lots of non technical things people can be good / great at that a coder might not be. Things like CSS, HTML, accessibility, semantics, things like that. Lots of JavaScript people have no idea how to leverage CSS and over engineer things or find it impossible to implement certain features or if they do, it's 1000s of lines of code when it's really just a few lines of CSS.

Take home project limited to 2 hours.

Chat gpt can solve any take home problem. You need to be on video making interactive feedback and demands to see that someone can actually write code and understands programming even a little bit.

Hey, what are you hiring for exactly? May I email you? My email is in my profile.

Are you self-taught? How did you write the on-the-job code? Do you do well with take-home exercises?

Do you struggle with work projects that feel boring or abstract?

Self taught, come from EE background.

Was originally building firmware and hardware for previous company while testing DS on their systems. They liked my work and I switched to DS and ended up a team lead.

Honestly have never had a take home exercise but would love it if I could. I basically make my own work, if I don't get work I will build other projects for them and try to sell it to the company.

I normally make good value projects and can sell it. It's how I went from hardware to DS lead of a team in a few years.

You sound pretty cool and useful to companies that get it. My suggestion is to find ways to present on some of the things you’ve done. Then you can point to the presentation video/slides, plus you’ll probably receive inbound inquiries from companies that could actually use creative thinking and building.

The take home exercise/work sample companies are out there. Here’s a list I helped contribute to. https://github.com/poteto/hiring-without-whiteboards

Yeah I'm EE and CompE background, and been in software for 20 years, it gets old with the 26yo "senior" dev interviewing you rolling his eyes like you are some big liar for not wizzing through his CS quiz questions (oh and for front end positions, lol). Studying EE was much harder and well-rounded engineering program compared to CS degree at the time I was in school.

Why are you doing all those things and what jobs are you applying for? Can you solve fizz buzz in an interview setting?

I'm not bad at getting jobs, just feel when I am looking I believe people think I am lying about my project experience.

I do these things because I see a place in the company to grow value and do it.

I can write almost all basic coding and my true skill set is in custom complex DS pipelines at scale.

Fizz buzz is certainly not a replacement for expertise, which is what the above commenter seems to be emphasizing.

Naturally it's a "low bar" but it's an awfully low bar for a job that isn't entry level.

That's why it's so concerning when you have people who confidently say they're great engineers who are experts in firmware, UIs, operating systems, and networking, yet when you ask them to write a 3sum or remove from a binary tree they freeze up and blame it on an unfair interview structure.

I'm a bit reminded of a chef who claims he can cook pasta, sushi, and pastries, yet when asked to fry an egg says that it's not fair to expect him to do so on the spot. A chef who can't cook when needed is about as useful as an engineer who can't code when needed.

There's a common double standard here though - when I've asked backend-type devs to do a UI sample/question (these are often "full stack" roles), the leet code geniuses dismiss my concerns as that not mattering if they flop it.