Is Tech getting more elitist ?

I can comment on this from the perspective of someone who looked at hundreds (low thousands) of new grad resumes at Facebook, helped select which people got interviews, and had a good amount of insight into new grad hiring pipelines. TLDR: IT'S NOT ELITIST AND IT'S NOT PERSONAL, IT'S PATTERN MATCHING. 1. I went to a top Canadian school in the hardest program to get into in all of Canada and it was not on Facebook's short list they recruited at - they only recruited at University of Waterloo at the time in Canada. Once employed and doing well there, I complained they should add my program to their recruiting list and they didn't want to because Waterloo consistently produced high performers in large numbers, and my program was very tiny. 2. So they are focusing on consistent, reliable, and efficient pipelines of talent. The top CS schools consistently produce extremely high performing people (e.g. Stanford, MIT, CMU, Berkeley) in large volumes, and it's the most efficient (i.e. lowest cost way) for big companies to hire numerous new grads. 3. Bootcamps have a tiny number of high performers that get into top tier companies, but the vast majority need significantly more training and are far off from there. Big companies have TRIED NUMEROUS TIMES to recruit from bootcamps and they end up hiring one or two people a year. They need a reliable way to hire a few hundred to thousands of people a year, not one or two, so they have largely abandoned bootcamp pipelines - they cost too much in recruiter time and engineering time doing interviews that don't pan out. I'm speaking from the large company point of view. SlowestTriathelete makes a case for how a bootcamp can compete with a low tier CS school at lower tier companies.

\+1 to the warning about mid-level and senior roles with no experience. It's one of the 3 things I push Codesmith on constantly because it's dangerously mischaracterized. I do know edge case people with zero experience who get mid-level or senior roles (either direct from Codesmith or that we worked with post Codesmith) and it's not the rosy colored picture of success you might imagine... it's a stressful imposter syndrome filled ride and the gaps are extremely evident to these people when they start their jobs. I still think they can get by in these roles when they happen, but it's not fun and it should absolutely not be the Codesmith's goal to get people into these roles. I know Eric K constantly says junior roles are the worst thing you can do for your career and to target mid level and senior roles but he's flat out wrong and I'd be happy to debate him live in public about this.

I've worked with a number of Codesmith alumni and everyone is an adult capable of deciding what approach they are most comfortable with, and we can make that work, but my general advice is: 1. Leverage what's unique about your pre-SWE experience. If you were an accountant, or a doctor, or a lawyer, or something else that you put a lot of time into preparing to be, then you should present openly and try to pull out relevant things from it, rather than hiding it. For example, a doctor who did research in protein folding and was fascinated by the large scale computer systems used for simulations and some day wants to work on such systems to help save lives. 2. Target entry level roles and apprenticeships at top companies. I time box the time I spend writing replies on Reddit and this one needs it's own essay. 1. A summary for entry level: starting off with right support and expectations, crushing the lower bar - getting signed permanently or promoted and becoming a rising superstar, rather than trying to hide and avoid getting caught, having breathing room to grow and discover your unique areas of expertise instead of focusing on not getting fired. 2. A summary for top tier companies: good compensation and benefits, learn how to build things well/at scale from day zero gives you a bit of a head start. 3. Work on your OSP or another project for passion-sake, not for checking off the boxes to setup a website, medium post, post in slack, copy paste README file, etc... The projects I've looked at have very underwhelming code and any hiring manager can see this. I love the idea of building tools, but your tools will be judged against real tools, which is a high bar for the thoughtfulness that goes into this kind of thing. Building a more consumer project aligned with your passions that solves a real user problem and can get actual users using it, then iterate based on real feedback is ideal. Some people can do that with their OSP tools, but I've seen it very rarely.

I think your view is too cynical about getting into Amazon and you're trying too hard to game the system with that mentality. I know about the Codesmith Slack channels and Discords where people try to game the system. I know it works for some people and that only makes others double down on the same approach. But please hear me out. I've worked with a few people, and one in particular super closely, to get into Amazon with zero work experience. We also have a senior manager bar raiser mentor who did a panel discussion a few months ago for us around this topic. You shouldn't memorize some "stories for their Amazon principles and answer medium leetcode" to get in, you are missing the point and you might not keep your job very long if you get it. No interview system is perfect, but you'll have an easier time and more successful career trying to: 1. Become a genuinely strong generic problem solver, not a LC memorizer 2. Put in thousands of hours of programming time so you have stories to draw out of Amazon's principles, instead of fabricating stories from a few hours of work starting with the principals. Personal story. I was a classic overachiever child who always tried to game studying for tests to get the highest grades... but I was missing the point of what I was actually studying. I got amazing grades and had a lot of on paper success, I graduated high school top of my class, but I unlocked a much larger level of impact when I started opening my eyes to what I was doing. All of that work ethic and hustle I had developed by blindingly cramming for tests could now be applied to genuinely understanding how things all fit together and solving real problems. Always remember this: engineers get paid the big bucks to solve problems, they don't memorize things and regurgitate them.

Can you provide more detail about the proof? I try to be really on top of CIRR and have read the spec many times (and identified several loopholes) but would love concrete evidence of those loopholes happening in reality!

