Are juniors screwed? (Getting a job in a post-AI world)

I think it's fair to say that the job

market is weird right now. Honestly,

weird is putting it lightly. I've been

seeing crazy numbers like 74% of devs

are struggling to land a job despite

demand going up. 40% of employed devs

are planning to leave their current job

within a year, which is even crazier.

And when you look at the split across

different levels of experience for

headcount at companies, you see junior

engineers collapsing as well as

mid-career and senior engineers rising

meaningfully. At the same time, there's

lots of other numbers that contradict

this. Like the number of recent grads

that are struggling to find jobs going

up a bit, sure, but that's about 1%

increase and nowhere near as bad as

things were during the recession in the

early 2010s where it was much higher,

closer to 8% of new grads. So, what does

this all mean? It means that we need to

think a bit differently about the job

market. Most of the advice that is

available today is dated at best and

harmful at worst. And I want to do my

best to break this down. My goal here is

to make a video that's useful to people

who are experienced engineers maybe

considering a new gig, new grads or

people recently in the field that are

trying to get their first job, but also

for hiring managers, people who are

looking to level up their teams by

bringing in the right people at the

right time to build something awesome.

To get this right, we're going to need

to rethink a lot about how hiring works

and how you get the right people on your

teams and what they're even doing in the

first place. Our roles are changing

actively and as such, the way that we

hire should change, too. And I don't

think it's changing fast enough. And

that's why I'm going to do my best to

break this all down for you right after

a word from today's sponsor. I have a

confession to make. I stopped using

GitHub actions kind of. We just moved

all of our stuff over to Blacksmith and

it has been so much better. I could tell

you all about how Mintify cut their

build times and CI costs in half or how

they're going to cut their Docker build

times by up to 40x due to the Docker

layer caching, but I'm not going to tell

you about any of those things. I'm going

to tell you about how great it is having

real observability in your GitHub

actions. It's hilarious that this is

just not a thing on GitHub itself. But

look at this. We can see all of the runs

when they're happening. We can see

failed runs and why they're happening.

We can look at failure rates for

different tests. We can see what's going

on in our actions. You know, the thing

you can't do on GitHub at all. So, if

you're actually using actions for

anything useful, check them out now at

soyv.link/blacksmith.

Going to do my best to break down all of

this chaos into three core parts.

Companies suck at hiring. Experienced

devs suck at growing. and juniors suck

in general, but should lean into it. The

junior stuff's going to come near the

end, so make sure you stick around for

it. But I think all of this will be

useful for every level of dev as you try

to rethink how this stuff works going

forward. Let's start with one of my

favorite topics, which is that companies

suck at hiring. There are so many layers

to this, but I'm just going to start

with one of my personal favorites. How

interviews and candidate processes tend

to go. If you're new here, you should

probably hit that sub button. Doesn't

cost you anything, and half you guys

aren't subbed. It's a good way to keep

up with what's going on. But if you have

been around for a while, you might

remember my mock job interview I did

with Dan Abramov as my second actual

video on my channel. It was a live

stream where I did an actual mock job

interview with Dan Abramov, who is the

creator of Redux and a core contributor

of React, often jokingly called the

creator of React. And I went really hard

in this because I thought how technical

candidates were interviewed was

fundamentally flawed. I did a lot of

different things in this video to try

and make it easier for people to hire.

Well, one of those things is I shared a

technical interview document publicly.

Whenever I bring a candidate in for a

technical vetting process to figure out

if they are good enough technically to

be hired for the role, I try my hardest

to set the candidate up for success. And

this is the first mistake I see a lot in

interviews. It feels too much like

interviews are set up for gotchas

instead of success. The goal of an

interview should be the same as your

goal as a manager. Set your team up to

be as successful as possible by letting

them use the right tools, processes,

systems, and things that make it easier

to succeed. You should want your team to

use the things that make them as

successful as possible. And you should

do the same thing around your

interviews. But what if they're using

claude or chat GPT or cursor to cheat?

They should be using those for their job

as well. Then find ways to test their

capability that push against the things

that you're concerned about. Because

when you say that, your concern isn't

that they are going to use cursor on the

job. They should they should use tools

like that to be more successful. Your

concern is that when things go wrong,

they might not have the knowledge

necessary to dig themselves out of that

hole. And for the last decade and a half

plus, we've relied on their ability to

describe code on a whiteboard and write

a crappy app in 20 minutes that's just

sorting a [ __ ] tree as our way of

knowing if they know what they're

talking about or not. That was always

bad, to be clear. But now it's worse

than ever because the same things we use

to poorly vet someone's technical

ability are things that agents can do

immediately with no effort. The fact

that Cluey was so successful is again

proof that the process itself is flawed.

Because if your interview can be cheated

by a crappy AI app and your job can't,

then there's a gap between what the job

expects and what the interview expects,

which means you're doing a bad job

interviewing. That's why I always have

done interviews quite a bit differently.

I specifically try to give options to my

candidates because my candidates should

have the choice of how they think they

would best present their capability.

Again, setting them up for success. What

process gives them the highest

likelihood of succeeding? Obviously, the

choice they make is something I factor

in when I am reviewing them. And

long-term, I don't think the leak code

algorithm puzzles are probably something

we should include in interviews because

they were always bad. I mostly had this

option in here for the candidates that

tried really hard on these things that

had spent a lot of time scaling up on it

and as a result felt more comfortable

with this because again you want the

candidate to be set up for success and

being comfortable is a really big part

of that success. So this is what they're

comfortable with. This is what they

choose. I give examples of where these

types of problems come from and I said a

pro tip. Most of our problems will

probably be based on avent of code

because the team are all avent of code

players. We all take it way too

seriously and most of my challenges were

based some amount around advent of code.

I describe what we do. I say remember

our goal isn't to see how fast you write

the right answer. We're trying to learn

about how you work and communicate

because that's what makes you a good

candidate. I describe the general

structure of this interview. There's 15

minutes of general tech plus team

experience questions. I give a direct

example. 30 to 45 minutes of the code

puzzle. I can say it's pseudo code or

real code, whatever you prefer. and the

remaining time would be used for

questions about the company, role

expectations, etc. Very, very clear

expectations. Nobody coming in for a

technical interview would read this and

choose it and not know what they're

going in for. Option two, the

pragmatist. This is my attempt to do

something more like real world work

where I give you a project or a spec or

an API and say implement this part of

it. Funny enough, not dissimilar to how

I use agents today where I give the

specs, the expectation, what I want the

output to be and then see if the

candidate can complete it. Obviously,

with how things are structured nowadays,

