Giving interviews, disappointing, am I getting old?

[paulca]

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

A few trends I am seeing are disappointing.  They can usually answer, to their abilities, questions about tech.  Some can even talk tech open ended quite well with questions like, "How would you convince me as a tech lead that we should use X Framework in our projects?"

What I see far, far too little answers for are things like, "Could you see any disadvantages to using X in a project or X in general?"

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.  Because they all just downloaded an open source starter project and off they went with no idea what was happening in the background.

I wonder if this is just because I'm a bit of tech polyglot and I'm interviewing 'two tech ponies' with 1 language, 1 methodology, 1 application style, 1 mind set? 

They seem to want to push towards minimising code by increasing architectural complexity, dependencies and overheads.  Stacking frameworks on top of frameworks for fear of having to write a few hundred lines of code.  Of course few of them understand those things beyond having followed a few tutorials and worked in a project that used it a few times.

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.

[tggzzz]

For an R&D position rather than a technician or junior position, I normally start by asking them to describe their past projects, question them on why they made their choices and what they would do differently next time. That gives a good idea of their background and expertise and thoughtfullness.

Then I'll ask a few fundamental questions that aren't technology specific, to see if they have a theoretical understanding to back up practical experience.

Then I ask a few questions that night be relevant to the current job, to see how they think about new problems and situations.

Finally I let them ask questions; the more the better

I don't expect them to come up with specific answers, and am quite prepared to give them a few nudges down a direction that turns out to be interesting.

But before all that, I look for clues in their CV that their experience will enable them to have a good stab at answering them. Very few fail completely, very few are perfect

[tszaboo]

The questions you ask, it would be good questions for a "System architect" job position. In big companies, all decisions are done by these more experienced engineers, while the junior, or even the senior positions are filled up with coders. Sometimes of course they will be more capable than that, these are the people that are not satisfied with their jobs and desire a promotion. There are a lot of young smart experienced programmers that are held down by bureaucracy and boomers who got their position first.
And then of course you will interview them, coming from a smaller company. With these positions, you have autonomy and you are expected to make decisions like that on your own. They will not be prepared for that. They expect that agile/scam meetings to happen, and every day told what to do, and working outside these conditions might be just uncomfortable for them.
It is a difficult market. I also had to interview people, and it is difficult to write questions for them, especially, because I despise writing code in C for embedded. So to answer your question, yes, you could be expecting too much from them. One of my favorite interview question is to list 5 devices that can be used to debug a board. I expect a list like "LA, Scope, Multimeter, Jtag whatever" and if they cannot come up with enough of these, they haven't used them enough to work on a board. Questions like these should tell you, if their mindset is about making a working products, or closing "User stories".

[paulca]

Yea, maybe.    Our interviews are only part of the process, it's a whole rigmarole to be honest.  The only bit I am involved in technical and values.  The other party, usually someone from the management hierarchy will ask the CV run through stuff and let me pick them on interesting points to engage them in free form technical discussions.  Then I pull from a set of fairly language/domain specific question already prepared.   I pick them as I please.  I point out that while there may or may not be correct answers, it's more about how they talk tech, how they work out problems, so if they don't know, have a go or tell me how you would find out.

I don't see the point in asking dozens of black and white tech questions and assessing people on what they know on the day under pressure.  If I ask a question and they get it wrong, but in the process they mention a dozen keywords and sensible demonstration that they have dealt with the concepts, then I take that as a good enough answer.

Our company doesn't want drones or Yes men.  We would like to work in a more trust and empower kind of way, but it requires people to take ownership of their tasks and roles and be free thinking, not boxed and siloed.  Although recruitment is a tough market.  Luckily it's not my decision.  All I say is, how I found them technically and if I would want them working on my team next month...  even though they are very unlikely to be.  It's just a question to myself to get an honest answer from myself.

[tggzzz]

Yours sounds like an interesting company, and the kind of company where I used to work

I'd be careful that the CVs aren't being inappropriately filtered before they reach you. I've seen that happen even in companies that should have known better.

If your adverts mention specific keywords then automated systems and HR droids will tend to remove CVs that don't include the exact keyword. They won't understand that a candidate with Rust experience but not C++ experience may be demonstrating excellent discrimination

Apart from that, it does seem that many educational qualifications and company jobs have the effect of pigeon-holing candidates into rigid silos. It sounds that you need somebody with a more general background than that.

Consider locating good (whatever that might mean) university courses and concentrating your efforts there. I recently went back to my alma mater (University of Southampton) on the 40th anniversary of graduating, and to my delight found the electronics+computing courses to be just as broad and multidisciplinary as they were in my day. Example: they still let undergrads use the labs for their own private projects.

