The founders are taking all the risk, getting slammed by investors, and probably have put in more hours and more capital than you ever will. Zoom out a bit and their chances of failing is 90%.
The people that are very successful today all started somewhere. Many of them started at a startup, built something, and made a name for themselves. In their 30s, they are now in demand execs who have proven track records of building out teams and products.
At the end of the day no one is going to give you 50% of a company, not test you to see if you can write code and think logically, and not check to see if you are a good cultural fit in an early stage startup. It sounds like this a huge issue for you so you have two choices:
1. Go do your own startup.
2. Turn down the job and work somewhere else.
3. Go work for some mega-corp that pays you well.
In the end, you are just spamming the board with your pointless posts.
"The founders are taking all the risk"
No, they're not. One could just as easily work at a stable job. Instead, they're taking a bet on the founders' vision.
"getting slammed by investors"
That's their job. They need to grow up. As an engineer, we get slammed by other engineers. Criticism is a good and necessary thing.
"probably have put in more hours and more capital than you ever will"
Capital yes. Hours is debatable. Early stage employees can surpass the hours a founder is putting in.
"Zoom out a bit and their chances of failing"
As are yours then as an early employee.
I think the line of risk and effort between founders and early employees is slim...and the tilt of rewards is heavily slanted towards the founders. That being said, it largely makes sense as they founders have done (typically) a lot of proof of concept work as well as handling a lot of the dirty work (HR, initial sales, fundraising, etc.).
The above is a strawman, e.g. where did you get the "give you 50% of a company"?
This recruiter is throwing out a lot of red flags, from being in stealth mode (frequently if not generally a company killer, something I've observed first hand), to not having much respect for the recruitee, which suggests he won't get much respect if hired.
Although his apparent dislike of coding on a whiteboard is a red flag if I put on my interviewer hat; if he can't prove he can code one way or another, you don't hire him.
I am the founder of an engineering intensive startup and I've always detested "write code on a board" interviews for their apparent uselessness(1) and awkwardness. There are better and more pleasant ways to ascertain engineering suitability (including coding ability in realistic coding conditions)
Errr, the point of "write code on a board" is not to determine engineering suitability, but to weed out the majority of people who style themselves as programmers but who can't actually program. See e.g. http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
I'm deadly serious about this; the last time I played this "game", back in 1997-8, we were using one of the 2 best D.C. area head hunters, were already receiving well screened resumes which we further screened, and even then a solid 1/2 of the "programmers" we interviewed couldn't program.
They showed no signs of "do this in public" performance anxiety, e.g. we would have been flexible on all but one of the tests by e.g. not hovering over the interviewee and/or providing an EMACS or Visual C++ editing buffer (the exception was "find bugs in this block of code on the board", which I think is a different sort of thing, especially since public code checking is something people do). And our write some code tests were simple, reverse a doubly linked list (C or C++), and compute the factorial of a number, which we supplied the definition of for those who'd forgotten.
Side note: I was their first programmer employee, back when they couldn't afford head hunters, just a classified ad (they'd already tapped out their networks), and the #1 reason I was hired was I was the only one who passed the white board programming test. Which I viewed as so trivial that when that fact was mentioned I didn't really remember the details of it.
Apart from all the humble-bragging, and unsupported assertions ("They showed no signs of anxiety" !! Right... not one candidate you got was anxious on the day of the interview.) the content I'm getting out of that post is minimal. And yes, I completely believe you that writing a syntactically complete piece of code on the whiteboard and finding bugs in it in while a senior engineer watches you like a hawk (without any intention of helping you out) is an everyday occurrence for a software engineer.
Anyway I don't think I'll be able to argue you out of your long-held beliefs per se. All I (and other engineer employers reading this) need to know is, Google has been the foremost purveyor of this method since it began hiring engineers and they now say their data shows it doesn't work. That's enough for me to renounce it and find other ways to screen talent (and yes, we're currently looking for a senior hacker in the Bay Area).
PS. btw, you might want to see a specialist about that deadly seriousness... before it gets, you know, too deadly ;-)
Given that few if any of us are in a position to do the sorts of filtering Google can or afford to do outside of the interview (e.g. it's been said they're enamored of Ivy League and equivalent degrees), I'm not very interested in claims that proving a candidate can code is worthless. Whereas I know from being in companies that didn't do this before I learned it in 1997 that failing to do this results in bad hires, which can be fatal, if you'll excuse my vocabulary, for a start up.
I'm sorry I wasn't clear, specifically:
The find bugs test was code we supplied, sprinkled with bugs subtle and not so subtle, and simple syntax wasn't being tested, but things such as using an uninitialized variable. The candidate had to find "some" of them, but there was never a problem in deciding who passed and who failed the test.
We also weren't at all particular about syntax in the examples that had to be written from scratch; the interviewee did had to signal to us he did knew proper syntax, but, come on, getting it all right is the job of an editor (well, so I, an EMACS user since 1980 think) and of course the compiler.
Otherwise you might try rereading what I wrote, e.g. I said "performance anxiety" in the context of writing the from scratch code examples. I.e. if we'd cued into that, or the interviewee had asked, we would have left them alone to write them, or put them in front of an edit buffer to do so while we didn't hover over them.
Counterwise, wow, I must really be coming across as a hard case, for "while a senior engineer watches you like a hawk (without any intention of helping you out)" was very much not true, see the above not watching option and we most certainly helped the interviewee out if he asked the right sorts of questions or paused at certain points while writing it.
I.e. while it would be a negative to have forgotten the difference between * and ->, we would have told them and then seen if they grocked pointers, that and recursion were the higher level things we were looking for (they were requirements for what we were doing). But it was never even close, it was never difficult deciding if someone passed or failed these three tests.
Seriously, deadly or not, while it was possible we had some false negatives, it really didn't seem to be the case, and enough other people I respect endorse this that I'm not about to stop advocating it.
As far as I can tell the Fizz-Buzz test, which is intended to be easier than reversing a linked list, has no connection to Google. "Google has been the foremost purveyor of this method since it began hiring engineers" might be true today, but in my days Microsoft was best known for this, before Google was even officially founded.
This was of course back when Microsoft was famous for being fairly well run, and their "hidden" "secret" was being consistently able to write software that "worked", i.e. didn't core dump (much)), one of the reasons all their big DOS era competitors fell behind or died in the transition to Windows.
I find it hard to pick what to answer from such a long message but suffice it to say, any engineers interesting in working with packetzoom would never be confined to a small room and asked to write code on the board. And despite that, for coding roles, we'd find out one way or another whether you can code, and at what level (not all coding roles are created equal either).
Ah, thank you. I'd written about 200 words, going round in circles, and still not quite got to the point that you've summed up in 20.
I suppose that seeing the situation turned around might help convince people of the truth of the maxim that when selling a product, you should set your price according to the value it has to the purchaser, not what it cost you to make...
I presume you are a founder. There are a lot of people who disagree with you. It would do you well to reflect on why. If these are your thoughts on founders and early employees I can't see you attracting and retaining the best talent.
"I presume you founded something. That means you take risks. Don't over-estimate yourself, because you may just be desperate, and therefore more willing to take risks. Or you're a gambler. Either way, founding a company isn't exactly a badge of honor.
If your idea/company isn't getting traction it would do your well to reflect on why. Others have given you clues. You may disagree with them, but you still don't have traction. Why not? Being angry won't help improve your idea or convince people to help you, with talent or advice. Of course, perhaps your idea/company just won't work. The typical case is that no one wants what your startup is trying to sell. Refine, repair, pivot or move on. "
This post is relevant because it demonstrates how some founders' extreme narcissism is experienced through the eyes of others. The recruiter, embarrassingly, could barely put two sentences together to explain why anyone should care about that opportunity.
This is an oddly defensive reply. I don't get the sense that this is an attack upon the basic premise of a joining a startup or startup life/risks. I think it was an attack on the approach taken to joining this startup. A fairly one sided dialogue laced with some posturing and arrogance. There are much better ways to do it.
As someone who has founded a startup before, not much of this is true. In fact, it's pretty much all just hyperbole and disinformation.
Regardless, I found this part amusing:
> not test you to see if you can write code and think logically
The article you are commenting on doesn't suggest that you shouldn't have to write code during an interview. Quite the opposite, in fact.
> check to see if you are a good cultural fit
Oh, and this doesn't mean what you think it means. Let me put this another way: it doesn't mean professional. In fact, it instead values the opposite of what that word implies.
You make valid points but his are more valid. Certainly the reward should reflect the risk taken but at present the reward is horribly skewed in the direction of founders + investors. Employees, who are extremely important, get much less in return. Founders + investors end up with ~ 85% of the stock while the first 10 employees have 14% at the time of an exit/ipo, despite the employees having joined anywhere from 3months to 1 year after the founders. This is ridiculously skewed. Where did you get the number 90%? If the founders fail, does that not mean the employees failed too? All said and done, at the end of the day, the founders can claim stuff like "founded something. got so far and failed" and they'd still be worshipped. What can the first 10 employees claim? "Wrote some code"?
Do not jump to respond aggressively without any actual thought.
The people that are very successful today all started somewhere. Many of them started at a startup, built something, and made a name for themselves. In their 30s, they are now in demand execs who have proven track records of building out teams and products.
At the end of the day no one is going to give you 50% of a company, not test you to see if you can write code and think logically, and not check to see if you are a good cultural fit in an early stage startup. It sounds like this a huge issue for you so you have two choices:
1. Go do your own startup. 2. Turn down the job and work somewhere else. 3. Go work for some mega-corp that pays you well.
In the end, you are just spamming the board with your pointless posts.