Giving interviews, disappointing, am I getting old? - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: October 20, 2021, 10:53:33 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2021, 11:02:35 am
content: 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 betterI 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

author: tszaboo
author_rank: Super Contributor
timestamp: October 20, 2021, 11:27:25 am
content: 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".

author: paulca
author_rank: Super Contributor
timestamp: October 20, 2021, 12:21:50 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2021, 12:55:35 pm
content: Yours sounds like an interesting company, and the kind of company where I used to workI'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 discriminationApart 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.

author: DrG
author_rank: Super Contributor
timestamp: October 20, 2021, 01:17:03 pm
content: Quote from: paulca on October 20, 2021, 12:21:50 pmA 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

author: tszaboo
author_rank: Super Contributor
timestamp: October 20, 2021, 02:21:56 pm
content: Quote from: paulca on October 20, 2021, 12:21:50 pmThen 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.Quote from: paulca on October 20, 2021, 12:21:50 pmI 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.)Quote from: DrG on October 20, 2021, 01:17:03 pmI've read some study, that unstructured interviews has something like 0.3 predictor for job performance at a company.

author: BBBbbb
author_rank: Unknown
timestamp: October 20, 2021, 02:47:36 pm
content: 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.

author: paulca
author_rank: Super Contributor
timestamp: October 20, 2021, 03:01:38 pm
content: 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".

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2021, 03:42:17 pm
content: Quote from: paulca on October 20, 2021, 03:01:38 pmIn 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".

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 20, 2021, 03:54:53 pm
content: 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.

author: paulca
author_rank: Super Contributor
timestamp: October 20, 2021, 06:55:46 pm
content: 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>

author: paulca
author_rank: Super Contributor
timestamp: October 20, 2021, 06:58:16 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 20, 2021, 07:21:12 pm
content: Quote from: paulca on October 20, 2021, 10:53:33 amThat'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.Quote from: paulca on October 20, 2021, 10:53:33 amUnfortunately, 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.

author: YurkshireLad
author_rank: Frequent Contributor
timestamp: October 20, 2021, 08:07:44 pm
content: 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.

author: jeremy
author_rank: Super Contributor
timestamp: October 20, 2021, 09:19:27 pm
content: Quote from: paulca on October 20, 2021, 06:58:16 pmI 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

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2021, 11:33:48 pm
content: Quote from: SiliconWizard on October 20, 2021, 07:21:12 pmI 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 frameworkcannotdo. 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.

author: Slh
author_rank: Regular Contributor
timestamp: October 21, 2021, 09:36:11 pm
content: 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.

author: Fgrir
author_rank: Regular Contributor
timestamp: October 21, 2021, 09:40:00 pm
content: Quote from: jeremy on October 20, 2021, 09:19:27 pmThere 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...

author: Brumby
author_rank: Unknown
timestamp: October 21, 2021, 11:31:33 pm
content: Quote from: Fgrir on October 21, 2021, 09:40:00 pmI would't respond like that. You would risk being labelled a smart-arse.

author: paulca
author_rank: Super Contributor
timestamp: October 22, 2021, 09:20:34 pm
content: Quote from: Brumby on October 21, 2021, 11:31:33 pmThis 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.

author: paulca
author_rank: Super Contributor
timestamp: October 22, 2021, 09:24:02 pm
content: 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.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: October 22, 2021, 09:33:06 pm
content: 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

author: Kjelt
author_rank: Super Contributor
timestamp: October 22, 2021, 09:51:15 pm
content: 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 22, 2021, 11:08:07 pm
content: Quote from: paulca on October 20, 2021, 06:58:16 pmI'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 howsome specific patterns of shufflingaffect 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.

author: james_s
author_rank: Super Contributor
timestamp: October 22, 2021, 11:17:54 pm
content: Quote from: paulca on October 20, 2021, 06:58:16 pmI 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.

author: james_s
author_rank: Super Contributor
timestamp: October 22, 2021, 11:27:13 pm
content: Quote from: Slh on October 21, 2021, 09:36:11 pmI 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.

author: station240
author_rank: Unknown
timestamp: October 23, 2021, 06:49:46 am
content: Quote from: paulca on October 20, 2021, 10:53:33 amQuote from: paulca on October 20, 2021, 10:53:33 amAh 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.

author: rstofer
author_rank: Super Contributor
timestamp: October 23, 2021, 10:07:57 am
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: October 23, 2021, 11:28:31 am
content: Quote from: rstofer on October 23, 2021, 10:07:57 amThat 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 24, 2021, 05:25:01 am
content: 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.