> We want to be the job search platform that puts engineers in control.
I love this, but I'm curious about the incentives here. Triplebyte only makes money from companies, not engineers. In the long run, can engineer-centric intentions override a business model based around companies and recruiters staying happy? I hope so!
Companies do pay us. But I think that our real long-term incentives still pull toward building what engineers want, not what companies want. I think that platforms like LinkedIn and Indeed have just gotten this wrong, because they focus on all jobs (not just engineers), and because demand for engineers is stronger than it has ever been. Take a look at this thread from last week:
Our bet is that LinkedIn is going to fragment. They are just not creating a hiring process that most engineers like. People tend to either get ghosted, or overwhelmed with low-relevance inbound (almost no one gets the "right" amount of attention). Companies need to go where the best engineers are, not the other way around. So I think our long-term incentive is to fix these problems.
In any case, I'm committed to giving this a try. There is danger that we get pulled toward building for companies. I want top guard against this by being public about what we're doing, and "showing our work" as we go.
> our real long-term incentives still pull toward building what engineers want, not what companies want.
> There is danger that we get pulled toward building for companies.
A common phrase thrown around with free services is "if you're not paying for it, you are the product".
> For example, companies aren’t normally incentivized to provide salary and culture data. But we can force their hand by promoting transparent companies in our search rankings.
Maybe I didn't read the article carefully enough, but are you planning to continue charging companies $15k - $30k for the ability to access candidates on your platform?
If so, companies are still your customers. And if you're building and optimizing your product for people who aren't your customers, your real customers (companies) may not be happy with you which will hurt retention, etc.
Maybe I skimmed the article too quickly, but it seems strange to charge companies $20k+ to post a job on your platform, and then actively do things that "force their hand". It might be a net benefit to the engineers on the platform, but I wonder how it will work from a business model perspective since you're potentially creating adversarial relationships with your "real" customers (companies paying you to access your candidates).
Edit: But maybe it's by design, if you actively remove employers who aren't abiding by your philosophy. Although again, that means turning away customers, which means turning away revenue, which in my mind raises questions about the overall business model. A lot of conflicting interests.
I generally agree with the phrase "if you're not paying for a product, you're the product". But the market for engineers is just so lopsided that I think it's less true here. There are a lot of recruiting companies. The only real thing that sets one apart from others is whether they have candidates. So one way to look at it is that yes, we are incentivized to build what companies want, but the main thing they want is for us to have engineers. And the only way we get engineers is by building what engineers want.
That does not fully express my motivations. I am an engineer and find the idea of making the process better for engineers more exciting than making it better for companies. But it explains how I think the incentives work.
This exactly. Their messaging is over the top "we help engineers get leverage over companies!" I have to wonder what Triplebyte is telling the companies who actually pay them all their money.
Triplebyte has always seemed scummy and this obvious--and unacknowledged--contradiction makes me trust them even less.
We do also have differentiating features on the company side. It's not like we're abandoning the idea of building features for companies or anything.
The job search, like other matching problems, is often not zero sum. So building (say) a better search interface for companies benefits engineers as well, because both sides of the market have an interest in a good match. What we're saying here is that in the cases where things -are- zero sum, the power - and therefore the incentives - lie with engineers and not with employers.
> We’re arbitrarily defining “great” candidates as those scoring between 95th and 98th percentile on our technical interview, and “the best” candidates as those scoring at 98th percentile or above.
This is an important qualifier. I'd argue that the most technical candidates are not necessarily the ones who offer the most value to companies. In fact, I would argue that "notably de-emphasizing ambition" will cancel out your technical superiority in the overwhelming majority of cases.
Here's a choice for your company's next hire:
1. A technically superior but comfortable candidate whose top priority is maintaining work-life balance and flexible work arrangements
2. A technically adequate but hungry candidate whose top priority is moving fast and learning tons
1., 2. Sounds like a pain in the arse to manage while I work at maintaining my work-life balance.
You're presenting a false dichotomy. There is also
3. Technically superior whose top priority of learning things got them where they are. Maintaining work life balance is just one of the many tools this person has learned over the years to be consistently effective over the long term instead of running into burnout.
I'd choose the first and I don't consider "moving fast and learning tons" very compelling.
That might just mean that the 2nd person would try to shoehorn projects into new frameworks and discount working solutions for shiny new (and cutting edge) tech. All in the name of "moving fast and learning tons".
> The bottom line is that the difficulty of the decision is the most important factor in determining whether a player makes a mistake. In other words, examining the complexity of the board position is a much better predictor of whether a player is likely to blunder than his or her skill level or the amount of time left in the game.
I wonder if this also works the other way around with good moves instead of just avoiding blunders.
A parallel in business: we spend so much time thinking about hiring "A players" and "10x-ers". But could refocusing on better processes, environment, and goal-setting (reducing the complexity of the position) be just as effective for increasing performance?
On point. I think that also is applicable to your personal life btw. I had a short-lived existensial crisis a few days back, realizing that my life is getting too complex for me to properly manage it. Things were falling out of hand, I wasn’t making enough progress, etc. I even had a suicidal thought, my first in a very long while. But then reflecting on it I realized that this complexity is driven by my mounting desires. To improve my balance and regain the sense of control over my life, I should examine these desires and get rid of secondary ones, which would make my life simpler and I would be less prone to error (blunder in the article’s terminology). Instantly made me feel better :)
How is this "strong-arming"? If we keep devaluing the meaning of words, we won't have any left when something serious actually happens.
The rep ran through a couple of retention scripts, and then got mixed up because OP called on the last billing day. Then he promptly canceled the service without any charges, which is exactly what OP was looking for. (And no, it's probably not because of the threat to contact his supervisor; customers overestimate how scary that is.)
There is literally nothing to complain about here, except maybe OP felt a little bit annoyed. I'm all for calling companies on their BS, but this feels just a bit too trigger-happy to me.
The BBB is basically a protection racket with excellent PR.
Get a customer complaint? BBB contacts you to pay for membership. Don't want to pay for membership? You must not care about your customers, so you get an F-. Pay for membership and the score immediately goes up to a B.
But with a name like the "Better Business Bureau", it's no wonder that people get suckered into thinking it's a legitimate organization.
> Programming, like writing, painting, and music, is chiefly a creative endeavor not a technical one. Practice... will not make you a substantially better programmer. It will just make you more efficient with your tools.
Show me a world-class writer who doesn't obsess about his writing with every waking moment.
Show me a master painter who doesn't paint every single chance she gets.
And show me a music prodigy who hasn't slogged through 15 years of mind-numbing practice every single day.
Only then will I believe that these artists are just getting more "efficient with their tools".
In creative fields, it's even more important that you put in a huge volume of work. That's the only way to connect the dots and create something truly unique.
Consistency my friend. Murakami's routine which involves him running for the first half to the day, then write and then chill with sexy-time Jazz music at time at night and turning in,
I could give you more examples of writers, Joyce Carol Oates , Michael Crichton but same thing basically. Also note that Murakami didn't start writing until 29 and loafed around at the public library chill in' and reading' and at Japanese jazz cafes. As far as I'm concerned, I'm a prodigy and workaholic at 27 for starting so early.
Also in regards to music, others can comment as I'm not an expert. But I've wasted 2 years of my life doodling around scales, ear training and music theory focusing on speed, dexterity and memorization, attempting to learn how to improvise like the greats. That I never taken the time to listen to the groove of the great pieces, sounds wonky but I decided that if I never can become a good musician, at least I could slow down and learn to enjoy the music as opposed to the idea. And I enjoy listening and playing much more now and don't give two-shits about how my solo's sound and just keep playing. And in the small moments of self-delusion inspired by bluesy turns, my own playing gives my deluded mind a self-congratulatory chill to the spine.
And in regards to programming, let's be real. CRUD or iOS apps are not going to change the world. We are like the capitalist work-bees, shoveling digital snow around like escorts shoveling sensual snow. If we are really secure enough to want to dive into our craft, then learn Linux kernel, compilers, advanced algorithms and contribute to the bottom of the stack for a change instead of fluffing snow at the top.
Everything you said was golden, until the last paragraph.
<sarcasm> Picasso really should have stopped faffing about with his silly brushes and gone to work in a canvas factory instead. The world really didn't need another bloody painter. </sarcasm>
However, most guitarists get paid to provide pleasant background music at weddings. Making money writing and playing Purple Haze is a (boom-and-bust, drug-induced) outlier. Master artists aren't employees of Paint-o-Corp who get paid salary in exchange for the rights to their creative output (even if it's side-projects).
If we want a sustainable population of healthy, balanced engineers, we need to adjust our expectations for the typical coder.
Roald Dahl is a great example of a prolific author who would write perhaps 4 hours a day and would spend the rest of his time drinking, relaxing, and tending to his farm. As far as I know, a casual pace like that is pretty common among writers - though maybe not to that extreme.
Slogging through 15 years of practice every day is a technical endeavor. If you need to learn how to do something or to master a technical skill, then yes, volume of work will get you there. Code is a tool that is used to create, and I think the quote you selected just serves to underline the difference between learning how to be an effective engineer vs learning how to become an effective technician.
Edit: constant practice is definitely important, but relentlessly working is not.
I agree that you must put in time to get better, but I think the difference with programming is that more hours does not necessarily result in getting better. Actually, now that I think about it, maybe that's no different than the examples you provided. If you practice violin 14 hours a day, will you really be better than you would if you practiced 8 hours a day and spent the other 6 doing other things?
When programmers get beyond a critical daily/weekly threshold, putting in more hours hurts more than it helps. The brain gets tired of solving problems, and when that happens, pushing yourself further is not the answer. The answer is to do something else, especially something involving physical activity, to allow your brain time to recover.
I believe that many programmers fundamentally do not understand this concept, thus they drive themselves crazy trying to push harder and harder. Yes, you may write more lines of code that way, but at what cost?
I love this[1] interview of Eubie Blake by Marian McPartland for many reasons, but the part where he describes how he at 93-years-old still does daily scales on the piano just goes to show the importance of persistent training in artistic endeavors. I'm a lazy bastard, but I'd only be fooling myself if lack of complete dedication to my craft didn't come at a price.
That said, I have no sympathy for a company that expects to hire a Yo-Yo Ma for the salary of an amateur band member.
I think there is a middle ground between the OP and your comment. I agree with you that the best way to get good at programming is to program. But I also agree with the OP that having other hobbies, interests and letting your mind work on different things will also help you. The ideal balance is some mix of side projects and hobbies.
> Show me a world-class writer who doesn't obsess about his writing with every waking moment.
> Show me a master painter who doesn't paint every single chance she gets.
Well, there's Dante Gabriel Rosetti, who decided one day to give up painting and become a poet. While he is remembered more for his paintings than poetry, his poetry carries with it the essence and soul of his paintings as well as the imagery. He decided to paint with words. I don't think he obsessed about writing all the time. As he put it, though, "A sonnet is a moment's monument."[1]
This gets at what I think is an important point though. All of these creative endeavors require real-world knowledge. Hemmingway went out on adventures. For Tolkein, writing fiction was not his day job (teaching about medieval literature and linguistics, however, was). You can see their respective works that the live of the writer and the other obsessions beyond writing are what make the author.
Similarly with programming, yes, it is a technical endeavor and yes it is a creative one. However just like writing the great works of fiction, these don't come out of nothing. They require a context grounded in other knowledge and experience.
[1] http://web.ics.purdue.edu/~felluga/medievalism/areading.html Note that this was the introductory sonnet to "The House of Life" which chronicals Rosetti falling in love, getting married, coping with his wife's death, and finally finding solace in his religious worldview. The poem, despite its abstract nature is full of classical Greek imagery and something one could probably write volumes about. At the same time, it is an exposition on why he wrote poetry, and it provides the framework for fully understanding the hundred or so sonnets in The House of Life in that way. There are love sonnets, and sonnets which, as he puts it "in Charon's palm it pays the toll to Death" (i.e. allowing the dead and the living to begin to move on).
So your argument is that the primary difference between geniuses and the rest of schlubs is sheer volume of rote practice? I think you're confusing creativity with tool proficiency.
I don't think programming is that much like painting (more than any other craft), but I do think deliberate practice is at the heart of mastering any craft.
More than putting in a huge volume of work, you have to work hard and deliberately at improving every day. That doesn't take (and can't be sustained) for more than a few hours a day, and all other activity is nowhere near as important for development.
As some sort a of music prodigy according to certain people, I'd say you have a point. I've certainly put in a ridiculous amount of time in music "just for fun".
At the same time, to create something great you do have to stop practicing and go back to what you know best and what inspires you.
you omitted a pretty key clause with those ellipses. in its entirety, the quote from the article is clearly targeted at api churn and similar things thrashing everyone's personal caches, not practicing programming in general.
> Rails isn’t just a brick wall, it’s a brick mountain... By the end of the first month, I had literally no idea what was going on.
This is not a brick wall. It's giving up as soon as something gets hard.
Rails is a great example. It has so much behind-the-scenes "magic" that it's really hard to wrap your mind around at first. Back when I was first learning it, my brain felt like it had been filled with cement at the end of every day. I didn't understand it for weeks; I felt like I was just pounding my head on a brick wall over and over. Then, all of a sudden, the fog suddenly parted and it was like being set free. After that, I never had another Rails problem that I couldn't handle.
Everyone that I've ever talked to that has learned Rails - or any other language - has struggled through this initial pain period. The difference is that the successful ones push through it after it stops being fun.
It doesn't only apply to programming either. Everything you ever learn starts with a "brick wall" that you think you'll never get past. Once you suck it up and break through it, you may find that the road is clear from there.
There is no programmer so intelligent and so experienced that there does not exist a framework which makes no damn sense to them.
I think I'm a decent programmer but the scope and complexity of Rails (especially with all the great concepts and practices Hartl introduces simultaneously) is daunting at first. But you just have to keep at it and it eventually clicks. I think I did his tutorial 3 times from scratch before I really started to understand what was going on, and it wasn't until I tried to make a large and complex app that all the features and beautiful organization of Rails began to feel natural. Rails (or Ruby, or any other insanely powerful tool) just takes a long time to really grok, and even longer to master. Smart people are used to getting things quicker than that and that is what makes all of these things so emotionally painful. Our projects don't work and our egos suffer as well.
Exactly. The smart people ego thing. Yikes, that's me. Programming is humbling the shit out of me. It really is a good process.
Just slow down, be patient, expect many failures and false starts. Hell, if I can do this, it seems like I'll be better prepared for all sorts of challenges in life.
Here's an important piece of demographic information for the survey:
> 45% of those surveyed don’t own a device that can read ebooks – this includes both e-readers and smartphones.
So almost half of those polled don't actually have steady access to ebooks. I wonder how the statistics change for a sample who have ready access to both.
Either many of those 45% don't realize they don't have access to devices that can read ebooks (may not know their iOS/Android device can run Kindle/iBooks/whatever) or this was a really weird sample.
> Twenty-somethings are the leading smartphone users in the U.S., with a full 81% of Americans aged 25 to 34 using the devices. Teens aren’t far behind, with almost 70% of those aged 13 to 17 already using a smartphone.
Sure, but even more key than that is that this is a question about perception, which can potentially be overcome with education.
How many of the people who say they prefer a physical book have read a complete book using a modern e-reader? How many of them have learned about a book, gone to their e-reader, bought it, and started reading, all within 5 minutes, while sitting in their pajamas, at 11pm? How many have purchased enough e-books that they feel they are carrying a small library in their bag, even though it still only weighs less than a pound.
There are compelling reasons to like an e-reader even if you still really prefer a physical book.
Or they don't really consider smartphones or PCs suitable devices for reading ebooks. I know I'll read an ebook on my smartphone from time to time but if that were all I had, I certainly wouldn't buy ebooks for it. Of course, I think it's also entirely possible that at least some respondents just answered whether they had an ebook reader or not--however the actual question was worded.
I have never used my smartphone to try and read a book, I think most people around me would agree that it would not be a fun experience (most people around me have older smartphones with small screes).
I do own a Kindle, though, but my point is that I think many people don't consider their smartphone a "reading device".
I used to do this a few years ago when I was in London. When you have 5 minutes to wait for the next tube there wasn't much else to do as there was no wifi then :)
>> 45% of those surveyed don’t own a device that can read ebooks – this includes both e-readers and smartphones.
I'd say this is the key variable in the set.
Another example:
>"The only reason I haven’t bought an e-reader is because I love the feeling of holding a book in hand and seeing the creases in the spine when I'm done. It’s like a little trophy."
I was the exact same way -- right down to the explanation as to why I didn't want an ereader. I just loved everything about physical books. The texture, the smell, and, embarrassingly, the vanity of having an apartment filled with books. And then my work bought me an iPad. Everything changed almost immediately.
I absolutely love being able to have an army of books with me at all times. As a guy whose still a student, 95% of my time is spent with technical books. It is absolutely amazing to have everything at my fingertips at all times. I can pull up whatever I feel like studying at any point throughout the day. Few minutes of downtime at work? Maybe I'll read a chapter in my Patterns book. If I'm not feeling that, I just swipe over to Programming in Scala and have some fun. Also, being able to search a book is worth its weight in gold.
That said, there are a few draw backs which irk me. Though, I think these can really be solved with better software.
Firstly, referencing two places in the book at once. How many times have you been reading a textbook and kept your finger in one section while reading another so that you can quickly hop back and forth? Impossible to do quickly with readers. You got to create bookmarks, with each "flip" open the bookmarks, find the one you need, and finally select it to view the page. With physical, all you need to do is flip to where your finger is and presto! Done. The digital equivalent requires multiple taps and a good bit of waiting.
The other drawback is DRM. After a fiasco with Amazon (which I otherwise love), It became clear to me that DRM books are not worth owning. I purchase almost exclusively from O'Reilly due to the fact that they offer a plain old, DRM free PDF. I give them money, then give me the product -- not a licence to use the product under their terms, the actual product for me to do with as I wish. Currently, it's very tough to find all the books I want to read as DRM-free pdfs. I'm doing my best to vote with my wallet, so that means there are many books that I simply don't buy anymore because I like actually owning the things that I purchase.
Other than those caveats, eBooks have completely replaced physical ones for me. The article is kind of pointless given that so few of the people sampled have any actual reference point.
> When the Internet bubble burst, the company underwent rocky times. By 2000, [the founder] was gone from the company, as were four other members of his founding team.
> For the next decade, Bloodhound recovered and slowly grew, raising seven more rounds of financing. In April 2011, the company was sold for $82.5 million.
11 years is a long time. How much do they think they deserved?
My thinking is a little different than most of those who have commented...probably because I'm a bootstrapper.
After reading all of these comments - my thought process goes like this: If the founders output from 11 years ago is worthless, why isn't the investors' money from 11 years ago equally worthless?
If the founders' sweat equity didn't create value, the early VC money didn't either. Should the early VC's lose their investment, or just the founders?
I'm not naive, I understand that these deals are structured this way...I'm just saying that the structure is bullshit (imo).
That's not quite right. It's unclear how much total the VCs put in, at least from the article. But it sounds like they continued to fund the company while the founders' involvement ceased over 10 years ago.
"For the next decade, Bloodhound recovered and slowly grew, raising seven more rounds of financing." <-- if the insiders participated in follow-on rounds they stayed involved all the way through. Once again, that's what seems to be indicated but it isn't spelled out.
Right. The founders were there five years, then pushed out during the dotcom crash, then the company made a substantial “pivot” (in the same field, but the product being offered and created by the founders was gone, and new ones introduced).
Two years after the founders are gone, the company begins to make money again.
Then 11 years, the company is sold for a lot of money.
And the founders feel they are entitled to a large chunk of that, despite their non-involvement in operation of the company and their diluted ownership (unsurprising, but common with multiple rounds of financing that they were in favor of).
It’s worth noting that many of the founders claims have been dismissed as egregious, lacking in evidence and otherwise.