this is a question that could almost

certainly be completed by an agent in

seconds. But I could also then ask the

candidate questions about the code that

comes out and how it works. In fact, I

would already do that when I worked with

these problems with these candidates.

When they wrote the code, I would ask

them, "Oh, why did you break out this

component? How would you reuse this? How

would you make this piece reusable

somewhere else and have the

conversation? Because that's really what

matters with these interviews. You're

talking about hiring somebody who's

going to work with you every day,

somebody who's going to be in your

meetings with you, in your Slack with

you, at your lunch with you. That your

ability to communicate with them is way

more important than how many lines of

slop they can generate. And then my

personal favorite option, the realist.

You bring your own repo or project,

ideally something open source, and then

we shadow you as you work on something

for it. So if you have a feature you

want to add to your project, a thing you

want to build or complete or work on, a

bug you want to fix, you send me the

repo, you send me information on what

you plan to do, and if I think this is a

good way to vet your technical skill and

communication, then we work on it

together for one to two hours. And by

together, I mean you drive and do most

of it, and I ask questions throughout

again to see what it is like to actually

work with you. That's the point of all

of these options, including my favorite

one, the specialist. The point here is

that if you don't think these ways of

interviews work, you can propose your

own. If you think you can have your own

way to showcase your skills, bring it

with you. Show it to me and I would be

hyped to learn. Sadly, I've never had

anyone take this option. But also, I

usually don't hire people that haven't

already proven their technical skill

because if you have a GitHub full of

really useful things or I've interacted

with you in the past on different

projects, I don't need to do any of

this. This all gets thrown away if I

already know that you're good. It it's

kind of ironic that I have what I would

consider to be one of the best technical

interview processes and I also don't do

technical interviews anymore because I

only hire people that have already

proven themselves. So despite having one

of the best processes, I end up using it

the least. That's part of why I'm

putting it out here and continuing to

leave it open source and available

because I want more people to think

deeply about whether or not their

interview process is checking your

[ __ ] leak code skills or is actually

seeing what it's like to work with

somebody because that's what you should

be hiring for. compatibility with your

team. So, I think we've established the

current way people do technical

interviews is [ __ ] and should be

rethought. Something like this.

Obviously, there are parts of this that

don't make as much sense anymore, but

really focusing in on transparency,

clarity, comfort, and communication will

make your interviews way better. The

candidate should feel like you're on

their team, not like you're using a

microscope or a magnifying glass to

catch every little thing they do wrong.

Cuz this person's going to be on your

team. You want them to be supported.

Support them through the process. But in

order to get that far, you need to get

through some other things that are

honestly kind of [ __ ] Here's where

we have to talk about resume slop a bit.

Cold applications are just a garbage

thing right now because every time a job

listing goes up, lots of people spam it

hoping to get in. People will generate

resumes using all sorts of tools, fill

them with fake information and absolute

[ __ ] in hopes that they get enough

attention to have their name clicked on

in the pile of 10,000 names, mind you.

All of which are being read by a

non-technical recruiter at the company.

The stuff just is [ __ ] It isn't

going to get you a job. Like, do you

actually think your resume in this

gigantic pile of PDFs is magical enough

that a random recruiter that doesn't

know [ __ ] about code is going to read

through it, see yours, and pick you? You

need to be realistic about this. Cold

apps just don't work anymore. You need

to find a way to get in front of a

person, ideally a technical one, so they

know you're a real human because the

realness and the transparency is now

rarer than ever. AI making slop so

common means that being genuine and real

is now an outstanding angle to have and

a lever you can use against all of this

[ __ ] Things like interacting with

posts from engineers at the companies

that you're looking at. local tech

meetups if you live in a place that have

that type of thing. Although local tech

jobs are a whole [ __ ] mess of their

own, but finding ways to get facetime

and interactions with the people at the

company you're talking about is

essential because you want to really

increase the odds that you can get

through that first round and get in

front of a technical person so that you

have a higher chance of getting along

with them, getting to showcase your

comm's abilities, learn something, and

then get the role. But if you're sitting

in my comment section like, "I can't get

a job. The whole market is [ __ ] I

applied to 500 companies and didn't get

a single response and your definition of

application is going to random job

listing boards online and finding their

hiring sections and submitting a PDF and

not even adding anything specific to the

company, of course, you're not going to

get [ __ ] hired. There are people

trying harder than you. Don't think

you're going to get handed a job on a

silver [ __ ] platter. It's not how

this works. And to their credit, the

companies are very largely at fault

here. Companies are so bad at hiring

that they're still doing it like it's

the early 2000s. They're putting up

these weird listings on terrible boards

that expect you to submit a PDF or docx

file in a specific format that nobody

even [ __ ] reads and then has a

non-technical person reading through all

of it. They deserve the [ __ ]

employees they're getting as a result.

You got to work around that. If you're

doing all these things right and you're

still not getting a job, you should also

try and be thankful that the companies

you talked to that weren't good didn't

accidentally hire you into a role that

would suck. That said, you also all need

to stop [ __ ] coping. I'm already

seeing it in my chat. Is stalking now a

genuine job search technique? You

deserve your unemployment if you think

interacting with people working at the

companies you're interested in based on

your shared mutual interests is

stalking. your understanding of basic

social norms is so bad that you're not

going to get a job. And it's weird to

put it this way. We'll probably talk

about this more in the junior section,

but your ability to socialize on a basic

level went from a nice to have to a

borderline essential skill if you want

to get a job today. I have a lot more

thoughts on why companies suck at

hiring, but I'm going to dive into the

experienced devs part cuz I think it'll

cover a lot of this as well. It's hard

to know which of these numbers is the

most real when it comes to what the

current state of unemployment and job

struggles are in the market. Like the

info from Hacker Rank, this 74% number

is an interview that they did with their

audience. And obviously a platform like

Hacker Rank for getting a job is going

to have a different set of numbers than

places that are interviewing engineers

in general. So I don't know which of

these numbers we can really trust. What

I do know is that I'm seeing less junior

devs on average getting roles and I see

more senior devs on average getting in

demand. But what I'm also seeing is a

lot of experienced devs that are

struggling a lot both at their current

role in their current job as well as

presenting themselves as a good option

for getting a job other places. There

are lots of people that did their first

ever interviews right after college, got

one job out of the 10 they did, and have

just stayed there indefinitely. have

never bothered leaving because they

don't really want to. And now they go

out and do interviews and they're

performing in them slightly worse than

they did when they first got jobs 5 or 6

years ago because they haven't refined

the skill at all since. And that's not

