Thankfully a somewhat distant inside connection was achieved, who managed to suggest “maybe that wasn’t actually the correct decision” and I got the chance to continue with the process. It’s all been good since then.

I sure do have an internal chuckle every time I have to use that particular tool… and still have to look up the options. :-)

But they also did give me what I thought was quite a good test, which was talking through some working code and suggesting how it could be improved.

I'm sure in the ML sector right now, it's hell. Seven figure salaries are going to get some optimistic over-reachers desperate to try and get in the door and BS their way through the first few months.

My own experience: I had a CEO and board member of the startup I was CTO'ing push a dev my way. "Brilliant", they said, "just really great attitude, check them out see if we can get them hired, fast". I was excited, and keen to meet them. Turns out their way to code was to find a library (this was a Ruby shop, so technically a gem), that did the thing needed, bolt it in using example code and ship it. "OK", I said, "but we're a startup trying to solve an optimisation problem in the logistics space. There is no gem. We're going to have to be smart and solve this ourselves by reading papers and experimenting and trying things out. How would you do that?". And I kid you not, the exact response was "If there isn't a gem, I don't think it's doable, or maybe we should wait until it's done".

When I told my CEO and board member that this great, exciting prospect they found couldn't code, they refused to believe me until I spelled it out really carefully: if we hired them, we'd have to train them to solve problems in code. Like, give them CS50 or something. Is that right for a senior engineer as 4th or 5th hire in a startup?

So now I ask some trivia for engineer roles. I dress it up a bit so as not to be patronising, but I kind of want to have a conversation about how they code, what they do, what their method and see if it rings true. On a lot of phone screens, it still just doesn't tally up.

[1] This is 2007, but I see no evidence of it having really changed much, TBH: https://blog.codinghorror.com/why-cant-programmers-program/

Fortunately they gave me the opportunity to explain that it was a well-known interview question dating back to 2007 (with that blog post as evidence), and that I had previously asked this question in interviews, so I basically had the answer memorized. (I think the fact that I had correct, unique answers for the other questions helped me also.)

Yikes. But I have also known many people with this mindset (and it appears to be workable for a certain subset of the tech industry)

>but I kind of want to have a conversation about how they code, what they do, what their method and see if it rings true.

I think these are great ideas. What kinds of things were you asking in your interviews?

My favourite answer was a guy who replied "I've been working recently on some OpenGPL stuff in Common Lisp for the X window protocol". That was an interesting chat, and I was happy when he accepted the offer I made at the end of it.

By reading papers and experimenting and trying things out? Throw in a few books for good measure?

Why are you answering the question you are asking yourself?

You might not understand how low the bar is here. If I ask 100 applicants to write a working function to calculate E=mc^2 for different values of m, 30+ just won't know where to start.

So when I ask how we might solve a problem I am not asking for the abstract 10000 foot view. I'm checking they can write simple code. Filters out a huge number of people, unfortunately.

If we take that as a given, and I don't disagree with you, what happens? The hiring pipeline becomes optimized to prevent unqualified people from getting through the process. It's focused on reducing false positives: hiring the wrong person. As a side effect, it eliminates more people who might be hired before they get far. In other words, the number of false negatives is not controlled.

In short, the way the filter works is broken. Good candidates never get to the offer stage. They are incorrectly filtered out by a process optimized for filtering, not discovering.

This isn’t a single round N-choose-1 game; the unqualified candidates don’t dematerialize, but rather keep applying and may even engage with automation tools to apply to hundreds of roles every day. So, they become wildly over-represented in the applicant pool for any given role.

There are plenty of applicants which are simply awful and you do not have time to interview all of them.

I am not impressed by the people hiring but I also understand why their task is hard.

Agreed. I do work with some folks who are all "OMG I have to work with this archaic mess." way too often. And I don't disagree with them, but man... not that hard to learn it and code your way out of it. But no they just complain.

Hard to really find out who REALLY has the interest in fighting through the unexpected / rough spots.

You also get a feel for the history of various things too.

I work with a big old Coldfusion system at times. Server side rendering was a thing in the past too ;)

Not many do. Especially those doing the hiring. The thing is, there isn't much business value in making it a core competency, so employers just wing it mostly based on copying what they see someone else do, without any attempt to measure effectiveness, combined with plain old hope and prayer. The result is what you have witnessed.

I don't hear from those kind of recruiters anymore. I just get recruiting spam. Come to think of it talking to recruiters now seems about as honest, opaque, and enjoyable as going into my email spam folder...

The coding tests are specifically designed to hire only recent graduates of computer science. My education was electronics engineering so specifically did not have much "algorithm specific" training (too bad hiring managers have no idea how to change their expectations based on that)

I usually just get underhired in technician and production roles and end up running the entire IT/technical/engineering of small companies in a couple years.No interviewer has ever showed interest in this either.

I've hired a few people for a small company and been a recruiter/screener/hiring manager. It's _incredibly_ time consuming, and it's one of the many things on my to-do list.

https://blog.readme.com/designing-a-candidate-focused-interv...

No! As many applicants as possible should be rejected before we start interrupting these people's days.

You might be a great candidate but what about the other 10 doofuses who aren't? Do they all get to talk to the folks they'll potentially be working with/for right away?

I see doofuses hired regardless.

Whether you agree w/ the filtering or not, you want people who you aren't willing to hire (and who won't be willing to work for you) to be removed from the process as quickly and cheaply as reasonably possible.

This is why phone screens with a single person who has a general idea of what to look for exist. The key is that this person receives feedback on future interviews and their decisions and can make adjustments to exclude/include the right people.

My belief on this is that if that person isn't being told, "You let a bad one through" occasionally, they're being too strict on filtering, for example. But you don't want to hear that too often.

Think about somebody rejecting a job offer.

In most cases, many hours of people-time will be invested and wasted when this happens. So look at why was it wasted? Was salary, a company policy, benefits, or something similar a dealbreaker? If so, start bring that thing up earlier on – either in that first phone screen or ideally in an email before the first phone screen.

Of course, you're not always going to get a clear answer so this is where instinct and experimentation come into play. This is also why it pays to have a single person specialize in the phone screens – they will get many reps and opportunities to develop that intuition.

The trouble is that _everyone_ will say this during an interview, but few have the ability or interest to _actually_ learn on the job.

How to tell the difference?

Yeah, certain hard skills help. I don't want to teach you excel or basic computer skills.

But we work in data analytics/marketing and my coworkers consist of people like a theater major, an anthropologist, someone that previously negotiated govt contracts for Lockheed, a sommelier, and more. Yeah, we hire mostly at entry level, but our team is highly capable because they were hired based on curiosity, critical thinking skills, etc and taught by the people who possess hard skills

Probably because those people are writing code and don't want to spend more than a couple hours a week interviewing folks.

If a role gets 500 applications in a week, it seems reasonable that there will be some sort of filter before candidates start talking with SWEs whose time is very expensive (compared with that of HR or recruiters). Whether that filter is an HR person doing a phone call, a take home assignment, or an automated code test, all methods are vehemently hated on HN.

I hate job hunting just like everyone else, but I'm also on the other side of it and kind of understand why things are the way they are. It's not a "cargo cult" or a conspiracy; it's just companies trying to balance a lot of different concerns.