> And just to quench my own personal curiosity, since you're on the hiring side and I'm not: why is it that every company absolutely must find someone who fits the bill exactly? What is with this aversion to spending any amount of time training people?
We don't have an aversion to training, but when someone has supposedly 8+ years of development experience and cannot answer simple questions, well, on to the next candidate.
I personally do always look for potential, I believe it is the most important aspect when hiring. But potential means having a drive to learn independently. I really do understand why a lot of employers are just saying "screw it" and not hiring anyone who isn't on Stack Overflow, or has a tech blog, or some sort of presence that said "I am passionate about this field."
(I'd be doomed by that metric, I don't have a github or Stack Overflow account! I'm on this site and /r/programming, however I do have a somewhat maintained tech blog.)
> As for knowing how malloc works: fewer and fewer universities are even touching C. It's all C++ or, better yet, Java (no need to understand memory management _at all_ in that case). The only guys left that are into reimplementing malloc are the minority of Computer Science or Computer Engineering graduates that are into embedded work or HA scenarios.
Ugh I know. My college still teaches native, and in fact the majority of the curriculum (last time I checked, its been a few years) was native, but they are unfortunately the exception to a general trend.
The thing is, managed languages are pretty damn nice for teaching software engineering principles in, but bad for hands on "this is how it works" explaining.
Covering how the JVM or CLR does stuff on a PowerPoint slide isn't the same thing as having students write an allocator. Which sort of sucks when they go on the job and have to write an allocator!
I wonder if your hiring process isn't more narrow and exclusionary of independent learners than you think. It is really quite easy in 2013 to have racked up 8 years of real high-quality development experience without having any idea how memory allocation works at a detailed level. For some portion of the people with 8 years experience it will be easy for them to go and independently figure out how it works and for others it won't. You want people in the first group, but you can't find them just by asking them questions about memory allocation.
(Also, do you do something having to do specifically with memory allocation or is it just your pet entry on the list of things you think everybody should know about to not be dumb?)
Honest question: what field are you in which means your candidates are going to need to write custom allocators on a regular basis?
What problems need custom allocators? I'm a fan of lower level details and all, but surely you can get away with one of the many existing allocator implementations when the problem to be solved isn't "sudo make me an allocator"?
> Honest question: what field are you in which means your candidates are going to need to write custom allocators on a regular basis?
Embedded. :P
> What problems need custom allocators? I'm a fan of lower level details and all, but surely you can get away with one of the many existing allocator implementations when the problem to be solved isn't "sudo make me an allocator"?
Memory is being counted in kilobytes. Processing time in cycles.
I'm loving it, but finding others who feel the same, and who are serious about software engineering, isn't easy!
>who feel the same, and who are serious about software engineering, isn't easy!
So what you're saying is that you have a hard time finding people experienced and passionate about your extremely small niche? I'm sure I'd have a hard time finding qualified child neurologists willing to work for < 200k as well.
I'd hardly call embedded work an extremely small niche. Now, what he's doing on them may or may not be. But microcontrollers on the whole are a much bigger industry than personal computing. You'll find many more 8-bit and 16-bit microcontrollers in any given house than you will Intel or AMD 32/64 bit general purpose microprocessors. Last I checked approximately half of all CPUs sold globally were 8-bit.
Have you (or your company) given any thought to telecommuting? I know of one software engineer who would love to return to the embedded space, but would not be willing to move (he is right now, on a "working vacation" for the next three months some six times zones away from his current place of employment; his employers put up with this because he is that good at what he does).
Heck, I might be interested in the embedded space. I certainly have experience with Assembly language (several different CPUs) and C (for twenty years now). It would certainly be a change from testing call processing.
Covering how $a or $b does stuff on a PowerPoint slide
isn't the same thing as having students write a $thing.
Which sort of sucks when they go on the job and have to
write a $thing!
That statement is true for many different projects in many different niches. Colleges can't possibly teach them all. If they try, then classes spend less time on CS fundamentals and employers are unhappy. If kids learn about $thing, that means less time for theory and employers are unhappy. (Not to mention that practically speaking, less time on theory means they won't be passing "top tech" interviews at all.)
"We need people who know $thing" does not imply that "colleges should teach kids $thing" is true. Is $thing important because you know it and use it, or do you know it and use it because it's important?
> That statement is true for many different projects in many different niches. Colleges can't possibly teach them all. If they try, then classes spend less time on CS fundamentals and employers are unhappy.
Well yes, very true, I believe in fundamentals.
But the 3 types of common memory storage (stack, static, heap), and how each is commonly implemented, seems like it should be covered. :)
Likewise, common GC algorithms should also be gone over!
CS curriculums really are over stuffed, just from a theory point of view there is so much that is already not covered.
We don't have an aversion to training, but when someone has supposedly 8+ years of development experience and cannot answer simple questions, well, on to the next candidate.
I personally do always look for potential, I believe it is the most important aspect when hiring. But potential means having a drive to learn independently. I really do understand why a lot of employers are just saying "screw it" and not hiring anyone who isn't on Stack Overflow, or has a tech blog, or some sort of presence that said "I am passionate about this field."
(I'd be doomed by that metric, I don't have a github or Stack Overflow account! I'm on this site and /r/programming, however I do have a somewhat maintained tech blog.)
> As for knowing how malloc works: fewer and fewer universities are even touching C. It's all C++ or, better yet, Java (no need to understand memory management _at all_ in that case). The only guys left that are into reimplementing malloc are the minority of Computer Science or Computer Engineering graduates that are into embedded work or HA scenarios.
Ugh I know. My college still teaches native, and in fact the majority of the curriculum (last time I checked, its been a few years) was native, but they are unfortunately the exception to a general trend.
The thing is, managed languages are pretty damn nice for teaching software engineering principles in, but bad for hands on "this is how it works" explaining.
Covering how the JVM or CLR does stuff on a PowerPoint slide isn't the same thing as having students write an allocator. Which sort of sucks when they go on the job and have to write an allocator!