the only skill they haven't refined.

Once you've had a job for a while, your

willingness to learn almost inherently

starts to go down. As your job gets more

and more specific internally, your

likelihood of exploring other things

outside of the job inherently goes down.

And if you're at one of those companies

that isn't letting you use AI tools

internally, you're probably falling

behind in that regard, too, which is

terrifying because those junior devs

that don't have jobs don't have any of

those restrictions on them. You need to

put more work into staying ahead. Here's

another way of thinking of it. When a

junior engineer comes in, they have lots

more energy. They don't have the jaded

attitudes that people get over time.

They're not as restricted to certain

ways of thinking or doing things, but

they don't have the same capability. Be

it their experience in general, like

they don't know what languages have what

compromises, what libraries do and don't

make sense, how you deal with outages at

a company, all those types of things,

but also role specific capabilities and

company specific capabilities. They

don't have the institutional knowledge

of how your business operates. Whereas

an existing senior dev at your company

has lots of capability. They have years

of experience that are both generic in

terms of how things work, but also

specific in terms of how your company

works. But their energy and their

willingness to learn new things has gone

down as a result. There's always a

trade-off here. The better somebody

knows how to build and more importantly

how to work at your business, the lower

their ability is to go try other things

and experiment and explore. And

balancing these two things over time is

essential as a business trying to

operate long-term. The real win is when

you find ways to get energy transferred

effectively from juniors to seniors. And

the trade-off is that the senior

engineers get excited working with and

hanging with those junior engineers and

they inherently pass some of their

capability on to the juniors. Once you

can build that type of relationship as a

business, that's when things really

start to go crazy. When the seniors

trade their capability for the junior's

energy and everything feeds in and you

grow. This is why people like Dan

Abramov used to brand themselves as a

junior for life because they wanted to

maintain their energy more than

anything. And as you get more

experience, you'll find yourself longing

for this. I like to think I have higher

energy than average for somebody with my

15 years of experience because I love

new [ __ ] That's just how I am. That's

why I have this channel. I love

exploring new solutions to problems and

then bringing them to people who might

not have went and found them themselves

in the first place. That is just one of

the most fun things for me. And I think

it was the senior engineers encouraging

that in me early in my career that

helped me maintain it over time. This is

also a thing that big companies seem to

be struggling a lot with. I've been

thinking about this clip non-stop since

I first saw it.

>> For the first 25 years of Netflix, as

I'm correct, the only software

engineering level used to be a senior

software engineer. You've [music] now

started to hire earlier career software

engineers. Can you tell me on how that

has changed the culture at Netflix?

We've had a great experience with new

grads and early career talent and also

our internship program which you

mentioned. [music] We were starting from

a very different place than a lot of

other tech companies. So when you look

at the distribution of levels or talent

at some of the [music] other larger tech

companies they had in some cases 30 40

50% [music] what I'll call level three

level four engineers. So when you think

about a new technology shift or the work

that those companies need to do now I

understand why they might need a

different [music] distribution of

talent. We were starting at 0% in most

cases. We had mostly a level five and

above population. So we had a huge

opportunity to complement the team we

had with earlier career talent who

brings new skills, new perspectives,

great energy to the teams and with a

technology shift right now with Genai, a

lot of native AI familiarity. So when

you think about somebody who's graduated

from school in the last few [music]

years, they're very accustomed to using

AI in whether it's developing products,

writing code, thinking about solving

data problems. It's [music] actually a

useful way to bring new skills and

perspectives to the team. I think we

will absolutely maintain [music] that

investment in earlier career talent

because it's been so additive in

different parts of the business. But I

also think everything in its right

proportion. [music] There's plenty of

problems where we need extremely

>> you get the idea. The very interesting

thing that was touched on here is this

idea that newer career devs, earlier

career devs bring unique energy, unique

perspectives and what she referred to as

native Genai attitudes and perspectives.

I have a lot of thoughts on that bit,

don't worry. But I want to give a little

more advice to the seniors first.

There's a good chance if you're a senior

developer that is starting to do more

interviews, you haven't done them in a

while. I highly recommend first and

foremost that you do a lot of them on

the other side. Take advantage of the

fact that you have a job and see how

much you can get involved in the

interview process. Do way more

interviews. Almost every time I talk to

a person that's struggling to get a job

that has years of experience, they have

almost no experience facilitating

interviews. The more you can facilitate,

the more you can see the other side, the

more you can become aware of what a good

or bad interview looks like and can make

changes accordingly. You need to be

really introspective more so than ever

now because historically code was so

rare and coders were so valuable that

developers were allowed into roles that

they might not have had the linguistic

capabilities for. People who weren't

very pleasant or good at communication

would get away with it because the need

for rockstar developers was so high.

Now, there are people who are not

necessarily as technically gifted, but

are way better at communication that are

much more obviously good hires because

those communication skills have never

mattered more. And this is regardless of

your perspective on AI. If you think all

AI code is slop and that your

handwritten C is the only right way of

doing things, you might be right. But it

doesn't matter how right you are if you

can't convince anybody. So, if you're

going to compete with AI slot being

churned out by these cloud code kids

that have never written a real line of

code, you better be able to explain why

your stuff is better. Getting better at

communication and explaining your ideas

has never been more important and

historically hasn't even been that

valuable as a developer. Now that that

has shifted, you need to present

yourself differently. Do more

presentations internally. Take more time

to document things, to write internal

blog posts about things, to see if some

of those blog posts can be published

externally to discuss your engineering

learnings as a business. Find ways and

incentives to better your communication

skills because otherwise you will lose

to the AI whether or not it is better

because you can't properly communicate

why you're right. And I promise you

almost all of the people I am thinking

of here, the ones who are experienced

devs who can make great code that are

struggling to get jobs, 100% of the time

suck at communication. You have to get

over that. Not being able to clearly

describe what you're doing and why was

only acceptable because of the nature of

code being novel enough. We are past

that point. Get over your [ __ ] But now

we need to talk about the thing most of

y'all are here for. Junior devs. It's

tough out there. I won't pretend

otherwise. Getting the attention of an

experienced enough dev to even be

considered is not easy. We need to do

things a bit differently and use every

lever you have. But before we can start

doing things right, we have to stop

doing things wrong. Let's go through

some of the most common mistakes I see

with earlier career devs. I already

talked about the cold apps. Cold

applying to random companies with shitty

resumes that you generated on chat GPT

is not going to get you anywhere. And

no, a handcrafted one isn't going to get

you that much further. Cold apps are

dead. There's just too much [ __ ] going

in. You need some way to stand out from

