Tech startups are at least partly to blame for this as well. I've seen so many job postings requiring years of experience in exactly the same combination of technologies the company itself is using. I know it's harder to hire people for their innate abilities than it is for the number of years they've done rails or django or rspec but if you're going to be that inflexible you've got nobody but yourself to blame for the empty desks.
I think you are adressing job postings in the wrong way. See it more as a wishlist and not as something with hard limits.
Sure, you still have to be able to fit the role they want or replace someone else that can fit the role, but don't overestimate the importance of the requirements.
There might be a case to take them really serious if the job posting really differentiate between what the candidate have to know and what they wish for. Other than that, don't take them too hard.
> There might be a case to take them really serious if the job posting really differentiate between what the candidate have to know and what they wish for.
That is the problem. Very many of them say things like "flash in the pan technology X a must" or "latest silver bullet Y mandatory". They are basically advertising that their start-up only hire liars and people who actually believe management consultants. And then they are surprised that all the good people run away screaming.
RethinkDB says "For that matter, you think SQL is a terribly designed language." Oh, dear. Refined by the hardest of the hard-core engineers for half a century, foundation of the world economy, and they only want people who have an ironclad, dogmatic belief that it is unconditionally terrible. Good luck recruiting actual information retrieval experts, guys.
It's exactly the same problem we are facing. When the job requires very high technical skills its a dead end. I am looking for talented kernel engineers. If I go for employing someone high caliber, the costs would be in the 100K >= range. Not a smooth option for a startup. Also it's still hard to attract them even if you pay well. If I go for contractors, there is the problem of IP disclosure. Contractors are probably worse; you disclose IP, pay more, and they disappear after certain level of training investment. You are back to square one.
If you get someone with lesser talent, (done twice, and parted ways after several months) it's also terrible. In this case you usually pay for nothing. E.g. a month of struggle with code, reaching nowhere, dumping their code. This happened a few times.
The hiring is also key. If you have 8 high-caliber engineers, it means you get many times more done. What you could do in one year is done in, say 3 months. A huge difference for a startup.
I have been thinking about hiring talented grad students like they did, maybe that's the best way to go. So its really a tough problem with no straightforward solution.
From the article: We try to ask about the difference between cooperative and preemptive multitasking.
I ask what is kernel preemption. Silence. A blocking mutex and a spinlock? Silence. I think a good candidate should know what event-based and threaded programming means, and even go further to explain the implications and best scenarios for both. Its not easy to get that far.
Sounds like simple economics: if you can't afford to pay people in cash and your start-up doesn't look attractive enough that options look attractive then you won't be able to attract the talent.
"When the job requires very high technical skills its a dead end."
That's a very highly 'mixed' situation: I hold a Ph.D. from a top research university in some very technical material, with a lot of connection with computing, and have published peer reviewed original research in some topics where, thus, I am a 'world-class' expert in those topics, and I can absolutely, positively guarantee you that (1) in a 'job interview' in such a topic I will totally blow away the interview questions and (2) really know so much that the interviewer will feel 'rejected'. So, I won't get hired.
Uh, we're still back 100 years ago where the person hiring insists on knowing more and won't hire anyone who doesn't know less. In particular, the person hiring wants the new person to look just like the person hiring wants, including what the hiring person does NOT know.
This situation is very general: For a person with "very high technical skills", there is essentially no way to get interviewed or hired. There is no way for that person to expect someone else to understand those skills or have a job for them. The academic solution is for such a person to publish papers and, then, have others just count the papers, prizes, grants, whatever -- never try to read the papers. In business there is really just one solution: Have the person with such skills start their own business.
So, there really are people with "very high technical skills", but they essentially can't be hired, that is, they are unemployable.
For a hiring manager to insist that their particular list of skills, some good, some actually 'bad', are just the 'right stuff' is a mistake of the hiring manager.
Of course I don't know you, but my impression based solely on this post is that your missing skill might be getting knowledge across without making the person you're talking to feel bad. That is, coming across as a patient, friendly teacher without being condescending. People like that are worth a lot.
The "I'm more technical than you" game is commonly played in hacker circles but encourages us to behave badly.
"kernel"? For WHAT operating system(s)? Or do you just expect them, naturally, to be expert in all of them, so little their efforts are worth, so great your cash is worth?
Then for WHAT work? Writing device drivers? Tweaking the TCP/IP stack? New, tricky things in video? For WHAT?
Here is the general situation: A successful information technology startup is a RARE thing, among entrepreneurs, businesses, and even information technology startups. So, you are trying to do something RARE. So, being rare helps you attack a part of the market not attacked well now and have a barrier to entry, etc. But the 'flip' side of this is that getting people to do the work for you will be difficult.
Or, if very many people knew how to do what your startup is doing, then your startup would be in serious trouble.
Net, if you have a good startup, then hiring people to do the technical work will be from difficult to impossible.
To be more clear, your 'idea' where you want all the technical work done by others doesn't amount to much.
Here's what you are missing: You need to do the hard technical work yourself.
Uh, for the person you want to hire, they didn't just sit around studying for the past 15 years getting ready for your startup. And if they are deep into the internals of the kernel of some operating system and not a company founder, then they about have to be in a big company where they are likely reasonably well valued and compensated.
A long, very general lesson in computing is, if you want someone expert in just the topics you have in mind, then basically you have to PAY them to LEARN those topics. Sorry 'bout that.
Back to Mother Goose, you look like The Little Red Hen who wants to hire the other chickens to do the clearing, plowing, sowing, cultivating, harvesting, threshing, brick laying, milling, mixing, rising, and baking while you own the business. Nonsense. The Little Red Hen did all her own work -- do yours.
For the Slate article, that was written by a 'writer' who writes on law, etc. So that writer likely doesn't know much of anything about computing. So, likely all the writer did was find the two startup persons, interview them about their struggles, and then make a 'story' out of it.
But the 'story' doesn't make much sense; nearly all the comments to the story make more sense.
For the recruiters, sure, they don't know dip squat or jack sh!t about computing. That's a special case of the more general situation: If you want to hire specialists, then you need specialists to evaluate people. Then both the people you want to hire and the people to do the evaluations are rare. So, basically the evaluation has to be done by the hiring manager, and that manager needs to know the technology quite well or make the new person a co-founder.
This whole subject just reeks of a nasty attitude: For any project, there are rivers of highly qualified people, with whatever specialities we need, who spent the last 15 years becoming expert in what we decided last week we need, and they will be grateful to move half way across the country for our semi-, pseudo-, quasi-promising job.
The really rich one was when Java first came out and the recruiters were looking for people with five years of Java experience! Gee, just call up Gosling, although then he may not have had such experience!
Nonsense. Special case of, mostly there is nonsense. Necessarily high success is rare.
For my startup, I am doing ALL the significant technical work myself, with my own ten fingers. I am making sure that any people I will have to hire will need only very routine qualifications. The good news is that I know in fine detail, documented in fine detail, ALL the significant technical work. Some bad news is that doing all the work myself takes longer. But, nearly all the work is just learning the tools: So, read for a week and write code for half a day, and document for a half a week. Sorry 'bout that.
Just do it yourself.
Finally, you are writing about essentially the subject of 'concurrency' in operating systems. I've never written an operating system, but I have done some significant work on concurrency, enough to understand monotone locking protocols, deadlock detection and resolution, and 'fairness'.
For your "cooperative and preemptive multitasking" it seems to me your terminology is not both well defined and common. So, it looks like you are deliberately asking tricky questions. I could guess at what you mean and answer that, but still your question is vague.
Also, any significant chunk of software that wants to do much with concurrency needs something of a well designed 'architecture' for concurrency. So, just what such architecture a particular operating system has is open to question; can't expect one person to know them all.
Similarly for your "kernel preemption. A blocking mutex and a spinlock". Again I can guess, but I doubt that your terminology is both well defined and common. I remember what a spinlock was in MVS, but that was a long time ago, and I have no idea if any other operating system ever did any such things.
Gee, you omitted Dijkstra semaphores!
If you want people who understand some things about operating system software development and concurrency, for specific parts of a specific operating system, then focus on those topics.
Are you looking to build a business or to pump up your own ego by claiming that no one else is qualified to do your work?
They asked this on RethinkDB interview. I found a similarity and just mentioned it. FYI its a pretty common terminology.
I also don't care what you think about my ego. I made a candid post for a problem I am facing. If you criticize that's very welcome but try to make it a bit constructive.
On your ego, I;m just guessing. It's a common failing.
Broadly you seem to be recruiting a bit too close to the ground, to be straining over gnats and forgetting elephants. E.g., my best work in concurrency was at the Watson lab in Yorktown Heights. We had NO trouble hiring people with lots of smarts, knowledge, talents, and determination. When I interviewed people, I asked more general questions. So for concurrency, ask about some really solid topics in the field.
You gave a URL on your terminology: I still don't think that the terminology is both solid and common enough to use in an interview. Indeed, I would guess that a real expert in concurrency, e.g., a recent CS Ph.D. who did their research in the field, would not use such terminology. What a Dijkstra semaphore is is solid. So, might ask about that. I don't think your terminology is good for recruiting real expertise.
> Similarly for your "kernel preemption. A blocking mutex and a spinlock". Again I can guess, but I doubt that your terminology is both well defined and common.
Really? That's standard terminology and I could define both in few sentences and could fresh out of college. I don't do OS development (and while I've tweaked a few lines in the kernel source, I'm not a kernel hacker by any means), but I understand the differences between spinlocks, event loops and blocking on mutexes (it's a core part of userland systems/network programming).
I highly suggest picking up Andy Tannenbaum's "Modern Operating Systems" (the MINIX book is excellent too, but is more about "the right way" to build an OS with a microkernel etc... rather than a case study of what exists). It's accessible and meant as an undergraduate text and will give you at least a cursory overview of these issues. It just seems like you had a bad professor for your operating systems course.
I've taught computer science in ugrad and grad school but only took one course, that AFTER I taught the ugrad course, and it was a silly course.
I know more than I indicated, but I wanted to say that the questions need to be more clear, Yes, preemptive is like handling a keyboard interrupt. Mutex likely stands for 'mutual exclusion' and typically is supported by a library with various features. Spin locks were an old IBM trick where it actually was faster to let a 'task' just go into a loop on something than use something like a Mutex that would involve the dispatcher -- the dispatcher could be slow. But spin locks had a bad reputation for spinning forever and were a standard system managment problem.
I'd advise the hiring guy first to get a book, maybe like you listed, and go to a university with a good CS department and buy a hour with a good OS CS prof and get an outline of what he needed to hire.
You are laying out certain facts well; if you are doing rare work on an expert subject its unlikely that anyone with the expertise will risk their time and career with your work.
But I have not anywhere suggested that I am not willing to do the hard work. In fact it's exactly the opposite. I am doing all the hard technical work that is sometimes too much. So what do you do? You look to transfer some of it to someone else. The fact is however, only the smallest bit of hard work requires so much that you might as well do it yourself by adding an extra 1 hour to it rather than wait for someone to do it, communicate, and get it done in a week. So you look for expertise.
And you don't have to know the details of a specific kernel or a TCP/IP stack. A very good C programmer in general will do well enough.
The other trait that is highly acceptable is not knowing a lot, but being hard working and enthusiastic. We have one engineer like this who knew nothing and in 1 year he is a wizard in linking, build systems, python, locking, drivers ... I am all up for teaching patiently, but finding someone who has that vigor and enthusiasm is also very hard.
To your do-it-yourself suggestion. You need to acknowledge the problem of scalability and look for ways to expand your team because you are then a scalability bottleneck. I am not saying I know how to do it, otherwise I wouldn't be doing the earlier post. But I am at least considering ways to fix it.
Now you are getting a little closer to reality: You paid a guy a year to learn.
For your "A very good C programmer in general will do well enough.", that sounds wrong: C is just Brian W. Kernighan and Dennis M. Ritchie; sorry 'bout that; for "C", it's just that one, thin, 'idiosyncratic' book where I still can't make sense, parse the syntax, out of an arbitrary 'declare' (I borrow from PL/I since C likely has no good terminology) statement.
C in Kernighan and Ritchie is a DIRT SIMPLE language. In particular, there is NOTHING, not a single line anywhere, in the language on concurrency.
Being a "very good C programmer" is a bit vague: To get very far in C, about have to dig into material definitely not in the book and likely not standard or even well documented.
In C one place I started screaming was all their talk about "the heap" and malloc(). Their 'heap' likely has nothing to do with the heap data structure in 'heap sort', and they never said what their heap was or how malloc() worked. I've done things in dynamic storage allocation, and not knowing the details, ANY of the details, of what C does was a BUMMER. I couldn't hope to design serious software, especially for an operating system with concurrency, without knowing in fine detail just how malloc() and free() worked. Not a chance.
Note that Microsoft just gave up: They know that their Visual Basic .NET, C#, common language runtime (CLR), etc. just MUST work for long running, serious, production applications. So, there, first-cut, it is CRUCIAL to let programmers not have to worry about memory leaks. Second, even worse, Microsoft had to find some dynamic memory allocation that didn't have the memory of the application just grow slowly over the days and after two months have the program slow to a crawl or just die. So, they went for the gold standard solution: MOVE the data in memory and do full 'garbage collection'. Some questions remain, but so far my timings indicate that it at least mostly works. Just dynamic memory allocation AIN'T easy, ESPECIALLY in an operating system that we want to run for months or years.
Next, for threading in C, maybe go to the Posix things. Again, that's not really just C, i.e., as in Kernighan and Ritchie.
Next, in C there's the 'stack': To get very far using C, very much need to know a LOT about the details of 'the stack', especially for anything with concurrency in an operating system, but the details are not easy to find and likely not even standard. Uh, do some moving of data in memory and totally mess up some stack pointers!
E.g., I could never find any decently clear details from C compiler or linkage editor documentation on just what the 'stack limitations' were or anything about 'stack overflows'. All clear as mud. The hope is that such things just won't happen, and for serious code that's DUMB. Special case of a general situation: For serious software, even just in applications, CERTAINLY in an operating system, C is DUMB.
Then there's the really big elephant in the room on using C for concurrency in an operating system: WTF does C do with an interrupt or an exceptional condition? The broad problem is freeing various 'resources' and popping back the 'stack' of 'dynamic descendancy' (another term from PL/I internals), but Kernighan and Ritchie provide no documentation about C to let one design how to do such things.
So, as a serious language for concurrency and serious work, say, in an operating system, C just SUCKS because of lack of solid features and documentation. Write trivial little word whacking 'filters' as in Kernighan and Ritchie, sure. The last C I did was as Microsoft .NET 'unmanaged' code called from Visual Basic .NET 'managed' code using 'platform invoke' -- what I did looks solid enough, but I want to avoid that subject like a barrel of poisonous snakes.
If I'd had to do much with C, then I'd have screamed myself hoarse.
Somehow I suspect that concurrency has made progress past, say, just
C. A. R. Hoare, 'Communicating Sequential Processes',
now in PDF near the top of a Google search. So, if you want some expertise in concurrency, then get someone who had a recent, solid course in the subject, did well in it, has applied it, and maybe has done some serious work with it.
Concurrency is now a newly, very hot topic due to many cores, Web sites with tens of thousands of user 'sessions' at once, corresponding loads on data bases, MemCache, etc. The latest I heard was that there are some fairly serious concurrency bugs in some of the most important 'frameworks'. Going forward, doing much with concurrency will be a challenge. Such work will just scream out for some totally rock solid 'proofs of correctness' -- and major applications of keep it simple, stupid -- since there is no hope even in heaven of duplicating failures from bugs. Zip, zilch, zero hope.
Mostly what people are trying to do is to get some better concurrency 'primitives' way above interrupts with save and restore registers, spin locks, Mutexes, even 'transactional' topics like deadlock detection and resolution, and give programmers some robust, easy to use tools that actually work.
For how to modify an operating system, looks like you should get with whoever owns the operating system and what their 'guidelines' e.g., on concurrency primitives, etc., are for modifications.
Again, part of success is good problem selection. So, if you can't do all the significant technical work yourself, then either you didn't pick a very good project or have one boatload of money and time to recruit, select, hire, relocate, train, and manage people.
C is just a thin wrapper around raw machine code, so naturally most of the details depend on the implementation. When a good C programmer wants to understand the stack, he leaps straight for the system documentation and source code for the target architecture. (A file named something like "crt0.s" or "fork.c" is a good place to learn how the stack works and where it comes from.) K&R is just background reading.
here an idea, hire a very very very good programmer or world-class talent, however you want to name them, and yeah pay them the dough that they deserve.
And have them train/teach those rookies.
that is called: "building a team"
it always amuse me to see some people thinking they can get away having the cream and the butter for a cheap price.
I think the other way around is also hard, many startups require such diverse combination of skillsets that its hard to know what you should learn in order to be hirable. As college grad student I have no clue what to learn to get hired by an "exciting" company. The only way seems to learn either the .net or the java platform as "safe" path, which in turn these exciting companies are not looking for.
This article is a bit of a contradiction. On the one hand, it says:
"Unemployment is chronic in much of the country, but in Silicon Valley, employees have their pick of jobs."
Then on the other hand it says:
"And in four months, the hundreds of resumes, dozens of phone screens, and numerous four-hour meetings with viable candidates yielded no one who fit their criteria."
This tells me that the easy job market is there if you are a star. No so much if you're just 'competent'. But the 'stars' have an easy job market in any industry.
This company has the same problem as the New York Yankees. The Yankees have an opening for .350 hitter and it's very difficult for them to find qualified talent.
Similar problem, but it's worse in Silicon Valley. At least the Yankees will pay what you're worth if you 'fit their criteria'.