Sorry, I don't have time to write a lot and will try to come back to it, but two big ones: 1. It tells you the number of graduates included as an absolute number, and that's it. All other numbers are percentages, which can hide the underlying truth. The salaries are only for graduated and for people who report them, and exclude people who did not. So saying that X program has a $120K median salary is great except it's the median salary of the 95% of people who graduated on time and 85% of those people who got a job and 95% of those who reported salaries... the people who are excluded from the salary data are slowly shaved off the numbers. 2. There's no indication of number of people who started the program in absolute numbers. 3. Not everyone follows CIRR properly, Codesmith doesn't follow CIRR guidelines and "fellows" extend their their "clock" on CIRR by 3+ months. Which makes it even hard to figure out who graduated when and got placed when. 4. Missing background info. We want to see outcomes for people by experience level. It's death by a thousand cuts and CIRR was created by the bootcamp industry to have each of those cuts be small enough to not stand out but in sum make a difference in interpreting the data. At the end of the day, there's enough data to go off of to fill in most of these gaps yourself, but you have to do the work to understand... rather than looking at "median salary" and judging the "best bootcamps".

Is it possible that you are awesome and demonstrated both natural talent and a strong connection to the company? I obviously can't speak to this experience, but I've worked with top bootcamp grads and top CS grads from MIT and Stanford and that statement doesn't apply at all when comparing the two. A Stanford CS grad has about 300 hours across 6 core CS courses and then another 1000 hours in a dozen or two CS electives, then then have 3 FAANG internships on their resumes and leave with 5+ offers at FAANG companies. This obviously isn't the typical CS degree and many of them are not like this. But saying the best bootcamp produces grads that are more experienced than a mediocre CS degree is more accurate. I would give Codesmith less of a hard time in this regard if they didn't market themselves as equivalent to an elite grad school and instead marketed themselves as the outcomes of a generic CS degree in 1/8th the time. And I don't mean this in a cynical way at all, if you can go to a bootcamp for $20K and six months and do just as well as a mediocre school that costs $40K and 4 years, that is one heck of a business model and win win... and that's why I suggest going to Codesmith to many people.

Number 2: It took me a while to wrap my head around this one too and quite frankly, I'm still confused. The main point was that CIRR could just ask straight up the number of people who started in the half and the number of people who graduated. And It could be very clear that not everyone who started in that half was expected to graduate in that half, but it gives some idea of what the starting point is because you'll see below, there are a lot of ways people cannot be included in the graduation count. 1. Withdrawals: CIRR is very clear to anyone who withdraws needs to be marked as such, but their worksheet has not a single withdrawal example or a column to do this. So it looks like only people who actually graduate end up being included in the report. I'm not sure how withdrawals end up being reported to be honest. If someone withdraws for failing a test, they could be included in the worksheet, and if they are currently still in the program, they could be, but someone who leaves entirely doesn't have a clear field in there IMO. They make it clear in the variable length program template, which is based on start date and not graduation date, that people withdrawn are included but their template for fixed length programs, which is almost every boot camp, doesn't have a column for withdrawal and all the people in the example graduated. So even if the example isn't demonstrating the intention of the words of the spec, it's confusing. 2. Not included in the report. There are numerous reasons why someone might be excluded. like the country that they're in or that they had intended to do the program only for education or the person started a company instead or the person had a personal issue and was unable to job hunt. Specifically the health or family issues that prevented you from job hunting that is mentioned in the spec in words doesn't have some kind of code or appear in the legend inside the worksheet they provide. Again similar to 1, like a competent person can try to piece together the intention and do something reasonable, there's just a lack of clarity in the details. At the end of the day, I think all the schools that are reporting are trying to do things consistently and fairly but I'm just pointing out that the spec itself is not written clearly and has issues that if someone were very smart and strategic they could try to work around to make their numbers look better. Or put another way, someone very strategic could maybe interpret things in their favor and have a valid excuse if the consensus was that they were not following the spec. I might just be looking at things wrong, but I could see how someone using the example worksheet, and "trying to follow the spec" could end up making mistakes.

I love this discussion btw! Yeah I agree with everything you are saying about these factors being reasonable, I think that's why they are in the CIRR spec for the most part. My problem with CIRR comes down to the "legalities" of the writing itself and the spec document looking like it's written by a "head of outcomes" at a bootcamp, rather than a lawyer or auditor who can write proper documentation. This leaves a very clever bootcamp operator, room to "follow the rules" and still portray things in the "best light". For example: 1. There is no clear list of definitions of terms and concepts, like almost every legal document begins with 2. A list of all possible values for each item we are recording. They have a list of codes specified for outcomes and then refer to those in double quotes inconsistently. 3. Lots of "X states" or "if Y", but then the collection of documentation is a separate section that doesn't cover all the documentations for all possible X, Y, Z states and cases, and dates/rules for how to accept those things. Every single piece of information should have a indicated way to collect it. Anyways, timebox responses, and have infinitely more to say. For all the crap that Hack Reactor gets for leaving CIRR, their standard is written a lot more like like a legitimate legal document: https://drive.google.com/file/d/1OJqKJSd4tBcG5j7sWQjVr5gGceSVAtmQ/view