it. And the way you stand out isn't

anything you can put on the resume. It's

humans. It needs to feel more real. I've

said this for a while, but the biggest

differentiator in everything, but

especially hiring, is trust. You need to

find ways to build trust. If you're an

early career dev, we can't trust your

job history because it's not there. So,

we need other things we can trust.

Things we can trust include somebody at

the company. thinking you're pretty

good. Somebody recognizing one of the

libraries you use, somebody reading one

of your blog posts and realizing that

it's relevant to their work. Whatever

you can do to build up trust is going to

be key. Remember that. So, we'll be

talking a lot more about trust in a bit.

So, cold apps suck. Don't expect that to

be a thing that will get you anywhere.

Your professor sucks, too. This is

another really important thing to

understand. Something I've seen a lot of

is earlier career devs or people fresh

out of college and the best dev they've

ever known was their professor. The

harsh reality is that your professor is

almost certainly not a very good dev

because most professors make less money

than good devs. And if your professor is

teaching, it's probably because they

didn't like doing, they didn't do well

with the doing, or they got tired of it

for some reason. And I can't tell you

how many times I saw in college that my

peers were running circles around my

professors. And I was lucky that my

professors largely understood this. They

knew their experience was really, really

behind. And they leaned on the students

that were most excited, most energized,

and most ready to teach those things to

guide us towards what the most useful

things were. Your professor can teach

you a lot about how to think technically

about problems, but they will not teach

you how to get a job. They will not

teach you what working in the industry

looks like today. They will certainly

not teach you about getting ahead of

your peers in a way that makes you more

likely to succeed beyond giving you

homework that you're probably using AI

to cheat on anyways. Your professor is

not going to give you the pieces you

need and the knowledge you need to get

your job. Another common mistake I see

is obsessing over qualifications. And I

understand why this happens. In order to

get into college in the first place, you

needed to have all of these crazy

accolades on your application. like you

were the head of some club at your

school or you had this experience

working this specific charity or you had

really high grades, you got the perfect

score on the SAT, all those types of

things, that [ __ ] does not matter

anymore. It barely did before and it

does not matter now. Chasing prestige,

chasing accolades, chasing these

qualifications is not going to help. and

going and getting some random

certification from Microsoft that you're

Azure certified or office certified.

None [clears throat] of that [ __ ]

matters. I don't know anyone who's hired

anybody in the last 10 years based on

their qualifications in those senses.

They are hiring based on the fact that

they are potentially good fits for the

team. That is it. And now for the thing

that will likely be the topic for most

of the rest of the video. Outsourcing

your learning via AI. Or put

differently, avoiding learning with AI.

Feeling dumb sucks. Humans optimize

their lives to avoid it. And it makes

sense why. Like biologically speaking,

if you have the option between two

foods, one that you're familiar with,

have eaten a lot, and know is safe, and

one that you've never seen before or

tried before, the one you've never tried

could be poisonous. So obviously, you

don't want to try it. The fact that you

don't understand it makes you inherently

averse to it. But the harsh reality

about software engineering is that you

are at your best when you feel kind of

dumb. That's when you are pushing past

your experience, past your expertise,

and building yourself up and growing.

Does this mean you should avoid using AI

tools? No. Notice my wording here.

Avoiding learning with AI is the key.

Not that you should avoid learning with

AI, but this is a thing that you are

probably doing right now. When you run

into a problem and you don't understand

it, you use the AI to work around it or

to have it solve it for you, and you

don't improve your own understanding at

all. you are reversed to this feeling of

being unsure or clueless and rather than

embrace it and spend time in it and

resolve it, you outsource it so you

don't have to spend any time in it and

that keeps you from building up skills

that are valuable. To contradict myself

a little bit here, HTMX is a project

that is largely by a professor. His

name's Carson. He's great. Carson thinks

a lot about how we learn and he knows

that his students are going to use AI

tools. instead of just letting them

cheat on all their homework with that,

he actually goes the other way. He knows

that the students are going to be using

these types of AI tools. So, he instead

hands them an agent MD file. If you're

not familiar, an agent MD file or a

cloud MD file steers the agent by

putting something at the start of the

context that gives it instructions on

how to operate. Generally, here is said

agent MD. Primary role is teaching

assistant, not codegenerator. AI agents

should function as teaching aids that

help students learn through explanation,

guidance, and feedback, not by solving

problems for them. I see that M dash,

you generated this, didn't you? You sly

fox. What agents should do. Explain

concepts where students are confused.

Point students to relevant lecture

materials or documentation. Review code

that students have written and suggest

improvements. Help debug by asking

guiding questions rather than providing

fixes. Explain error messages and what

they mean. Suggest approaches or

algorithms at a high level. Provide

small code examples that are two to five

lines to illustrate specific concepts.

Help students understand assembly

instructions and register usage. That

one's a bit of a reach, but I

understand. And explain memory layouts

and pointer arithmetic when asked. What

agents shouldn't do. Write entire

functions or complete implementations.

Generate full solutions to assignments.

Complete to-do sections in assignment

code. Refactor large portions of student

code. Provide solutions to quiz or exam

questions. Write more than a few lines

of code at once. convert requirements

directly into working code. It gives

guides on the teaching approach on how

it should give good code examples and

then the classic this belongs in any

good agent MD or guiding file examples

of what good looks like and examples of

what bad looks like. And to be clear, he

doesn't enforce this in his courses. He

wrote this and published it and

recommends it saying, "Look, here are

the guardrails. I can't make you use the

guardrails. If you want to be a good

programmer, though, you should use these

guardrails." He moved everything to in

person on paper to make it harder for

people to cheat with AI, yada yada.

Adapt, improvise, readapt. Love this

framing in particular. This is one of

the things I love about Carson. He

constantly is reflecting on what is and

isn't working. And instead of rejecting

the norms and rejecting where things are

going, he finds ways to adapt them to

better fit into his role, which is

setting his students up for success. I

wish we had more professors like him. He

is very, very good at this. But I will

contradict him a tiny bit here. Not in

this in using it for his coursework.

Absolutely. If you're taking a course

from him or someone like him, highly

recommend for all the course work you

use an Asian MD like this and you follow

the rules accordingly. This will make

you much more likely to succeed. But at

the same time, you have a really unique

lever you can be using right now. Here's

we're going to start talking about the

things you should do instead. Before we

can do that though, I want to go on one

of my personal favorite tangents. We're

going to talk about mobile applications

for a little bit. If you are younger, as

in like a Gen Z that's going through

college or finishing it up right now,

some of the points I'm about to make

