Hey everyone. Happy to answer any questions about this. Basically, we think that LinkedIn profiles don't do a good job of showing engineering skill (especially for self-taught people or people from non-traditional backgrounds). I'm excited to just build better support for showing side projects and GitHub contributions. LinkedIn profiles have become the default engineering resume (despite the fact that most engineers are not particularly happy with their LinkedIn profile). But there's lock-in. I hope that we have enough scale to be able to chip away at this.
The same thing happened to me! My brother and I left on a 5-day backpacking trip on the 10th. I did not learn about the attacks until the 13th (another hiker came in and told us). We thought he was probably lying, but hiked out early to check. On our way out, we passed another party and asked them. They had not heard about it either. I remember a woman saying "it sounds like someone has been pulling your leg!"
Reducing the size of a tumor for six to eight weeks (especially via a new method) could actually be an important result. Many cancer drugs only result in temporary remission when used in isolation, before the cancer out-evolves the drug and comes back. However, using multiple drugs simultaneously (combination chemotherapy) and using the drugs after surgery to kill remnant cells can have a far larger impact. Many of the drugs that can now 'cure' certain cancers in combination only provide brief remission by themselves. (Disclaimer: my only knowledge of this comes from the book The Emperor of All Maladies)
Lyme disease is easily curable with a large course of antibiotics. Now, there can be complications that persist after the infection is cured (arthritis, cardiac issues, and - controversially - fatigue and post-treatment Lyme syndrome). But the infection itself is curable today.
I want to add that opening books are not THAT effective in computer chess either. Yes, they are significantly more effective than in computer go (because of the smaller branching factor and greater role of tactics). However, exponential increase in game tree size is crazy, even in chess. Thus, opening books really can't take you THAT far into a chess game (10 moves). An engine with a worse book but better search/eval will usually win.
It's possible to use color in that the dots don't have to be black and white, and don't have to be totally random. The way an autostereogram works is that there's a repetitively tiled base image (or vertical column repeated horizontally). The stereographic angle information is encoded in mutations of the repeating image. That base image can be anything (including a photo).
However, this color image will not correspond in any way to the 3D geometry of the scene. I don't know of any way to get color information to correspond to BOTH the 3D geometry and the stereographic information (without using two images).
You can apply the exact same algorithm to any starting pattern (it does not have to be random dots). When a pixel is unconstrained by the algorithm, just pick a pixel from an image (rather than a random value). Of course, to work well the image needs a lot of small details. I actually tried that here. But the result "leaks information" into the 2D image (as you move around, the deformations of the 2D image reflects the 3D geometry). It seemed less interesting.
Thanks! I did try to smooth the flickering. There's a 4th render mode. Press 4 and you'll get a smoothed version of autostereogram. It does look better in autostereogram. However, you'll notice that the smoothing causes an "information leak" into the 2D image (you can see the outlines of the walls)
I mostly focus on consistency in this post (how to make a group of interviewers more consistent). Of course, what actually matters is accuracy (predictive utility of the interview). Obviously those are not the same thing (you could run 100% consistent interviews by just having everyone always grade “strong no”). However, I think (based on running the interview team at Triplebyte) that inconsistency is the primary obstacle to accuracy in practice. So I end up spending the majority of my time focusing on how to make interviewers more consistent.
Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.
An interesting point that I ended up cutting from the blog post is that companies also use culture as a selling point to convince candidates to join. We have seen this work (convince a candidate to take an offer). However, most companies underestimate how similar their culture pitch is to other pitches candidates hear. I think these pitches are less effective than most companies think they are.
The conversations involved me asking them to talk through the details of their interview process and decision-making. I think there were good incentives for companies be honest (given the context of us matching engineers with them). I did the classification into types of screening after, based on my notes.
This is the core way we look at it. Our models are hopelessly simplistic, and have no chance of modeling the true complexity of human ability. It's important to stay humble and recognize this. However, what we're competing against is people (often non-technical people) making gut screening decisions. And it ends up that even relatively simple models can do a better job than most recruiters making gut calls.
And the fact that we are able to do this while being blind to background (and open to people from all sort of backgrounds) is something that I think is very positive. We totally make mistake and reject good people. But we get better over time, and we also help lots of people get jobs they might not have been able to get without us.
I'm one of the co-founders at Triplbyte. What this means is that our statistical model now significantly outperforms our own interviewers (and me) at performing a structured interview, and then making a judgment about whether a candidate will or will not go on to do well at interviews at other companies. It is slightly meta, because we're using an interview to predict other interviews. But I find it very exciting, because a) it means we're more accurate, and b) we know exacly what features we're feeding into our model, and can avoid a lot of the bias in the process.
Yeah, we do more than let people skip phone screens (although don't undervalue skipping phone screens and take-home projects at 8+ companies). Companies really do look for different things in interviews. Not all companies look for CS trivia. So in your case, if you went through our process, we'd suggest 20 or so companies that look for more practical / architecture skills (depending on your skillset). Because we do this, engineers who go through our process get job offers at about 2X the rate of engineers who go through regular channels (we avoid the cases where engineers who don't like CS are rejected for being bad at CS)
We (Triplebyte) don't ask engineers where they've worked until the end of the final interview. It's the last thing we ask (after all the technical evaluation and scoring is done). We regularly find and pass great programmers who are totally self-taught (and would have been screened out by any resume screen process). We ask about previous work at the end because we want statistics on who is applying to us. This lets us compare our process to more traditional credential screens (I write about this on our blog)
We (Triplebyte) actually tested a while ago whether identifying languages was predictive as an interview question (we thought it might predict general experience / exposure to lots of code). It was not predictive of anything. So this quiz is just for fun!
So, we've gathered data on exactly these points over the last 2 years. And what we've found that the decision that gets the best signal is often not what feels most accurate to the interviewer.
For example, my guess before running these experiments would have been that simply looking at progress (how far a candidate gets through a problem) would be a bad measure of interview performance. I'd expect that things like style and how communication how careful a candidate was being would render pure progress a mad metric. However, when we compare pure progress to a subjective score the interviewer gives the candidate (ignoring specific reasons, does the interviewer think the candidate is a good engineer after the interview), we found that pure progress is more predictive of success at companies! (To be clear, we don't only look at progress at Tryplebyte. We've also found other things to be predictive.)
The same is true (among our candidates at least) for question difficulty. Easy, straightforward question (write a command line interface to store and retrieve key-value pairs) are more predictive of success at companies than question that try to target intelligence (calculate how much water would collect in a histogram)
That's an interesting idea! The hard part would be convincing companies to trust an external trial week fully (part of what's great about a trial week is the chance to actually see how an engineer will interact with your team / your problems). But I like the idea!