[DrG]

Yea, maybe.    Our interviews are only part of the process, it's a whole rigmarole to be honest.  The only bit I am involved in technical and values.  The other party, usually someone from the management hierarchy will ask the CV run through stuff and let me pick them on interesting points to engage them in free form technical discussions.  Then I pull from a set of fairly language/domain specific question already prepared.   I pick them as I please.  I point out that while there may or may not be correct answers, it's more about how they talk tech, how they work out problems, so if they don't know, have a go or tell me how you would find out.

I don't see the point in asking dozens of black and white tech questions and assessing people on what they know on the day under pressure.  If I ask a question and they get it wrong, but in the process they mention a dozen keywords and sensible demonstration that they have dealt with the concepts, then I take that as a good enough answer.

Our company doesn't want drones or Yes men.  We would like to work in a more trust and empower kind of way, but it requires people to take ownership of their tasks and roles and be free thinking, not boxed and siloed.  Although recruitment is a tough market.  Luckily it's not my decision.  All I say is, how I found them technically and if I would want them working on my team next month...  even though they are very unlikely to be.  It's just a question to myself to get an honest answer from myself.

A few thoughts about the situation that rattled out of my brain...

They are good questions to think about, but don’t over think your responses.

Sadly, institutional processes often seemed to me to evolve by convincing administrators that the procedures have value even though that value has little empirical validation.

Developing predictors of success is not an easy task. Often, it seems like we rely on a kind of face validity, i.e., it sounds like a good process to somebody or it simply makes some people feel better about the screening process.

I am assuming that a) these folks are much less experienced than you and b) they are younger than you. For me, there was always the challenge of realizing that they were not going to think and do things the way I thought they should be done, because “now” is a different time than “then”. Maybe you are feeling a bit of that and you are not the first or last in that respect.

Your role may be more aimed at “red flag detection” or simply a BS meter. Due diligence requires a lot of box checking. Don’t discount that function.

While not terribly relevant to your situation, it reminds me of the inevitable question on recommendation forms for graduate school admission for clinical fields (MD, Clinical Psych., etc.…); “Assuming the candidate obtained a degree, would you let this person treat you?” I freaking hated that question 

[tszaboo]

I don't see the point in asking dozens of black and white tech questions and assessing people on what they know on the day under pressure.  If I ask a question and they get it wrong, but in the process they mention a dozen keywords and sensible demonstration that they have dealt with the concepts, then I take that as a good enough answer.

Then we have similar interview process. I even give them questions that have no right answer, or it is just impossible to know the answer by heart, and I couldn't care less if they can answer it right. It matters if they come up with something to at least answer it, or they have a good guessimate.

Although recruitment is a tough market.