might doubt me a lot. I know I'm about

to uncstat myself hard, but hear me out,

okay? Imagine back in the day, you see

mobile phones suddenly getting really

good. Historically, we've used computers

for everything. I know you guys are

learning how to use computers now in

college, but we used to have to do it in

elementary school. And no, I'm not

talking about a Chromebook. I'm talking

about an actual computer with files

where we would plug in flash drives and

floppy discs, if you remember what those

are. Suddenly, mobile phones started to

get way more powerful. They could do

more. They could send emails. They could

browse the web. They got really

powerful. And it happened really

quickly. And you see an obvious trend

here. You know, the future, it it's

clear. We're going to be using computers

less and our phones more. Why would we

reach for a gigantic laptop in our bag

when we could just pull out our phone

and do the thing? And you want to bet on

the future. You're scared of falling

behind and you know this is what's going

to happen. So regardless of how much

experience you have, what work you're

doing, you decide it's time to go allin

on mobile. So you drop everything to

build Java applets for the Nokia

sidekick. Yeah, this is kind of funny in

retrospect, but at the time it was

pretty clear and more things were going

to move to mobile. And if you didn't

want to fall behind, made a lot of sense

to go put all of your effort and time

into building things for mobile phones.

So you would build for Sidekicks or

Blackberries or the things that were

popular at the time. All of which

together had less than 5% of the global

phone market share because smartphones

as we knew them, these types of devices

just weren't that popular. The hope was

that long-term they would become more

popular. And they did. But they got more

popular in a very different fashion.

They didn't look like this. It looked

like the phone you're watching this on,

the iPhone. The iPhone changed

everything. And when the iPhone first

dropped, they didn't even have an app

store. All they had was HTML 5 and web

apps that were inherently really

limited. About a year and a half after

the iPhone dropped, they realized they

needed to let you build real apps. So,

they put out an SDK and an app store.

But think about this for a second. The

Sidekick came out in 2002, and lots of

new versions came out over the next few

years. The original iPhone was 2007, 5

years later. Now imagine you spent 5

years going allin on sidekick

development on BlackBerry development,

on Nokia development, building for all

these weird bespoke proprietary

operating systems. And then the iPhone

comes out, takes half the market, 50x

what you thought was even possible, but

all your experience is building apps for

these old dated archaic platforms. You

don't even know how to interface with a

touchcreen properly. You're switching

languages, you're switching ecosystems,

you're switching operating systems,

you're switching user experiences,

you're switching expectations,

everything changes going from Nokia dev

to iPhone dev. So effectively what

happened there is you just wasted years

of experience and it'll take you even

more time to unlearn it. So let's think

about this. Who's better off? a

developer with 10 years of experience

who just spent three years building for

dead platform

that has to unlearn all that BS for the

new thing or somebody who's fresh out of

college, never learned wrong thing and

is excited to go all in on right new

thing. Which of these people is better

off? Very obviously these ones. the

people who don't have to unlearn the

weird ways that they did things in the

past and can just dive in fully on the

new way of doing. So, this is obviously

about mobile, but let's talk about AI

dev. Imagine a developer who's been

coding for 10 years. They used to be a

big sublime text person. They moved to

VS Code and now they're all in on Vim.

They became a hardcore neovim person.

They've been building for all sorts of

different things at their job and

realized that this AI stuff probably

matters. So they put a lot of time into

their custom config trying to get stuff

like you know the classic co-pilot

working in Vim worked really hard to do

that started using stuff like super

maven tried their best because they

cared so much about their developer

experience and their use of their editor

that they wanted to do everything

through the lens of Vim. Now all of a

sudden we are using agents in our

terminals and our IDEs and all these

other places to generate all of that

code and they are fighting tooth and

nail pretending that none of that

matters and that they are still way

better. But now they have to deal with

it now. Maybe 6 months ago they didn't,

but now these tools are good enough. If

you're not using them, you are

definitely falling behind some amount.

Their willingness to unlearn all of

their way of doing things for long

enough to embrace these new things is

way lower. The 10 plus years they have

of experience is hurting them now. And

everybody's saying I'm sneak dissing

Prime. No, I actually love Prime for

this reason. I think Prime is doing a

great job of challenging his notions and

not letting his way of building things

traditionally keep him from trying out

new things. For every person like Prime

who's actually trying to figure out why

we're all so hyped, there are literally

a hundred plus that have no interest at

all that are coping and running in

circles claiming that everybody's doing

slop and they're the one doing things

right. And that same person also sucks

at communication, so you can mostly

ignore them. But you're not that person.

You're fresh out of college. You're

really excited to try out all of these

new things. You're playing with new

stuff. You're doing whatever you can to

accelerate your own stuff, your ideas.

you're you got into code some part

because you want to make money, but some

part because building things on a

computer seemed fun to you. At least I

hope. If you're just here for the money,

go somewhere else. My channel is not for

people who are just using software to

make money. We love this stuff. And I

like programming, which makes a lot of

people question why I like this AI

stuff. I like programming because I like

the problem solving aspect and I like

building useful things for myself and

for others. And with AI, all of that's

gotten way better. So imagine the person

who just loves their Blackberry, who's

been building apps for Blackberry, who

dedicate their whole life to the

BlackBerry ecosystem. Obviously, that

person is going to be useless when the

company needs to build a phone app.

That's kind of where we're at now, too.

These people who have 10 years of legacy

way of building that are deeply attached

to each individual piece of the software

stack they use, of the editor that they

build in, all of those things. that

person is not going to embrace this

stuff without a lot of incentive to do

such and they also probably have less

energy at this point too because they

were trying all sorts of new things

early in their career. They slowly

settled on what they have and now

they're not as interested in trying new

stuff. That is not the case down here.

Somebody who's fresh out of college is

not going to be unwilling to try a new

editor. They're not going to be

unwilling to check out these new dev

tools. They're not going to be unwilling

to explore these things. In fact, quite

the opposite. They might be excited

about them. They might be trying all

sorts of new stuff. And that's one of

the things I want to encourage. On one

hand, when you're doing your coursework,

you shouldn't be using AI to cheat. I

highly recommend this guest, and the

link will be in the description, don't

worry. If you want to use AI correctly

in class, but the harsh reality is that

if you're only coding for classwork and

you're not doing anything else outside

of it, you're probably [ __ ] So, to go

back up here, what you should do instead

is use the new tools to do cool [ __ ] I

don't mean you should use it to cheat on

your work, but maybe if one of your

assignments in class was really cool and

you want to build it into something more

thorough, you can work with some of

