I think his average stay was maybe 9 months which is not unreasonable for consultants. My guess is they were all charmed by the CV and didn't interview him thoroughly enough.
Or your analysis is wrong and he didn't need to know a single keyword in C to be fantastic at his job. i.e. if this is the truth then if we re-run history but you spontaneously accept an excuse and let him skip your technical interview, you might have been extremely satisfied with his work and input with you over the next 9 months.
We have a couple of things to analyze here: 1) could this have happened? 2) in this case would your satisfaction be false, i.e. he wouldn't have been doing good work for you over the next few months?
Or is there a chance that he had some skills that didn't require knowing any coding, while being able to contribute valuably to you...
Or maybe he's old enough that he's used to thinking in assembly. I learned firmware on 8051 assembly, I've used C mostly since then but always with a reference, and only the last few months finally am getting into C++.
That doesn't mean I don't understand how firmware works. I know what's going on deeply under the hood, and I understand systems architecture. I know how to debug the stupid SPI interface when you're talking to an Analog Devices ADC that just won't respond for no clear reason. I know how to read the datasheets for parts and pick reliable ones that can be sourced readily and have sane interfaces.
I have no idea what a linked list is. I do know pointers, but not super well, I just know that they're a spot in memory that gives you the address of another spot in memory, like the program counter. I know my limitations, I'd never try to interject in dealing with a system that has a full OS on-board, and I'd refer questions about encrypted bootloader based firmware upgrades to someone who knows what they're doing. But I still know what Mode 2 SPI is, and the typical noise levels on different kinds of shielded cable. That's not nothing.
shrug
I think the best way to determine if someone is a decent engineer is to get them talking about previous projects. If all they can do is talk about it at a high level and they don't seem to have any real knowledge of the implementation details, they didn't do the work themselves. I once had a guy who claimed to be an instrumentation engineer, but didn't know (even vaguely) how you would go about measuring temperatures in a process you're dealing with. I could be wrong (often am), but anyone who has done instrumentation but has never encountered a thermocouple... well, that would be a very unusual history.
> Or maybe he's old enough that he's used to thinking in assembly
"I'm sorry, I don't actually know C, can I show you this in assembly instead"?
> I have no idea what a linked list is.
I cool thing about the linked list is that it's probably the simplest data-structure in all of computer science. I can explain to you what they are in less than 30 seconds, provided you have even the faintest grasp on how computers actually work.
> I could be wrong (often am), but anyone who has done instrumentation but has never encountered a thermocouple... well, that would be a very unusual history.
This is exactly what I'm talking about: A good programmer who can't understand and reason about a linked list, that's very unusual.
Haha, thanks for the schooling. I looked it up and it turns out I studied them in scheme back in the day. I just didn't know the term, so I'd (probably) come off as incompetent in an interview where asked.
> This is exactly what I'm talking about: A good programmer who can't understand and reason about a linked list, that's very unusual.
Well put then, I say rather chagrined ;-)
My intended point though was that sometimes you can't tell how good of an engineer someone is by asking them about things you know. Better to ask them to talk about what they know. But that's not very controversial I'd hope!
Your entire comment seems to hinge on the assumption that the GP wasn't hiring for a C programming job. That's pretty disingenuous.
Or do you really find it plausible that people who don't know a single keyword in C can be "fantastic" C programmers? Or that it's a good idea to hire very, very nice people who can program for programming jobs because they might have other skills that might be valuable?
Sorry I'm still not in industry, but isn't there a review system for past employees, and specially for past consulting work? This would be extremely valuable for future employers, problems with lies and uncertainty notwithstanding.
It looks to me a few amazon-style 10 minute reviews could save many many hours of HR rumblings and expenses.
No, people are too lawsuit-crazed these days. Many companies will give no facts about a past employee other than the dates they were employed. Even "would you hire this person again?" can be dangerous.
At one of my past employers, my manager (who sat next to me) told me that he wasn't allowed to say anything whatsoever about past employees - when anyone called to confirm past employment he had to give them HR's phone number, where specially trained operatives would presumably answer the one and only question allowed.
We do all development in 95% C and 5% assembly. While not with him, I have given people chances at other times and they fail miserably if they don't have basic C programming skills.