I haven't got any candidates for a Junior FW position in the last 3 weeks. We have a recruitment agency looking for it, plus internal HR.
Meanwhile I am approached maybe 2-3 times a week if I could write FW for some company (Hint: No, the same way, I'm also not going to deliver pizza, just because I know how to drive a car.)

Developing predictors of success is not an easy task. Often, it seems like we rely on a kind of face validity, i.e., it sounds like a good process to somebody or it simply makes some people feel better about the screening process.

I've read some study, that unstructured interviews has something like 0.3 predictor for job performance at a company.

[BBBbbb]

3-5yrs or experience could very well mean only one project (or type of projects) under their belt.
The fact that they know how to describe different things means they prepared for the interview (which in a way is a plus) and not knowing comparative (dis)advantages is due to lack of real experience - again looks normal for 3-5 yrs for most companies.

For sure you're not interviewing seniors, 3-5years should mean mostly some maturity of reasoning.
What I focused on (was in a similar situation as you recently) was that they can describe the things they put they did in their CV (don't bullshit) and how they reason when we give them some task to solve. Not necessarily looking for a correct answer, just a good thought process.

Oh and I could not care less if they have experience with Agile or whatever buzzword my company is pushing atm. Those things don't write code and don't debug if you're looking for an engineer.

[paulca]

For me it's finding the people who later bring you problems and say things like, "I tried this, this, this and that.  I'm stuck.", as opposed to, "So, what progress have you made this week?",  "None, I got stuck because I don't have access to the database."

People who when you ask about said problem can explain it concisely, or at least make an attempt rather than say, "I donno" or my favourite.  Stare blankly.

Working across different cultures is sometimes hard too.  I have found some cultures are very quick to just say, "No.  I don't know." and end the conversation there.  Other cultures will try and bullshit their way out of it.  Some cultures when you ask someone to do something and they think, "Sh1t I don't know the first thing about how to do that!", then answer with "Yes, yes Paul".  3 days later you have the same conversation again and same result.  They still don't get it.  If they would just say, "I would like some help to get started on that.", or something other than "Yes, yes Paul".

[tggzzz]

Working across different cultures is sometimes hard too.  I have found some cultures are very quick to just say, "No.  I don't know." and end the conversation there.  Other cultures will try and bullshit their way out of it.  Some cultures when you ask someone to do something and they think, "Sh1t I don't know the first thing about how to do that!", then answer with "Yes, yes Paul".  3 days later you have the same conversation again and same result.  They still don't get it.  If they would just say, "I would like some help to get started on that.", or something other than "Yes, yes Paul".

In some cultures it is considered rude to say no, or loss of face if you say no. That's why you never ask "is this the train going to X?", but do ask "where is this train going?".

An Indian manager I worked with once mentioned that "you have to realise, in India we believe in miracles".

[Sal Ammoniac]

When I interview people, I'm looking for someone with an engineering mindset--someone who can solve problems. Specific knowledge is something they can learn on the job--the field is too big at this point for anyone to know everything about everything.

With that said, I do make sure candidates know the basics before I let them pass Go and collect $200. In other words, someone interviewing with me for an embedded development position had better know C well along with knowledge of how a microcontroller works at the bare metal level. They don't need to know details about any specific MCU, however.

[paulca]

I suppose putting it into electronics/electrical engineering terms... from a software engineer perspective... this ought to be good.....

Say the current trend has been pushing more and more things into certain main chips, 90% of what you see is projects using those chips and very often assorted support chips.  They come with easy IDEs and out of the box examples for nearly everything.  With a few months working on tutorials and a few months in a project using it, you could "pass" yourself off as knowing how to deliver solutions on that platform.

The fact they only used one brand of design tools, process or they really have no idea of how to achieve the same things without the digital processor or even understand what the support passives and associated circuitry do....  Well the market says that those expensive processors are producing products faster and cheaper in the long run and they want to recruit a load of them ...   The fact they can't tell you why it's important to analysis critical path code in a latency sensitive application or tell you the downsides of using certain features as they are not performant.... or that they stuff they are using is so complex and over engineered that performance is impossible.... </rant>

[paulca]

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.

[SiliconWizard]

They seem to want to push towards minimising code by increasing architectural complexity, dependencies and overheads.  Stacking frameworks on top of frameworks for fear of having to write a few hundred lines of code.  Of course few of them understand those things beyond having followed a few tutorials and worked in a project that used it a few times.

That's been the trend for years. I'd say even for a good couple decades now... with it getting worse in the last 10 years or so.

Am I being too picky to expect critical thinking from people with 3-5 years experience?

Unfortunately, these days, yes you are.
It's particularly bad for pure software engineers. Their world has mostly evolved into this huge pile of frameworks, hype languages and trendy methods. Who cares about the fundamental concepts, requirements and critical thinking, when you got those shiny frameworks and all those user stories and stand-up meetings?

Not sure what your field is exactly, and what kind of people you are recruiting. For "embedded" software development, things are still a bit different. Candidate profiles for this have a lot more variety, with a good chunk of them having an EE background. But pure software people - very hard to deal with these days, unless you are yourself formatted the exact same way.

[YurkshireLad]

I'm guilty of this now. Too many years of working with web frameworks and I've lost many fundamentals. Now I spend most of my time fighting the tech I'm using rather than maintaining my skills. That's after 25 years of working as a software developer; maybe I'm just feeling/getting old and the mental decline has already begun.

[jeremy]

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 think this is the wrong move. I don’t think most people go into interviews expecting an adversarial process. Not everyone has the confidence to second guess the interviewer.

Also, your problem is ill-defined, as-is I don’t see why it is impossible. There is even a built-in python function which does it all for you (iteratively, so you don’t run out of memory): https://docs.python.org/3/library/itertools.html#itertools.combinations

[tggzzz]

They seem to want to push towards minimising code by increasing architectural complexity, dependencies and overheads.  Stacking frameworks on top of frameworks for fear of having to write a few hundred lines of code.  Of course few of them understand those things beyond having followed a few tutorials and worked in a project that used it a few times.

That's been the trend for years. I'd say even for a good couple decades now... with it getting worse in the last 10 years or so.

I don't mind people using frameworks (and often it is preferable to re-invention of an elliptical wheel), but I do want them to understand what a framework cannot do. Too often people use frameworks and think they no longer need to think about failure modes, because the framework deals with it. It is remarkable how many frameworks have solved distributed ACID transactions, the byzantine generals problem, the split-brain problem, and have managed to ensure there is a single global unique time.

For wry amusement, consider the layering of asynchronous protocols on top of synchronous protocols, and vice versa.

[Slh]

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 ...).

My main technical competence question is supposed to get the candidates to show that they know the fundamentals (some equations, some knowledge of how to apply them etc) even if they don't get the answer or need some prompting. When they get to the answer it's also a really useful result that's worth knowing. One "principal" engineer tried to tell me that the current when charging a capacitor is constant for 2 tau (and reduced thereafter) and that power was the same as energy... He seemed annoyed by my attempts to push him in the right direction so I guess the question did a good job showing technical level and attitude...

Asking them to describe a project they've worked on is usually good as well (and having usually beaten them up on the fundamentals it gives them some nice home ground to work from). From that you can hopefully get an idea of what they've done, enthusiasm and what they're likely to be able to bring to the team.

[Fgrir]

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 think this is the wrong move. I don’t think most people go into interviews expecting an adversarial process. Not everyone has the confidence to second guess the interviewer.

Also, your problem is ill-defined, as-is I don’t see why it is impossible. There is even a built-in python function which does it all for you (iteratively, so you don’t run out of memory): https://docs.python.org/3/library/itertools.html#itertools.combinations

There is only one combination of a shuffled deck of cards and writing a program to generate it should be trivial.

Now permutations is another story, or combinations of a 5-card hand dealt from the deck...

[Brumby]

There is only one combination of a shuffled deck of cards and writing a program to generate it should be trivial.

Now permutations is another story, or combinations of a 5-card hand dealt from the deck...

I would't respond like that.  You would risk being labelled a smart-arse.

[paulca]

There is only one combination of a shuffled deck of cards and writing a program to generate it should be trivial.

Now permutations is another story, or combinations of a 5-card hand dealt from the deck...

I would't respond like that.  You would risk being labelled a smart-arse.

This is the point.  It forces a decision, a choice, a thought process, even an opinion.  I find those qualities more lacking than the technical 'does this do that'.

Too often I find people almost brain washed into their silo of one framework, one mindset. 

As one specific; when you ask Java developers about any negatives with "their" frameworks on performance including memory load or any kind of efficiency they go blank.  The same candidates when then tell their stories of high performance networking talk of 100s or 1000s of message or responses per second and latencies of milliseconds.  When you point out, your domain is deal with microseconds.  Their multi-threading/performance understanding pales.

I interview from junior to 5+ years specific roles.  However I would expect a 2-3 year Software enginerr to have some understanding of the costs of such "frameworks".  And all I see is they simply don't understand at all.  They don't understand the maintenance overheads, the debugging overheads... yada, yada.

It just makes me worry I'll end up cleaning up after them.

[paulca]

At the same time, customers love them.  Throw a PoC together in 2 weeks, consider it production ready.... why can't we have MORE younger inexperienced people in our team, they get stuff done.

[nigelwright7557]

Sometimes people are looking for someone who knows it all when a lot of the time you dont need to know it all.
I have been writing software for 40 years, the first 20 without any training and all my systems worked.

Been in electronics 40 years too. Only got City and Guilds in industrial electronics yet designed many computer systems.

In 1983 I was given the task of writing some Teletext software yet had very little experience of Z80.
When your given a serious task you learn very quickly or give up.
The reason I got the job then was because programmers were then thin on the ground or what there were, were expensive.


These days its harder to get away with knowing little.
To even get a web programming job you have to meet a long list of prerequisites.
HTML, ASP, CSS, bootstrap, java script, entity framework, SQL server, mysql etc etc

[Kjelt]

My biggest concern with the young generation is to keep them interested to stay.
We have only huge piles of spaghetti C code to maintain that has been developed over decades and most of them are not interested in C programming.
They want "cloud dev", "big data", C#, they walk out after a few months.
We can't get the message through to HR to tell them at the interview what to expect, prepare them for our department.

We get a new colleague each quarter and we keep loosing them worst case a quarter later, best case a year later.
The funny part is that the managers also leave every 14 months, the last one had a record at 5 months before jobhopping to the next step on the careerladder.
Time to ask for a big salary raise to my current manager, if I and my two colleagues who have been there for the last ten years walk, the product  is dead   

[Nominal Animal]

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'd fail, then, because I'd give you a function that takes a 226-bit unsigned integer (0 to 52!-1, inclusive), and returns a deck with that particular order.

The reason is that generating all combinations in a sequence is rarely useful, but being able to generate any specific combination (here, any specific configuration in the 52! -point configuration space), i.e. any one of all the combinations, can be useful.
In particular, when examining how some specific patterns of shuffling affect the deck order, how long loops they generate, and how large a fraction of the available deck configuration space the shuffling can cover.

Even after decades of experience, I still fare so much better when I'm presented with an actual, real world problem, and can solve that one instead.