these new AI tools to push it further to

build something bigger. Maybe there's a

club in school that you really like that

needs a better way to keep track of its

balance and its budget and what people

are doing for the club. Vibe code an app

using these new tools to try and make

that useful. I'm at the point where in

an average workday where I'm actually

sitting and doing things for my job, for

my channel, for my companies, for my

products, I am vibe coding one to two

new apps from scratch a day to just

experiment with ideas, try to solve

problems, build things in the

background. Even now, as I'm streaming,

I'm working on a project to help me find

and identify project ideas and video

ideas based on things being posted on HN

and on places like Simon Willis's blog.

and I'm going to compare that against my

channel and use an AI agent to compare

and contrast and find ideas that I might

not have covered yet that could be good

topics for my channel. I just build

random [ __ ] like this all the time when

I have a theory or an idea or some

question I want to answer. I love using

these tools to build all of this stuff.

One more borderline essential thing that

like especially in college, but

especially if you're not in college is

essential to everything we talked about

here, collaboration. Most of your

coursework is going to be individual

things that you're working on

independently yourself like your tests

and your homework. There will be some

amount of coursework that is hopefully

collaborative, but that varies a lot

depending on the school, the program,

and many other things. Your job isn't

just to take an issue and write code.

Your job is to be a member of a team.

And working with other people is

essential to being successful in this

field. Getting good at collaborating is

key. Collaboration can be all sorts of

different things. It can be mentoring

earlier students and helping them with

their homework. It can be building

things with your friends that are useful

to the clubs that you attend. It could

be making a project with a few friends

to help you keep track of stats in a

video game you play. It could be going

to hackathons and building things from

scratch at those. Hackathons in general

are really cool. Finding opportunities

to collaborate will help you level up

your skills as a developer so that you

understand what it's like to actually

have a job. And even more importantly,

it'll help you make connections that'll

be essential in getting jobs in the

future. To this day, despite the fact

that I have been coding for 15 years, a

significant portion of my coolest

opportunities come from my friends that

I went to college with. People like my

CTO and roommate Mark. I met him in

college. We actually didn't interact too

much in college. We were just part of

each other's rough friend groups from

the other things we did, but we ended up

very aware of each other and what each

other was good at through the

connections we had as we collaborated

with other people in each other's

networks. So, when he moved out here, he

was looking for a place. I knew him

pretty well. I suggested he considers my

extra room and since then we have been

best friends building everything we

build together. These are connections I

made through college through

collaboration both directly and

indirectly and those types of

connections are essential to being

successful long term because when you

are eventually looking for a job if one

of your friends from college that you

built things with is on a team that's

hiring and they know that you're

pleasant to work with you get to skip

that whole pile of [ __ ] resumes and go

straight into the interview. Those types

of things are essential. It's not what

you know so much as who you know is the

common phrase, but that's very real. And

you're starting to build up who you know

in your classes. And this is why it's

even more important if you don't have

courses to find ways to collaborate,

build useful things, find other people

building useful things, find ways to

work with them, find Discord servers to

hang out with these people, find

projects that you could be useful to.

Just building things with people will

help so much. Mickey's hanging out in

chat. If you're not already following

his channel, definitely give it a look.

He's had a couple really cool jobs,

including Convex, one of my favorite

companies in the space. And as he just

said, he didn't interview at Tempo or at

Convex. It was the companies reaching

out asking if he wanted a job because he

made a splash in the spaces they were

in. They saw him and they were

interested in potentially working with

him. Those are going to be the coolest

opportunities. And you get those by

being useful and building trust with

people way earlier. And you don't do

this expecting every single one of these

connections to come out and be useful.

You'll probably only have one useful one

for every 10 to 50 people you work with.

But the goal is again to increase the

odds that things go well for you. We're

trying to stack the deck. The more cards

you draw, the more cards you put in the

deck, the more outcomes that are

positive that exist within it, the more

likely you are to have a good outcome.

If you make two friends in college and

neither end up getting a job or on teams

that are hiring, you're screwed. If you

make friends with 20 devs in college and

three or four of them end up on teams

that are hiring, your likelihood of

getting a real job soon is way, way

higher. And if you find yourself jealous

of that super social person that you

went to college with that like was on

the football team or whatever, barely

knew how to code, but got a job fresh

out of college, this is why. They made

the connections and the friendships, and

they were pleasant and easy to trust and

work with. Even if the work was bad,

they made it easy to do. The easier you

can be to work with, the better chance

you have at getting work. I have a whole

video about luck surface area that goes

deeper on this idea, but you really need

to be focused on increasing the

likelihood that a lucky thing happens

because in the end, getting a job is

luck some amount. So, the more

opportunities you have to have that

lucky thing happen, the higher

likelihood you have to succeed. On that

topic, here's one that's a little harder

to describe that's very, very valuable.

Be useful. This is tough because there's

two sides to it. There is the being

useful part, but more importantly,

there's the understanding how to be

useful part. You don't know what useful

is until you've experienced it on the

other side. And you get there largely by

doing things. Here's an experience that

you either have or haven't had and which

you fall on will tell me a lot about

where you're at. You're working on a

project. You have some weird error

happen when you use this specific

library. You have no idea what's going

on. So, you Google search it. The first

two results are useless, but the third

one is a random old GitHub issue where

the person reported the problem and then

three months later somebody else said,

"Hey, I have this problem too. Here's

how I solved it and now it's been 3

years and their answer kind of works but

is also out ofd and not supported." But

at the very least, you unblocked

yourself by seeing that. If you haven't

had an experience like that at some

point, you're not building enough. You

need to go ship a lot more. Something

you'll learn is there's a lot of

valuable knowledge and information

around the web from other developers

over the last many decades working on

things similar to you running into

problems similar to you using

technologies similar to you. And here's

the kicker. Those people are also

similar to you. And if you can relate to

them and you can understand them, you

can very quickly become useful to them

and then eventually become friends of

theirs. So, if you do have issues like

that, if you have a problem with a tool

you're using and you find one of those

old threads and the information in it is

mostly right but kind of out of date,

figure it out, fix it, and leave the

comment that unblocks the next person.

I've legitimately hired somebody because

I recognize their username from a GitHub

thread where they solved a problem that

I was having. I know it sounds crazy,

but I've actually done that. It wasn't

as direct as I recognize your name, you

get a job. But when they hit me up about

potentially working with me and their

username on Twitter was the same as

their username on GitHub and I

recognized them, I was like, "Oh [ __ ]

do you use this library?" They're like,

"Yeah, I'm in the issues for it all the

