Giving interviews, disappointing, am I getting old?

[james_s]

It's why I am creating a set of code tests, one of which includes this:

Write a program to generate all combinations of a shuffled deck of cards.

The right answer IS "No".  The "better" answer is realising its impossible and explaining why.

I don't think "No" is a good answer. I mean I can write the program without too much difficulty. You and I likely won't live long enough to see it finish running though but if we are patient we might see it fill up all available memory and storage and then crash. Generating the permutations of a deck of cards is not difficult in itself, it's the shear number of them possible and dealing with those that is the problem and so it is not something that it makes sense to try to do. 

[james_s]

Interviewing for hardware folks feels similar to be honest. A worrying number of"senior" engineers appear to have forgotten the fundamentals and even people who do know some of it don't listen to the question that they're being asked (it does get repeated if they appear not to have understood ...).

I actually interviewed for a hardware position last time I was between jobs, despite lacking a degree and having spent most of my actual professional career in software or embedded which was mostly software. I was pretty much just kicking the tires when I applied and didn't really expect to even be interviewed but they called me in. They mentioned that it had been very hard to find anyone with any analog qualifications, all the recent EE grads want to throw a microcontroller at the problem and start coding. I ended up pre-emptively declining the job after thinking about how brutal the commute would have been and looking back I think it was absolutely the right choice to do so. Even so I was surprised when they sounded disappointed and told me I was easily the most qualified person who had applied. I don't really consider myself THAT good, I'm a generalist and jack of all trades.

[station240]

So I got promoted, yeah!  As part of that I now have to give technical interviews for recruitment.

Also, things like differences between Arrays and Collections.  They can give me 10 reasons why you should use the dynamic Collection, but go a bit dumb when you ask why you would use an Array over a collection.  Similar things come through in terms of memory allocation, resource allocation and generally anything that has consequences functionally or non-functionally.

Multi-threading and concurrency.  Almost everyone of them have used a distributed, transactional, concurrent system design in their projects, but less than 10% even know it.  Aka, enterprise REST apis and micro-service stuff.  Almost none of them can actual tell me the disadvantages or difficulties of multi-threaded/concurrent/distributed systems.

Am I being too picky to expect critical thinking from people with 3-5 years experience?  An understanding of things like performance, memory, overheads and at least some consequences, pros and cons is what I was expecting, but I've only seen it in any fashion of understanding in the top 5% maybe.

Ah you've created a paradox, if they are teaching this at University then recent graduates may remember, after 3-5 years no chance.
The top 5% just happen to have kept practicing these particular skills.

Perhaps another approach would do better, give them the answer and get them to explain.
Here are two code bases, the longer one runs faster and uses less memory, explain why.
If they cannot figure out that code dedicated to one purpose is better, and that extra linked library at the top is bloating out the program, then you've not going to teach them other things they need to consider.

[rstofer]

Legally, interviews are tricky.  It might be hard to prove they are non-discriminatory.  At least in California and probably the entire US, there are laws...

If there is going to be some kind of pre-employment 'test', it has to be exactly the same for every candidate, including the issue of language(s).  It probably needs to be entirely objective (simply gradable) and not overly subjective.

Sometimes I think the process is 'zero sum'.  The interviewer showing how smart they are and how hopeless the candidate is.  It's probably best if the candidate terminates the interview if it heads down that path.

It is worth remembering that the interviewer has to 'sell' the company.  It serves no purpose if qualified candidates walk away.

[Kjelt]

Sometimes I think the process is 'zero sum'.  The interviewer showing how smart they are and how hopeless the candidate is.  It's probably best if the candidate terminates the interview if it heads down that path.

That is bad if that happens, an interviewer wanting to "protect" their job so trying to burn any candidate is a risk if you use an insecure person.

The only thing I once had with an interviewer is that he was trying to keep on digging for my negative points, everyone has one or more weak points, so I gave him some, but he kept going. The style of why would we not hire you? Why would you not fit in the team?  Etc. I answered them as honest as possible but it sets a negative ambiance. Then after a while he asked if I had any questions. I asked him why I would not want to work in his company or team. He went silent then I laughed and he got the joke that I mirrorred his interviewing style. I got the job.

[Sal Ammoniac]

One thing I’ve noticed in recent years is a lot of people interviewing for embedded positions know absolutely nothing about hardware. Even simple stuff like pull-up resisters is a mystery to them.