u/Nearby_Owl_4214

theres two different ways people use ai day to day either vibe coding, where you tell the ai what to build and never look at the actual code (in the case of a personal project or just training the AI and testing out), or regular engineering where the ai generates code but you still review and understand every part of it.

The thing is when an app gets complex enough. production apps depend on a lot of interconnected services, sometimes you have to fake account states or force certain code paths just to test something, and once multiple people are touching the same codebase at once in a team setting, its becomes hard to tell whats changed without actually reading the code, so past a certain complexity threshold, working at the code level directly ends up faster than clicking through the app trying to verify ai's work indirectly.

theres also pushback on the framing that code is an obstacle standing between you and the feature you want, the argument being that code is actually the value bc its precise, it tells you exactly whats happening instead of an ai generated summary that might not fully match reality, and its more concise than an ai over explaining some part of it.

Many people may have heard Nvidia's founder "ai wont replace you but someone using ai will" line that gets repeated everywhere, the take here is that this just hasnt played out, bc the software engineers who already have core engineering skills are the same ones learning to integrate ai into their workflow, so someone who only learns ai and skips learning to code ends up competing against people who have both skills, not just one.

Actually, ai researchers hype things up heavily on social media (I've already said this in somebody's post but founders of AI hype it so much for marketing, that's it), but the actual released models feel like incremental improvement day to day, not the dramatic leap the hype implies, with an honest disclaimer about not being qualified to predict how much better it'll get.

Personally, I don't agree with the idea that more efficient engineers just means needing fewer of them. People forget that tech companies are financially rewarded for growth, not for maintaining the same output with fewer people, so the incentive structure tends to push toward "same headcount, more projects" rather than "same projects, fewer people." and on the jobs narrative, theres a point about how layoffs get covered extensively in the news but rehiring doesnt get the same coverage, noting meta and google have both been rehiring for years after their layoffs and google's headcount is reportedly close to an all time high, which paints a less one-sided picture than what usually gets discussed.

To put it simply, learn ai and learn to code and learn to code before using AI or you'll pay for your lack of skill in other (perhaps more expensive) ways👍

The classic mistake is someone gets a verbal " we're flexible on remote," signs the offer without pushing on it, then shows up a few months later and the manager's gone or the policy changed and conveniently nobody remembers agreeing to anything.

you're supposed to bring up remote after the verbal offer but before the written one gets finalized, not in the first interview, it's because the moment a company has already decided they want you so their willingness to bend is highest, bringing it up too early signals that flexibility matters more than the actual job does.

theres a script that you can follow like thanking them, saying youre excited, then asking if the letter can specifically reflect what was discussed about the working arrangement before signing, location, any trial period, and whatever came up on the call.

offer letters technically arent legally binding contracts in most us states since employment is at-will, so getting something "in writing" isnt creating ironclad legal document, its just making it harder for someone to pretend a conversation never happened later like the case I mentioned in the first paragraph.

There's also proposing a 90 day trial instead of asking for permanent remote outright, defining the success metrics upfront, most companies that agree to a trial just extend it if things go fine, think of it like a temporary internship but keep in mind that they could still reject you (though it happens less often)

It can seem like too much effort for a job that you're not sure that you're going to even get and you're free to not follow it but it does make the chance of you getting the job easier and with less scams.

on July 6, a news outlet called notus got an internal draft report from inside the us treasury department, written by career analysts, the report was specifically prepared for treasury secretary Scott bessent, fed board chair kevin warsh, and various federal financial regulators.

the analysts concluded ai firms are actually more deeply embedded into the broader us economy than dotcom companies ever were back in the day, and that if the ai market takes a real downturn it would send shockwaves through stock markets, private credit markets, the companies financing all these data center buildouts, cloud providers, chip makers, and utilities, anywhere money touches ai right now.

It wad said that "ai investors are taking risks so significant that much of the financial system now rests upon ai meeting expectations for productivity gains and profitability,"

to be fair the report did stop short of predicting an immediate crash the size of the early 2000s dotcom bust, also, $1.2 trillion in vendor debt is tied up in ai infrastructure spending specifically, which (if accurate) gives a sense of scale for why the analysts are worried about contagion beyond just ai companies themselves, that debt has to be serviced by someone regardless of whether the productivity gains show up on schedule.

treasury publicly rejected it within a day or two of it leaking, a spokesperson told reporters it doesnt reflect the departments actual views and that it was written by a "low level staffer." treasury secretary scott bessent has been publicly pro ai investment, and the spokesperson said that the official position is that ai will be a "key driver of america's new golden age," which is such a specific and almost campaign-slogan sounding way to dismiss your own analysts.

the administrations public tone has been leaning hard into unrelenting ai investment to unlock exponential growth, thats been the entire messaging strategy, while the people whose job is to model systemic risk quietly wrote something that reads like a direct rebuttal to that messaging, comparing it explicitly to a crash that did real damage to the broader economy last time something like this happened.

The governments own career risk analysts publicly disowned for it within days, which doesnt necessarily mean the analysts are wrong but it also doesnt mean theyre right just bc it leaked.

if the people literally paid to model this things internally are worried enough to write it down and get overruled for it, maybe AI washing won't be indefinite and the same companies who replaced their employees with AI tools will regret it down the line.

most people think they need a career change when what they actually need is a pivot, a change means leaving the field entirely, new industry and starting closer to the bottom while a pivot means using what you already have and moving into something adjacent where the skills just translate.

For example, some teacher who spent a decade managing curriculum, coordinating with different departments, translating complicated things for people who didn't have the background can pivot to program management, ops, enablement.

You can have a lot of sets of skills but don't have a specific name for them or roles that they could work for other than the one you're currently in, you could write down maybe things people at work come to you for, then ask what a job posting would call that if a company was hiring for it.

When it comes to interviews you could name what specifically energized you in the old role and connecting it to the new one.

there's also a difference in how this lands depending on your age, a 30 year old pivoting reads as ambitious but a 40 year old doing the same thing has to work harder to frame it as expertise instead of restlessness.

Basically, a career pivot is not about starting over, it's about getting paid for what you've already been doing which is what a lot people actually search for but go into the wrong direction of changing careers.

There's a report out from ramp and revelio labs, they track enterprise ai spend and workforce data across something like 22k companies, and the finding was that "high intensity ai adopters" (companies spending the most on ai) saw their headcount go up 10.2% overall, and entry level headcount specifically went up 12%.

meanwhile through may alone almost 90k layoffs got publicly tied to ai as the reason, and some projections are floating numbers like 15% of all US jobs gone to ai within five years, so theethis huge gap between the layoff headlines everyone's scared of and what's actually happening inside the companies that are all in on ai. the layoffs are real but it's not the whole picture though.

"company quietly kept hiring while investing in ai" doesn't make as good a headline as "company announces layoffs" so it doesn't spread the same way even if it's maybe more accurate, my guess is the companies doing the layoffs and the ones actually growing entry level headcount are just different companies entirely and we're mentally averaging them into one narrative that doesn't exist

theres also a question of what "entry level" means here, like is that new grad swe roles or does it include things like support/ops/data labeling type work too.

Either way, I posted this bc i feel like this sub only ever sees the layoff headlines or general the negative side of things and at the end of the day, networking is the best way to get a job instead of just applying through job boards and it's not that hard to find conferences depending on the field you're in or just reach out, worst case scenario they don't respond.

The things that make a nonlinear path hard to explain on a resume are usually the same things that make starting something easier than expected, the pattern that shows up consistently is that people with nonlinear paths have already done the things that trip most first-time founders up, they've started from zero more than once, they've figured out unfamiliar environments quickly, the people who struggle most with starting something are the ones whose careers were too linear.

the reason most ambitious people with nonlinear paths end up moving toward building something of their own is that the same restlessness that drove the pivots in the first place doesn't go away when the job gets better, it just has nowhere obvious to go inside a job, a nonlinear path is usually a signal that what someone actually wants isn't a better version of employment.

the move that tends to work is not quitting first and figuring it out after, it's building something on the side while the job is still covering the bills, consulting, advising, a content business, a product, an event, whatever the format is the point is starting before the conditions feel perfect because the conditions don't get perfect, they just change, and waiting for the right ones tends to mean waiting indefinitely.

AI makes the starting part more accessible than it used to be, not because it does the work but because the parts that used to require a team or significant upfront investment, writing, design, research, basic automation, can now be handled by one person with the right tools and enough time to figure them out.

The thing that actually stops most people is waiting for more clarity before starting, most of the people who figured it out didn't have more clarity before starting, they just started before they felt ready and figured it out from there.

these three get treated as variations of the same thing when they're actually solving different problems, understanding what each one is actually doing makes the choice between them clearer. Prompting is the simplest of the three, you take a pre-trained model and send it an input, the model responds based entirely on what it learned during training, just the model as it exists, it works well when the knowledge required to answer the question is already in the model and the task doesn't require anything specific to your domain.

RAG adds an external knowledge layer without changing the model itself, you embed your documents, store them in a vector database, and when a query comes in the relevant chunks get retrieved and passed to the model alongside the user input, the model then uses that context to generate a response, the pre-trained model stays untouched, the retrieval layer is what makes it domain specific, a good case to use this is when the information changes frequently or when the knowledge required is too large or too specific to bake into the model through training.

fine tuning takes a pre-trained model and trains it further on your specific data, the result is a single model that has internalized your context rather than retrieving it at query time, this works well when the task requires the model to behave differently, adopt a specific tone, follow domain specific reasoning patterns, or handle inputs in a way the base model wasn't designed for, the tradeoff is that fine tuning is expensive and the knowledge baked in becomes static, if the underlying data changes the model needs to be retrained.

the way to think about which one fits a given situation comes down to two questions, how much external knowledge does the application require and how much does the model itself need to adapt, low external knowledge and low adaptation needed means prompting is enough, high external knowledge with low adaptation needed means RAG is the right fit, low external knowledge with high adaptation needed means fine tuning makes more sense, and if both external knowledge and model adaptation are high the answer is usually a combination of RAG and fine tuning running together.

most of the mistakes in this decision come from reaching for fine tuning when RAG would have been sufficient, fine tuning is slower, more expensive, and harder to update, if the problem is just that the model doesn't have access to the right information RAG solves that without touching the model at all.

A topic that we should talk about more is the space between where someone is and where they actually want to be, most advice skips the middle entirely and from what I've seen that's exactly where most people get stuck.

A bridge job is a role you take deliberately to close a specific gap, not your forever job, not your dream role, just something that gets you closer to where you're trying to go, it might give you skills you don't have yet, exposure to an industry you want to move into, or connections that would otherwise take years to build from the outside. A bridge job puts you somewhere new, and being somewhere new means access to people and conversations that just aren't available from where you currently are, the relationships built during a bridge job tend to have a longer tail than people expect, work and opportunities that come from those connections can follow you long after you've moved on.

there's also a pressure dynamic, jumping directly from a role you've outgrown into your ideal destination puts an enormous amount of weight on that next move, every application feels like it has to be the one, which is a lot of pressure to put on a job search that's already hard, a bridge job removes that pressure, it gives you something new to react to and learn from without requiring you to have everything figured out before you start.

the alternative most people default to is staying in a role they've completely checked out of while trying to plan the perfect next move, from what I've seen that approach tends to drag on longer than expected and the white knuckling through something you don't care about anymore compounds the frustration rather than resolving it.

ana kan dwzt f dentaire l fiha normalement 176 walakin ana bant lia mafaytax 70 li jat o m3rt 🤷🏾‍♀️

The common answer is "it's a token used for authentication" and that's not wrong but it doesn't tell the interviewer anything about whether you actually understand it, from what I've seen the answers that land well are the ones that explain the structure without being prompted to.

JWT stands for JSON Web Token and it has three parts separated by dots, header, payload, and signature, most people stop at the first part and that's usually where the answer falls flat.

the header contains the algorithm used to sign the token, something like HMAC SHA-256, it tells the receiving system how the signature was generated so it knows how to verify it.

the payload holds the actual data, user ID, role, expiry time, whatever the application needs to pass around, this is the part that gets decoded on the receiving end to figure out who the request is coming from and what they're allowed to do, the payload is base64 encoded not encrypted, which means it's readable if intercepted, sensitive data shouldn't go in there without additional encryption.

the signature is where the integrity check happens, it's generated by combining the encoded header and payload with a secret key and running it through the hashing algorithm specified in the header, when the token comes back in a request the server recreates that signature using the same key and compares it to the one in the token, if they match the token hasn't been tampered with.

the reason JWT gets used is that it's stateless, the server doesn't need to store session data or hit a database to validate a request, everything needed to verify the token is in the token itself, which is why it works well when multiple services need to verify the same user. Stateless also means you can't invalidate a token before it expires without building something extra on top, a blacklist or a short expiry window, interviewers ask about this more than people expect and most candidates don't have an answer for it.

something that comes up constantly is how to pivot into something completely new, like a full change into a field where there's no degree, no experience, and no obvious entry point, from what I've seen the people who manage it successfully tend to do a few specific things differently from the people who stay stuck researching the move without making it.

the first thing is starting lower than feels comfortable, most people visualize the level they want to reach and then feel paralyzed because they can't get there directly, the entry point into a new field is almost never the role you actually want, it's a coordinator role, a freelance project, a contractor arrangement, something small enough that the lack of experience isn't disqualifying, the goal at that stage isn't the title or the money, it's getting enough hands on exposure that you stop being someone with no experience and start being someone with some, that gap between zero and some is the hardest one to cross and starting small is the only reliable way across it.

networking at the pivot stage works differently than networking for a lateral move, when you're changing fields the people most likely to help you aren't recruiters or job postings, they're people you already know who have some connection to where you want to go, like a former colleague who moved into the field, a friend of a friend who works at a company you're interested in or someone from a completely different context who ended up somewhere relevant, some people say that a warm introduction from a mutual connection gets more traction than a cold application with no experience behind it, the bar for getting a conversation is lower when someone vouches for you and that conversation is often where the actual opportunity comes from.

Also, hiring managers in any field are trying to answer one question, can this person actually do the work, when there's no professional history to point to the answer has to come from somewhere else, for marketing that might be content you've created, campaigns you've run independently, or metrics from something you built yourself, for product it might be user flow mockups for an existing app or a case study on a product decision you disagree with and how you'd approach it differently, for data roles it might be a public portfolio of projects on github or analyses you've published somewhere, the format depends on the field but the function is the same, giving someone a reason to believe you can do the job before you've been paid to do it. When it comes to proof of skill, it doesn't have to be perfect but more importantly, it has to exist and it has to be specific, a rough mockup of something real is more convincing than a well formatted summary of what you plan to learn.

Another thing that can help is getting specific about what part of the new field you're actually going after, a pivot into tech is too broad, a pivot into technical content writing for developer tools is specific enough to build toward, the narrower the target the easier it is to find the right people to talk to, build relevant proof of skill, and position the experience you do have as relevant rather than unrelated.

career changes take longer than people expect and shorter than people fear once the right pieces are in place, the gap between where someone is and where they want to be is almost always a proof of skill problem more than anything else.

Everyone is focused on AI threats right now, deepfakes, model vulnerabilities and data poisoning, but from what I've seen the more immediate problem is what a lot of that AI is actually running on underneath.

FTP, a basic file sharing protocol built in the 1980s for a small trusted network, not an internet that gets scanned by attackers constantly, the modern standard for it was written in 1985 and it was never designed with security in mind, credentials and files go out in plain text, no encryption, just open and, a significant number of internet-facing hosts are still running FTP services right now in 2026, and a large portion of those show no clear indication that encryption is actually being used.

the AI strategy conversation is important but it tends to skip past the infrastructure it depends on, you can build the most sophisticated model pipeline in the world and if the underlying system was designed for a different era entirely it just becomes another attack surface.

the legacy infrastructure problem doesn't get as much attention as the futuristic threat landscape does, which is, imo, probably the wrong order of priorities given where most actual breaches are coming from.

I'm sure everyone noticed the fact that ghost jobs have unfortunately taken over a lot of job boards whether to get your data or simply for trafic, you need to know how to spot them.

If a posting exists on linkedin or indeed but doesn't show up on the company's own careers page that's one of the signals that it's in fact a ghost job along with job boards and internal ATS systems don't sync in real time, a role that was closed internally can stay live on a job board for days or weeks after the fact with no indication anything changed.

the reposted badge on linkedin is too, a red flag, many ATS platforms automatically repost roles at set intervals to keep them visible in search algorithms, a posting marked reposted may have been cycling for months, someone may or may not be actively reviewing what comes in.

the sector breakdown can help you spot ghost jobs because it changes how to think about where to focus energy, from what I've seen government roles tend to have the highest ghost job rates, followed by education, health services, and information technology, mid sized companies also tend to have higher ghost rates than either startups or large enterprises, if most applications are going to those sectors the odds of hitting a ghost are considerably higher than the overall average suggests.

Also, some companies maintain ghost postings specifically to create competitive pressure on existing employees, it has nothing to do with hiring, it shows up as a pattern when the same role gets posted repeatedly at a company without ever visibly being filled.

Overall, check if a real person is named, check if the position is still posted on the company's website and check for the reposted badge, there's also repeated desc which I see a lot of LinkedIn and, I'm not sure if it's true or not, but I've heard that indeed creates a certain number of ghost jobs to keep traffic so try to find job on companies' website rather than job boards.

Stackoverflow works reliably for common problems and starts breaking down when the problems become more specific, both of stackoverflow and tutorials are written for problems that many people have encountered, anything beyond that and the results become sparse, the official documentation almost always covers it but it tends to be the last place people look, partly because docs have a reputation for being dense and that reputation discourages people before they've spent much time with them.

That said, some documentation is genuinely poor, but a lot of it follows a consistent structure once you're familiar with how it's organized (overview, authentication, core methods, parameters, response formats, examples), reading through that before writing any code tends to reduce confusion later rather than add to it.

Another reason that it's better to avoid third party sources have an accuracy problem due for things like the changes that happen over time, for example, you might find an answer to your problem but the answer is from 2019 and you're in 2026, the solution might no longer be applicable while official documentation reflects how something currently works.

To put it simply, stackoverflow might slow you down when trying to solve a problem compared to official documentation at least imo.

a lot of people job search by feel or randomly, or simply to whatever is out there and when the search is unsuccessful, they think that resume needs and while that the case but if you keep editing your resume again and again and nothing changes then you should look into other aspects of your job search.

a job search can break down in four places that almost nothing to do with each other, before anyone reads your resume after they read it but before they reach out, after the first call but before interviews, after interviews, each one has a different cause, a different way to fix, personally, I think the best way to approach is to track everything.

so keep four numbers somewhere, one for applications sent, the seconf for responses, third for interviews and forth for offers and keep updating them.

Let's say that you've sent forty applications and heard back twice the problem is almost certainly not your interview skills, something is going wrong before anyone's properly looked at you, it could be the roles you're targeting, ATS filtering, applying to postings that have been up so long nobody's actively reviewing them anymore.

if you're getting responses but they're not turning into interviews something about how you're presenting on paper isn't landing once someone read it; and you're getting interviews but no offers that's a completely separate issue that has nothing to do with your application materials.

Also pay attention to which stage you're losing companies at specifically, whether it's after rounds of interviews or calls, regardless of which case you fall into, there will be a pattern which is why I said to track the data from your job search, your interactions, outcomes will help you see the patern.

Of course, today's job market is absolutely terrible but some strategies might help ease the process of getting a job.

every dev googles things constantly whenever they get stuck on a task, however, there's a difference between searching in a way that builds your understanding over time and searching in a way that just gets you through the next twenty minutes and leaves you in the exact same spot the next time you hit the same problem.

most people do the second one, the most common version of this is copying a stackoverflow answer without reading the explanation underneath it, the code works, you move on, you learned nothing, and then two weeks later you hit a slightly different version of the same problem and you're back on stackoverflow because you never actually understood what was happening the first time.

the way you're writing your search queries matters too, most beginners search for the solution: "how to center a div css" or "javascript filter array of objects." which is fine until it isn't, common problems have common solutions and that approach works, anything slightly off the beaten path and you get nothing useful back, experienced devs search for the error message, the behavior, the specific thing that's going wrong, "css flexbox child not respecting width" gets you somewhere different and usually more useful than "how to fix div width." the more specific and weird your query the better your results.

stackoverflow itself has a hierarchy, the accepted answer with the green checkmark is not always the best one, it's the one the person who asked the question chose, sometimes years ago, sometimes before better solutions existed, the answer with the most upvotes is usually more reliable and the comments under any answer often contain the actual nuance, edge cases, reasons this approach breaks in certain situations, newer alternatives. reading the whole thread instead of just grabbing the first code block takes two extra minutes which a lot don't do.

docs are also something that you should be open to dive into, because most people avoid them longer than they should. Most people who are just starting out go to google first and the official docs last, experienced devs usually do it the other way around. docs are annoying to read at first because they're dense and assume a lot of context, it's annoying to read at first and then at some point it just clicks and many come to prefer it.

the last thing is knowing when to stop searching and just try something, a lot of people spend forty minutes reading about three different approaches and never actually implement any of them, at some point you have to just pick one and see what breaks. what breaks teaches you more than another twenty minutes of reading would have.

Copying is a temporary solution that only works once if you don't understand it, it feels productive because the code works, but you're just borrowing understanding you don't have yet and eventually that catches up with you, usually in an interview or on your first job when nobody's around to google for.

Most people treat the hiring process as one continuous thing, you interview, you try to impress people, you hope it goes well, but the recruiter and the hiring manager are not looking for the same thing at all and walking into both conversations the same way is one of those things that's obvious once you see it and costs you interviews before you do.

The recruiter is not evaluating whether you can do the job, that's not really their role and in a lot of cases they don't have enough context about the technical side to assess it anyway. What they're actually doing is figuring out whether you're going to be a problem. are you going to be difficult to schedule, are you going to come in with unrealistic salary expectations that blow up the process at the offer stage, are you going to be weird in a way that makes them look bad for putting you forward? the recruiter screen is basically a risk assessment and the way to pass it is to be easy, clear, and low friction, know your numbers before they ask, be flexible on logistics, don't say anything that makes them nervous about what happens when you meet actual people at the company.

the hiring manager is a different conversation, they're not doing a risk assessment, they're trying to figure out if you get it. get what the team is actually dealing with, get what success looks like in this specific role, get what they actually need from whoever they hire, the candidates who do well here are the ones who've thought about the role from the hiring manager's side rather than just preparing answers about themselves, which sounds obvious but almost nobody does it, most people walk in ready to talk about their background and the hiring manager already read the resume, they don't need you to walk them through it again.

the mistake a lot of people make is preparing the same way for both. they practice their background story, their strengths, their career trajectory, that stuff matters more in the recruiter screen than the hiring manager interview, they have a problem, that's why the role exists, and they want to know if you understand that before you start talking about yourself.

the other thing is that the recruiter is often your best source of information about what the hiring manager actually cares about, most candidates treat the recruiter screen as a hoop to jump through and miss the opportunity to ask directly, what is the hiring manager prioritizing in this hire, what's the team dealing with right now, what have previous candidates been missing? recruiters know this stuff and a lot of them will just tell you if you ask because it makes their job easier when candidates come in prepared.

anyway. nobody tells you this going in and it costs people interviews they should have gotten, the recruiter and the hiring manager are different audiences who need different things from you and preparing the same way for both is the mistake.

A bootcamp is harder to justify in 2025 than it was in 2021 and most bootcamps are still marketing like it's 2021, what changed is that the junior dev market got rough after the 2022-2023 layoffs and never fully recovered, there are a lot more people competing for a lot fewer entry level roles, and a chunk of those people are experienced engineers who got laid off and are now willing to take junior money to get back in. you're not just competing with other bootcamp grads and cs students anymore, you're competing with people who have three to five years of experience and are desperate enough to take whatever's available.

AI also changed the calculus in a way that's hard to pin down exactly but is real, companies are hiring fewer junior devs because a lot of the work junior devs used to do is getting absorbed by tools like copilot and cursor. this doesn't mean junior roles are disappearing entirely but it does mean there are fewer of them and the bar for what counts as useful at that level has gone up. That doesn't mean that you shouldn't do it btw, bootcamps still makes sense if you're genuinely committed to putting in the extra work that the curriculum doesn't cover, the people coming out of bootcamps who are getting hired right now are not just the ones who finished the program. they're the ones who went deep on fundamentals after graduation, who didn't choose whatever project that were trending at the time like the insta and YT channels tell a person to do if they want a better portfolio, who understand at least the basics of data structures and algorithms because that's what keeps coming up as the gap that gets bootcamp grads filtered out in technical interviews.

bootcamp probably doesn't make sense if you're expecting the certificate to do the work for you. the 2021 market where bootcamp grads were getting hired quickly almost regardless of depth is gone, the program gets you started but the job search in this market is longer and harder than most bootcamps will tell you upfront because their incentive is to get you enrolled and a realistic job search timeline doesn't make for a great sales pitch.

the cost is also something most people don't think through carefully enough, fifteen to twenty thousand dollars is a lot of money to spend on something with an uncertain outcome in a market that's tighter than it's been in years, the free and cheap alternatives, freecodecamp, the odin project, cs50, are genuinely good now in a way they weren't a few years ago, the main thing bootcamp gives you over self teaching is structure and deadlines and a cohort of people going through the same thing, if you're someone who needs that, it might be worth it. if you're someone who can stay consistent without it, the self taught route is a real option that costs a fraction of the price.

bootcamp can still work, it's just not the thing it was being sold as even when it was actually working, if you go in thinking the certificate gets you the job you're going to spend a lot of money and have a rough six months afterward wondering what went wrong. the people making it work right now are treating the program as only part of their path into getting into the tech industry.