time." That was a huge trust builder

because it meant that this person isn't

just hitting me up with a random cold

resume. They're actually in the weeds

doing the [ __ ] and they understand the

same things I understand. They spend

times in the same places I do. when I am

hiring as an engineer, I'm not looking

for people who feel very different from

me inherently. So, the more you can be

in my spaces and do the same things I do

and breathe the same air I breathe, so

to speak, the easier it is for you to

get that job. Note things that I didn't

say here, pull requests. I'm not saying

you need to go contribute all sorts of

slop to random GitHub repos. In fact,

nowadays, that's kind of a bad look. I

also didn't say fill GitHub with all

sorts of random open source projects

with 0 to one stars. What I did say very

very explicitly is spending time in the

issues tab. Being useful in issues is

one of the best green flags I can see

from a developer. If I go check your

GitHub profile and what I see is you

opening detailed issues with clear

reproductions on the problem you had so

that somebody could go solve it and I

see you commenting on existing issues

with useful information and then I see

you hanging out in the Discord

communities for these projects answering

people's questions linking them to the

right sources and then I see you hanging

out in my Twitch chat like a lot of

these people are dropping me really

useful resources throughout like Maria

here just linking a video I was

referencing to somebody that was based

on an article that was written based on

my video. It's so surprisingly easy to

be useful, but you need to understand

what useful is. And the only way you

know what useful is is if you're doing

[ __ ] You don't know what a useful issue

is compared to a useless one until

you've seen both and one helped you and

one didn't help. You don't know what a

good answer to a question is until

you've seen them happen in the Discord

server or you've asked one or two of

them yourself. You got to be in the

trenches to understand the trenches. And

once you understand them a little bit,

you'd be amazed how quickly you can

become useful. One of my favorite

interactions I ever had that happened in

my Discord, pretty sure it's Roy. Roy,

thank you, Chris. Legend. Again, the

people who hang out here a lot and whose

names are associated regularly with

things that are useful, become my

favorite people. The moment Chris needs

a job, I will hand him to any company

interested because he comes in and

answers the like if I can't complete the

thought, he can because he gets it and

he Yeah, you get the idea. So the

example I want to give is somebody from

my community named Roy. Roy very quickly

became one of the most helpful people in

the community despite the fact that he

didn't have a software dev job. He was

effectively doing semi-technical

customer support and was building things

on the side for fun. This is Roy. Sorry

for calling you out like this one, man,

but you are the literal golden example

of what I'm describing here. It's also

worth noting that Roy was a career

shifter. He did not go to school for

software development as far as I recall.

He was working in other spaces and

teaching himself how to code on the side

and through that found my community, had

a couple questions, really liked the way

we were building, and very quickly

became the number one question answerer

in my Discord. After a few weeks spent

there, he started to get the things we

built and why we built them that way and

internalize these concepts and quickly

realized he could just answer the

questions. Eventually, another dev that

you guys might have seen on YouTube,

Melky, started hanging out in my server

as well cuz he was starting to use my

stack, the T3 stack, and he had

questions about it. In particular, some

weird things he wanted to do with TRPC.

Roy answered his questions in my server

very quickly. Afterwards, Melky started

DMing Roy, asking him questions about

these things because he wanted to go

even further and found Roy to be really

clear, concise, and useful. Melky

randomly hits me up a week or two later,

saying, "Holy [ __ ] Roy is one of the

most useful people I've ever talked to.

He's so helpful." To which I respond,

"Yeah, isn't it crazy that he doesn't

have a dev job yet?" Melky's response to

this was one of the funniest messages

I've ever gotten. Dot dot dot. You're

joking, right? Wait, you're not joking?

What the [ __ ] I thought he was at least

10 years my senior. What do you mean he

isn't an experienced developer? What do

you mean he doesn't have a job? What the

[ __ ] Theo? Which I then screenshotted

and sent to my friend who was hiring at

Clerk. And sure as [ __ ] Roy now works

there. If you ask anybody who's worked

or works at Clerk about Roy, their

response is going to look something like

this. He's now a knowledge well within

Clerk. Everyone loves working with Roy

because he just cares to be helpful. and

he felt so grateful to the community for

helping him learn that he paid it back a

hundfold and is now a golden example of

how to do this. He used my community in

space to learn and through that process

learned things that others hadn't quite

learned yet and could use that to be

useful. He immediately paid forward 10x

what he had gotten from MySpace. I would

argue he barely got anything other than

some names of some cool technologies,

but became one of the most important

people in said community very, very

quickly. And it's not that hard to do.

Huge shout out to Roy. He more than

deserves all of his success, but more so

than me or other YouTubers, I think Roy

is the model you should be looking at

for how to do well in the fast, quickly

changing tech landscape. So, what does

it look like to do this? Now, obviously,

people ask AI more and more questions

and they ask Stack Overflow less and

less. So, a lot of these opportunities

aren't as visible as they were before,

but believe me, there are still plenty

of them. There are so many repos that

have lots of issues on them that don't

have a good reproduction. If you are

working with a tool and you run into a

problem and you find an issue that's

already cut for that tool that doesn't

have a reproduction, it doesn't show how

to replicate it, it purely shows a vague

error message about the same thing you

had. go in there with a reproduction,

spin it up on Stack Blitz or make a new

GitHub repo that is very simple, minimal

example that showcases the issue. This

shows so many different skills. It shows

that you're resourceful because you

found this issue. It shows that you're

not trying to waste people's time

because you were trying to make it

easier to solve the issue. It shows that

you're not just trying to get a random

drive by PR because a PR filing might be

with the goal of getting merged.

Nobody's commenting on an issue so they

get credit. They're commenting on issues

so the issue can be resolved. And it

also shows that you understand the

problem space well enough to reduce it

to a very easy to see version of the

same problem. If you can come in and

say, "Hey, I looked at this. These three

things didn't solve it. Here is a simple

example that showcases the problem." You

bet your ass every maintainer on that

project that sees it is going to

remember your name and like you. And

it's not that hard to do that. Or if

you're on Twitter and you see somebody

having an issue with a thing, reply to

them or DM them offering to help. or you

see somebody in a Discord server asking

questions about a thing you just had to

resolve yourself, tell them how you did

it. Every time you have a problem,

someone else is going to have the same

problem. Do your best to remember it and

try and it's a weird way of thinking.

Try to write down the two sentences that

would have saved you that time. If you

spent a day or two trying to figure

something out and then finally figure it

out, think to yourself when you're still

in that questioning moment where you

just figured it out, you have a really

novel opportunity to take what you

learned and try to find the smallest

