Out of necessity, tech startups are changing the way workers are hired

Interviewer: "So, we'll start with some really simple questions on the stuff on your resume. How do you concatenate two strings in C?"

Interviewee: "With a dot?"

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?

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.

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.

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.