[doorbumper]

So you want a company to hire somebody after talking them for 30 minutes? Based off of what? You honestly can't imagine talking about technical software problems for more than 30 minutes? That's a pretty big red flag to me.

[Clubber]

I'm assuming you are technical yourself, otherwise please disregard. What you are unintentionally implying is that you can't spot a fraud by talking to them about your chosen profession within 30 minutes. If you can't, you shouldn't be doing the interviewing. If you can, why waste 5.5 hours of the company's time per candidate?

[varjag]

Plenty of people are great talkers about profession, big picture, architecture blabble and so on. It does not correlate with coding ability.

[taurath]

Its not causation, but I'd say it correlates to being a thoughtful person. Drilling down on the architecture blabble to see how deep their understand goes will absolutely tell you whether they could code a solution.

Is there a person who claims to be a coder that has configured and launched a multi-environment microservice with several attached artifacts like DBs and queues, that knows in depth what each is doing, that can't code? At that point you're just testing whether someone has memorized syntax details that they might usually get from an IDE or a 3 second google search in regular development. I have been writing production JS for years but still have to occasionally look up Array.slice vs Array.splice parameters, especially if I haven't done a lot of data munging in a while. That may indicate to a person giving an interview that somehow I'm "faking" it, when in reality its just a momentary stall-out in my brain's lookup tables.

[varjag]

> Is there a person who claims to be a coder that has configured and launched a multi-environment microservice with several attached artifacts like DBs and queues, that knows in depth what each is doing, that can't code?

Funny that you mention it. I know a person who can't shut up about microservices, Kubernetes and CI and can't code their way out of paper bag. They had no problem passing one of those interviews.

And sure rote API memorization isn't the point. But if a candidate can't code say bubblesort (or any kind of sort) in 30 minutes they are not very good at coding - and it doesn't matter if they can quote their architecture patterns by heart.

[taurath]

> But if a candidate can't code say bubblesort (or any kind of sort) in 30 minutes they are not very good at coding

Thats bullshit. Sorry. Most developers will NEVER implement a generic sorting algorithm except in a code interview. You say you don't want rote API memorization, but you do want rote sort method implementation memorization. Yes you can be a system or tools developer and maybe have a higher chance of doing it, but its 99% likely even then that you just use a library for it for the language you're using, or copypastaing it from someone who's studied the specific implementation for your lang.

[Clubber]

I disagree. You aren't asking the right questions or probing enough.

[varjag]

When you start probing enough it quickly becomes practical/coding interview we all come to detest. Sure enough, that way you might not even need 30 minutes. But shop talk alone doesn't cut it.

[phendrenad2]

Maybe your “shop talk” is different from mine, but I can suss out fakes from the first sentence usually. You’re correct in that they go straight for the broad architecture strokes, and they speak in vague terms. Trying to get a solid grounded answer is like trying to nail jelly to a tree. That’s when you know they just read some wikipedia articles and don’t know the practical applications of the words they’re using.

[varjag]

Those have to be really clumsy then.

There's a number of people with CS or SW engineering degrees who can't actually code. Those can often quote you Gang of Four patterns, discuss broad slices of tech and draw architecture diagrams on the board. But still can't code.