version of it that could have helped you

a few days ago when you first had the

issue. Try doing this and maybe, just

maybe, try writing it down because in

the future you'll see someone else

having the same problem. And if you

offer to help, you are suddenly way more

trustworthy, way more collaborative, way

more useful, and way more memorable. I

remember the usernames of the people in

my chat who answer questions for me, who

bring me useful resources, who build me

useful [ __ ] You got to be memorable,

though. Being yet another resume on a

pile of [ __ ] is not going to get you a

gig. But here's where things get really

fun, though. If you do all of this in

particular, you really start to lean

into these new tools to do cool [ __ ] and

you're seen as useful to others, you can

kind of win against all of the levers.

The hiring manager that doesn't know

[ __ ] about tech sees you have the

credentials and you know how to use

cursor and claw code really well. That's

AI. He's AI ready. Cool. And then the

actual engineers on the team are like,

"Oh, I've seen him pop up in the GitHub

issues for the things that we use. I've

seen him be useful in our space. That's

awesome." And then the exec at the

company is like, "Oh, we're hiring AI

native engineers, people who grew up

using these tools that can modernize our

company." It's [ __ ] but you can

lean into that. Use the lever they're

giving you. Take advantage of weird

statements like the one that the CTO of

Netflix made here about how juniors are

AI native. It's stupid, but take

advantage of it. And I'm not saying

cheat in class. I'm saying use these

tools for all sorts of different things

and use it to accelerate your learning,

your growth, and your completion of

things that you want to build. One last

piece, cuz I realize I should bring this

up more, cuz a lot of you will struggle

with coming up with ideas on what to

work on, especially early when you

haven't wired your brain in a way where

problems are now things you can go build

solutions to. Try turning your questions

into projects. It'll feel weird

initially. Just as a quick example, a

question I had was which different AI

models were better at writing? If I

wanted to use a model to generate copy

for my homepage or help me write an

essay, which models are better and worse

at this? Sure, there are some benchmarks

here and there, but I didn't like those

benchmarks. They didn't align with my

experience using the models. And I was

also curious how they would handle

feedback. If you give a model a review

of what it wrote and told it to adjust

accordingly, how well will it handle

that? So, I vibe coded a little app

locally for having it models generate

essays based on a prompt, having all the

other models give it feedback. It could

then update the essay and then comparing

all of those. And it was really fun. I

learned a ton and I made actual novel

discoveries about how the different

models behave in a writing scenario and

how they compare to each other. It was a

really fun project and I learned a bunch

and have a lot of fun things to talk

about when I talk to other companies and

people in the space. When you have

questions like this, try building your

own solutions. If you want to know how

much faster Solid and spelt are than

React, build something to figure it out.

If you want to figure out why it's so

hard to scaffold the C++ project, build

some scripting to automatically do it

for you and see where the shortcomings

and foot guns are. If you want to see

why people think Rust is so much better

than Go, vibe code the same thing in

both of them and see the benefits and

negatives of each. Build things to

answer your questions and you will learn

so much. Okay, I lied. There's one last

thing. Be excited. I know this can be

hard, especially if you're in that

terrifying, oh my god, school's about to

end. I don't have a job yet moment. If

you've had something that was your job

your whole life, be it you were in

elementary school, then middle, then

high school, during the summer, your

job's to relax, and then during college,

your job's to learn. When that's over,

if you don't have your next thing, it

can be scary. You can't let that feeling

win. Excitement is essential for

success, more so now than ever. And this

is your biggest lever against those

experienced engineers. The energy you

bring in. The fact the whole field is

changing is scary. Absolutely. But it's

also exciting as hell. You don't have to

give up 10 years of knowledge to be

successful. A lot of the people on this

side are going to have to give up a lot

more than 10 years of knowledge in order

to survive all of these changes. You

don't have to code for 10 years to learn

how to build a solution to your problem.

That's so cool. And because your brain

works different, you'll see things

differently, too. People who were really

into the Nokia into the Blackberry did

not know how to use a smartphone with a

touchscreen keyboard for a long time and

they couldn't figure out how to build

their apps around it because their

mindset was so deeply baked into the old

way of doing things. And the things are

changing quick, too. They're already

very different than they were when I

grew up and they'll be even more

different in a year. Take advantage of

that. Anything you can think of, you can

build some version of. Maybe you can't

build a multi-million user billion

dollar a year product that scales

infinitely across every platform. But if

you want to build Twitter for dogs, you

can go do that with not that much

experience and you'll learn a lot

through the process. Be curious, be

excited, be collaborative, be in the

trenches, do [ __ ] and as long as you're

here with us and you're hanging out with

us and you're talking to people that

work in code every day, you'll probably

do pretty well. I would bet pretty good

money that you could measure the number

of devs somebody talks to in a given

week against how hard they are

struggling to find a job and it'll be a

pretty linear relationship. If you spend

more time interacting with devs, working

with other devs, talking to them,

hearing what they're doing, hearing what

they're struggling with, collaborating

with them to build your own solutions,

answering their questions, asking them

questions, you will almost certainly

figure things out. But you got to be

there and you got to start being useful.

Balancing out how much you ask versus

how much you share is a key part here,

too. Your goal should be as quickly as

possible to give more than you take. To

answer more questions than you ask, to

be more useful than you are using. The

best thing in the world you could ever

do in one of these technical interviews

is answer a question that the person

giving the interview doesn't know or

understand. Be collaborative, be useful,

be energized, be ready, and eventually

you will start to build the types of

trust you need to be successful. And one

last thing, I would like to selfishly

thank the companies that suck so bad at

hiring that I can get the best engineers

at the world at discount prices. I

appreciate each and every one of you

guys. I pay my team fairly to be very

clear, but the fact that I can get these

legends working for me because big

companies don't even know how to

interview them is a huge edge. And if

you're interested in building something

useful and making your own startup, you

should take advantage of that, too. If

you're starting your own company, take

advantage of the fact that everybody

sucks at interviewing. Poach people from

great companies. take the opportunity to

hire better than your competition

because your competition almost

certainly sucks at hiring. I think I've

said everything I have to here. Had a

lot to say. I hope this is useful to

somebody. I know that these ones can

vary cuz I haven't been a junior in a

long time. And I know a lot of people

were looking for me to come in here and

be like, "Look at the numbers. You're so

[ __ ] Stop feeling bad." I don't want

to do any of that [ __ ] I just want you

all to understand why people don't want

to hire you specifically. That was quite

a rant. I hope this is useful. Let me

know if it is or if it isn't and what I

can do better next time.