It's not that I don't like to solve problems, it's that Linux and MySQL code bases bring unnecessary problems to the table that I have no interest in solving.
Flamebait. You have cleaner and better examples of a world-class kernel and database engine? You want to do rocket surgery, you gotta bend a few scalpels.
FreeBSD is generally considered to be a cleaner and better example of world-class kernel. MySQL codebase is OK, but isn't fantastic. In general, all mature large systems come with a can of worms, and it takes a certain kind of person to deal with that. Legacy code is always less fun than a blank slate, unless you have certain mindset.
Fortunately, we get to deal with both world-class legacy systems, and write some blank slate code. We get the best of both worlds :)
Yeah, I think that's their "nice" way of asking for someone with significant experience there. The problem is that you only want someone with significant experience, not just someone who is "unafraid" of it, because any worthy developer unversed in those projects would be scared to just jump in and start changing random things if the work is ever going to be used.
Both Linux and MySQL are huge, complex systems and if you want someone who can immediately start making usable changes to those systems, you should probably recruit on their respective mailing lists. Developers running in to huge things like Linux and MySQL ad-hoc and making changes causes lots of problems. See Debian's SSH-certificate problem from a year or so back for just one immediate example.
As with any complex platform, it takes a lot of tinkering and experience to know what flies and what doesn't. Those dudes should change their ad away from the cute thing to the serious thing unless they plan on allowing the hire time to figure these things out.
That's not true. While we'd prefer someone with experience in these areas, when we say "you're not afraid" we really mean "you're not afraid".
Hacking Linux really isn't that hard. I implemented two kernel-level projects - a stackable filesystem that gives you an assurance your files haven't been tempered with, and an "object orientation" system that lets processes modify and inherit their syscall vectors. Each project took about four days and I never looked at the kernel code before. I had pretty good access to a Linux expert who pointed me in the right direction, but I didn't ask that many questions. It wasn't the caliber of code that would make it into vanilla, but it was very useable.
The idea that hacking the Linux kernel requires superhuman abilities is a huge misconception. I can assure you that I'm as far away from being a genius as anyone. If I could do it, any reasonably competent software developer can. And the complexity of MySQL codebase pales in comparison to Linux.
We want some degree of experience hacking high performance low level systems, but we care about competency, determination, and ability to ship working code far more than experience in any specific area. It's Linux and MySQL today, but it could be FreeBSD and Postgres tomorrow.
I never said it required "superhuman abilities". It just requires some familiarity, obviously depending on how deep you want to go. The trend of developers running in guns blazing and changing a complex codebase they don't understand is bad. I'm glad your stuff was personally usable, but there's a difference between something that's adequate for personal use and something that you can distribute as part of your new _database engine_. That stuff requires serious stability and complex programs are complex and changes can often have unforeseen consequences even for devs already trained in these large projects.
I'm not saying one can't learn, but I am saying that most good developers who haven't changed the source code for ginormous things like MySQL and Linux _are_ scared to take a new job where they're expected to be able to make meaningful and/or significant changes to any ginormous thing they don't have much familiarity changing, especially if you want to changes that are immediately deployable in your project.
If you're going to give the dudes time to get used to MySQL and Linux and tinker and discuss adequately, then that's fine. If not, and you expect them to go from 0 to "usable filesystem" in 4 days, you should probably be more specific in your ad.
The founders are awesome =] This is a group that you'd want to work with, besides the cool technology challenges and perks of being early in a funded start up.
Can we please stop this nonsense about "cofounders" joining a company several months after it is founded? What's wrong with calling a spade a spade and saying "RethinkDB looking for 1st employee"?
Is it a fetus or is it a baby? It doesn't matter, it's so early that you can call it what you'd like. I think it's fine that they're looking for co-founders. They could just say "hiring first employee," but sounds like they're looking for a person who will be more involved than that.
If it dies, the law considers there there is a very large difference. :-)
More seriously: The English language says that "co-founders" are "people who found together"... not "people who found together plus anyone who joins them shortly thereafter".
Not necessarily. LinkedIn technically had 1 founder: Reid Hoffman. But really he couldn't build LinkedIn solo, after raising a small amount of capital (and using some of his own from paypal) he recruited 4 others to help him and become additional co-founders. So LinkedIn actually has 5 cofounders, but really started with 1.
What we need is another word that means "1st employee and oh so much more". I'm thinking "employee++", or "founder'" (that's founder prime, if it's not obvious).
In all honesty I think that all that is needed is a dose of reality.
If this to-be-hired person is going to be on-par with the existing "founders", in terms of pay, equity, and ability to vote to affect the outcome of the company, then I would call them a co-founder.
If instead this to-be-hired person is going to be a very senior employee with more equity than later employees, and some input on the product management stuff, then they are an employee, not a co-founder.
I do not know which case is true, my only point is that we do not need to invent new pseudo-titles for everyone to feel special.
Usually I'd 100% agree. But I think the RethinkDB guys are a special case.
They've gotten a huge amount done in the last few months -- in my "On Applying to YC" entry, they were the most notable exception to the "the teams that were moving the fastest at the beginning were also moving the fastest at the end".
But if you remove YC from the equation, RethinkDB probably wouldn't have incorporated yet. (Well, let's pretend that they wouldn't have, at least.) They're just a few months in. Really, I think it's exceedingly rare when "co-founding" teams all start on the same day. There's a period where the company comes together over a few months and the people that are there when it incorporates become codified as the "co-founders". In this case, the RethinkDB guys are early enough on that I think some of that DNA is still being laid down, and the term co-founder isn't completely off.
I am the technical cofounder, I am most definitely not leaving the company :) I couldn't have described the reasons we are looking for a cofounder and not an employee better than zaidf - expectations, equity, and pay. We expect full dedication, tremendous force of will to change the world, incredible technical expertise, and capability to lead people and define the company. In exchange, we will give a significant chunk of equity (it's not a 0.25% - 0.5% deal at all), and because it's such an early stage, we cannot pay a competitive salary yet.
Expecting these things and calling the person an employee would be dishonest at best. We're in this to nurture a great company, not to nurture our egos. We feel that assigning a title of employee at this stage would be a display of vanity and would significantly detract us from the real goal of building a next generation database that will change the world.
Expecting these things and calling the person an employee would be dishonest at best. We're in this to nurture a great company, not to nurture our egos. We feel that assigning a title of employee at this stage would be a display of vanity...
We clearly have different opinions here. I'd say that calling an employee a cofounder is dishonest at best; that you're in this to nurture a great compnay, not to nurture your employee's ego; and that for someone who joins several months after a company is founded to insist on being called a founder is an unreasonable display of vanity.
dude, what the hell is wrong with you? You can still technically write someone in as a cofounder -- both in terms of equity and pay. Just because you're recruiting them later than the initial founding team doesn't reduce the title. Saying that it's dishonest is just wrong here.
You can still technically write someone in as a cofounder -- both in terms of equity and pay.
You can give someone the amounts of equity and salary which are normally given to cofounders, but that doesn't make them a cofounder. The word "cofounder" doesn't say what you do; it says what you did -- specifically, it says that co-founded something (in this context, a company).
No it doesn't. You're just playing semantic word games.
If I incorporate a company one day and bring you on board the next day with half of the available founders equity then would you argue that you're "just an employee" because you weren't there on the day that the company was incorporated?
When did attempting to maintain consistency in how the English language is used become playing semantic word games?
... would you argue that you're "just an employee" ...
No, for two reasons. First, I wouldn't say just an employee, since I don't consider that word to be derogatory; and second, I wouldn't stop at saying that I was an employee (unless I was deliberately attempting to obfuscate) because that would fail to mention a large equity stake. I would probably say "early employee", "co-owner", or something else along those lines.
But if the company was founded without the intention that I would be part of it, I would never claim to be a co-founder.
My father has a daughter with his second wife. I call her my sister, not my half-sister, because I love her and would never want to connote that her value is in any way diminished because we have different mothers.
Sometimes using a label that is technically incorrect is the most succinct way to make a point.
This is a bit of a semantic game, and a bit of attacking windmills, but sometimes that can be an enormous amount of fun. So I'll indulge.
In practice, founding a company is a process, not an event, and hence is an interval of time, not a specific point in time. Legally, founding a company is considered an event at a given point in time, purely for reasons of convenience (how do you tax something that came into existence over a period of time?)
If you look at it that way, we're coming from the practical standpoint, not from a legal standpoint, and we feel that on the practical side we're still founding the company. If you look at it this way, poof, the inconsistency disappears like a cloud of smoke :)
- I don't think someone who has equity relatively close to the other cofounders should be called an employee. I don't think this is a controversial stance, no?
- I don't think it is fair to expect your 1st employee to put in 15-20 hour days consistently. Even if the 1st employee did put in such effort, as Rethink guys point out, they would be putting in almost the same effort as them and thus calling him/her an "employee" would be wrong.
- A big objection you seem to have relates to how long the company has existed. You think that 3 months is a long time for a cofounder to come in. If you look at the longterm roadmap of a startup, the initial 3 months hardly register. Do you think 10 years from now the new cofounder will look back and feel inferior to the other founders? With each passing day the 3 month thing becomes less significant.
Your disagreements are not so much about semantics as your lack of understanding between the possible difference in pay, expectations etc. between a cofounder and 1st employee. It might be subtle but it exists.
I'd like to suggest another factor that usually separates a co-founder from an employee: control. What amount of control will you give to the third guy, will he have a formal vote on core decisions?
You're completely right when you say "nonsense". I'm the founder of StyleFeeder. I've worked for five startups before this. Being a founder is a unique experience characterized by a constant feeling of being angry all the time and being emotionally drained by your work. Don't get me wrong - I love what I do, the people I work with and the company is doing great, but it is fucking hard. And I feel that all the time as 'founder' whereas I never did as an 'employee.'
I've also had conversations with other founders who independently used the exact same language to describe how they feel about their companies.
My simple rule: if there's nothing there when you start, you're a founder.
+1 to being angry all the time. I wasn't angry per se but I was certainly edgy. I loved my product but when I was on my first startup I really hated myself for giving up the potential to advance in my career and I desperately feared going nowhere and trying to explain to some clueless HR person the gap in my resume. Fortunately it worked out but that sucked :)
That threw me off as well. The product idea (and even some code) is in place, the vision done, the roadmap well on it's way, and they've already identified they need to hire.
During Larry Ellison's recent interview with Ed Zander at the Churchill Club in Silicon Valley, someone asked Larry Ellison what he thought was the most significant distruptive innovation that Oracle was paying attention to.
Larry Ellison said: "Flash".
Apparently, Oracle is taking flash very seriously. They already have a flash-based Oracle database product that is shipping.
And with the Sun acquisition, Oracle now owns MySQL.
SGI on their demo truck once were showing a database... or was it filesystem... system that know how to keep things in memory, HD or tape, depending on the data usage.
This is one of those times where I honestly wish I was at a time and place in my life where I could take the leap. RethinkDB does exactly the kind of low level, rethink-the-whole-stack systems development that I've been crazy about from the get-go. Best of luck folks!
Certain infrastructure plays really get me wet. This along with push notifications is one of them. We need to start building the infrastructure for the future. If I knew anyone who was qualified for this specifically, I would tell them to drop whatever they are doing and go join the company. Best of luck with the co-founder search and the future.
As a storage engine, are they in any position to fix MySQL's deeply held assumptions that the user is generally not interested in validation or constraints? We should at least begin expecting correct answers if this is the infrastructure of the future.
I'm a pretty good engineer, and I think I'm better than I am, but I'm pretty sure I'm not smart enough for this gig. Seems like one of the few job descriptions that requires software/hacking skills as well as computer science skills.
I think the right person who sees this ad will jump on it. I like the fact this company is doing something systems oriented and not just another web app. Pretty cool to see Scott's startup and this out there. Good job YC. It looks like PG and crew are seeding some folks with potential to make a long term impact on the plumbing of our internetz.
RethinkDB seems to implement a functional btree on a log-structured storage. This would involve lots of copying, I wonder what is the performance impact of this (compared to a less pure implementation that copies the modified nodes every thousand updates or so).
Also, the most important feature for SSD storage (no random writes!) is fulfilled by Cassandra / BigTable implementations based on SSTables, I wonder how a btree-based implementation compares to them.
Flash based storage is better than disk because there is no seek latency (the time for the head to find the location on the rotating platter where the data in interest are stored), which currently is the major bottleneck of databases. Also the transfer rate is faster than disks the prices are falling (not as fast as the prices of disk based-storage, but faster than RAM)
Today a gigabyte of NAND costs less than 1/3rd as much as a gigabyte of DRAM and the gap between the two is growing. ... By the end of 2012, when a gigabyte of NAND costs 1/19th as much as a gigabyte of DRAM, the optimum balance of flash/RAM will be very different.
My "I understand now" was just for fun. It's like LOLWUT... given that I'm the author of an in-memory snapshotting DB I belive I know at least the difference between RAM and SSD. So I stopped the thread this way.
That said, seriously, I think that what applies for SSD applies for RAM: that it's going to be cheaper and cheaper, and bigger, super fast, and unlike SSDs the writing and reading latencies are comparable, so even if as today it's a psychological barrier to hold your data in RAM, I think it is going to be much more common in high load applications in the future.
Actually most people are doing it already, with memcached. Sometimes the total memcached memory used could be enough to store the whole dataset well organized given that when you use a K/V cache a lot of space is wasted compared to using it to hold data.
You could keep data in ram and dump it occasionally to disk (which is way faster than committing every transaction for itself). Replicate among few machines to deal with failure scenarios.
reply