Using a burner because I don't want to tie this to my company.
You can send your CV to $bigcorp directly, but $bigcorp is inundated with CVs, and many CVs have a casual relationship with reality.
I do a lot of interviews on the hiring side. I look at a lot of resumes. And other than "worked in a similar position at a big-5 tech company or well regarded unicorn," nothing on a resume provides much signal. There are a handful of universities that make me pay attention, and a few particular programs outside that handful, but even that is weak signal. A candidate saying "expert in [whatever]" is useless.
I spend about 10% of my work week doing technical phone screens. This comes after a recruiter reads a candidate's resume, talks to them on the phone about their experience, and decides they're a plausible candidate. I get on the phone with them, we fire up coderpad, and I ask them to start coding. Nothing requiring exotic data structures or algorithms, just a straightforward "make a class with a couple of properties" type thing. Something along the lines of:
Part 1: Make a class that represents a playing card. It should have a suit (clubs, diamonds, hearts, or spades), and a rank (two through ten, jack, queen, king, or ace). Make a way to print out the card as a string. And make a comparison function that can tell whether two cards are the same (same suit and same rank).
Part 2: Make a deck of all 52 possible cards.
Part 3: Make a 5-card hand by picking 5 random cards from the deck.
and one or two more similarly straightforward parts after that.
There are a few places where a candidate can show off (e.g. override the default string representation for the class, anticipate that we might want a comparator that does more than just check for identical cards, or use a special data structure, use an optimized algorithm for picking 5 random cards) but none of that is necessary to pass the interview. More than half the candidates I talk to can't get through part 1. Half of the remainder can't get through part 3. Most people who get through part 3 move on to an onsite interview.
70 or 80 percent of candidates who say on their CV that they can code, and have convinced a recruiter that they can code, can't write a class and a couple of functions. So a lot of companies do the easy thing, and just toss out (or at least don't fast track) all the resumes that don't include particular schools or companies, or come from referrals. And in the process, companies lose out on tons of qualified candidates, and those candidates lose out on jobs.
If Triplebyte can reliably identify candidates who can pass a phone screen, when I'm sorting through resumes I'd be happy to treat a Triplebyte stamp of approval the same way I'd treat a degree from a top school.
You can send your CV to $bigcorp directly, but $bigcorp is inundated with CVs, and many CVs have a casual relationship with reality.
I do a lot of interviews on the hiring side. I look at a lot of resumes. And other than "worked in a similar position at a big-5 tech company or well regarded unicorn," nothing on a resume provides much signal. There are a handful of universities that make me pay attention, and a few particular programs outside that handful, but even that is weak signal. A candidate saying "expert in [whatever]" is useless.
I spend about 10% of my work week doing technical phone screens. This comes after a recruiter reads a candidate's resume, talks to them on the phone about their experience, and decides they're a plausible candidate. I get on the phone with them, we fire up coderpad, and I ask them to start coding. Nothing requiring exotic data structures or algorithms, just a straightforward "make a class with a couple of properties" type thing. Something along the lines of:
Part 1: Make a class that represents a playing card. It should have a suit (clubs, diamonds, hearts, or spades), and a rank (two through ten, jack, queen, king, or ace). Make a way to print out the card as a string. And make a comparison function that can tell whether two cards are the same (same suit and same rank).
Part 2: Make a deck of all 52 possible cards.
Part 3: Make a 5-card hand by picking 5 random cards from the deck.
and one or two more similarly straightforward parts after that.
There are a few places where a candidate can show off (e.g. override the default string representation for the class, anticipate that we might want a comparator that does more than just check for identical cards, or use a special data structure, use an optimized algorithm for picking 5 random cards) but none of that is necessary to pass the interview. More than half the candidates I talk to can't get through part 1. Half of the remainder can't get through part 3. Most people who get through part 3 move on to an onsite interview.
70 or 80 percent of candidates who say on their CV that they can code, and have convinced a recruiter that they can code, can't write a class and a couple of functions. So a lot of companies do the easy thing, and just toss out (or at least don't fast track) all the resumes that don't include particular schools or companies, or come from referrals. And in the process, companies lose out on tons of qualified candidates, and those candidates lose out on jobs.
If Triplebyte can reliably identify candidates who can pass a phone screen, when I'm sorting through resumes I'd be happy to treat a Triplebyte stamp of approval the same way I'd treat a degree from a top school.