General > General Technical Chat

Giving interviews, disappointing, am I getting old?

(1/7) > >>

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.

Navigation

[0] Message Index

[#] Next page