AI killed the tech interview. Now what?

>You can often tell an inexperienced interviewer from the extremely domain specific question they ask which _they_ are familiar with.

Lol a bit touchy aren't we?

Like I said, it's not really relevant in today's languages. It was for a Delphi/Pascal position. If you do any type of database code (like T-SQL), you would also know it. If your experience is mainly in C type languages, everything is a function so it doesn't apply.

If you hired a guy for a Delphi position who didn't know the difference between a function and a procedure, you hired the wrong guy.

  procedure Hello;
  begin
    ShowMessage ('Hello world!');
  end;

  function Double (Value: Integer) : Integer;
  begin
    Double := Value * 2;
  end;

Function or procedure is defined in every subroutine. It's a very basic question for Delphi, like what's the difference between an integer and a string.

> We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.

Except, that's not what happens. In basically every coding interview in my life, it's been a gauntlet: code this leetcode medium/hard problem while singing and tapdancing backwards. Screw up in any way -- or worse (and also commonly) miss the obscure trick that brings the solution to the next level of algorithmic complexity -- and your interview day is over. And it's only gotten worse over time, in that nowadays, interviewers start with the leetcode medium as the "warmup exercise". That's nuts.

It's not a one off. The people doing these interviews either don't know what they're supposed to be looking for, or they're at a big tech company and their mandate is to be a severe winnowing function.

> It isn't that your interviewer knew all the languages, but that the language didn't matter.

I've done enough programming interviews to know that using even a marginally exotic language (like, say, Ruby) will drastically reduce your success rate. You either use a language that your interviewer knows well, or you're adding a level of friction that will hurt you. Interviewers love to say that language doesn't matter, but in practice, if they can't know that you're not making up the syntax, then it dials up the skepticism level.

> Licensing. We do the Leetcode interview in a controlled testing center.

Congratulations, you are now a "Certified Leetcoder (tm)". :-(

Seriously: what a lot of people write down here is that a lot of programming jobs don't involve code puzzle skills, but are often rather about putting stuff/APIs together in the currently fashionable framework.

This makes becoming a Certified Leetcoder (tm) just another useless hoop to jump through.

(Just to be clear: for those few programming jobs that demand the employee to solve algorithmic puzzles regularly, doing them in a job interview makes sense. But these jobs are rare.)

I think you are missing my point.

Words like functions/procedures tend to have different connotations across languages and once one crosses one's 15th language, and each having some 20 different keywords, it become difficult to remember what the exact connotation of a word is, in a specific language/framework. This is the most likely situation of the guy whose post I responded to.

The exception to the rule is, if you have been working quite a bit _recently_ on a specific language. You are presumably talking about this situation.

> We do this too, works fine. We ask open ended questions like, "What's your favorite thing you've done in your career and why?" and "What was the most challenging project in your career and why?" If you listen, you can get a lot of insight from just those two questions. If they don't give enough detail, we'll probe a little.

The problem is: there is a very negative incentive to give honest answers. If I were to answer these questions honestly, I'd bring up some very interesting theorems (related to some deep algorithmic topics) that I proved in my PhD thesis. Yes, I would have loved to stay in academia, but I switched to industry because of the bad job prospects in academia - this is not what interviewers want to hear. :-(

> "What's the difference between a function and a procedure." It's a one sentence answer

The terminology here differs quite a lot in different "programming communities". For example

> https://en.wikipedia.org/w/index.php?title=Procedure&oldid=1...

says: "Procedure (computer science), also termed a subroutine, function, or subprogram",

i.e. there is no difference. On the other hand, Pascal programmers strongly distinguish between functions and procedures; here functions return a value, but procedures don't. Programmers who are more attracted to type theory (think Haskell) would rather consider "procedures" to be functions returning a unit type. If you rather come from a database programming background, (stored) procedures vs functions are quite different concepts.

I could go on and on. What I want to point out is that this topic is much more subtle than a "one sentence answer".