I couldn't disagree more with your post. The author is basically just putting out a detailed study plan for passing an exam. If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.
To your second point, I hear this all the time in threads about tech interviewing: "Tech interviews are biased and make no sense" and also "I'm too busy to have to do a lot of work for this interview." If you don't want to put the time in to prepare, fine, don't, and then see how you do. Again, in my mind it's very similar to studying for the medical boards - in most cases doctors have many, many thousands of hours under their belt in training before still needing to study a ton to pass their boards.
If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.
It's more like an oncologist posting that every doctor needs to revise cancer treatments for a month before applying for a role in a hospital without realising that other doctors have spent 10 years specialising in different areas of medicine, and then the hospital being amazing at treating cancer but wondering why they're absolutely terrible at mending broken arms.
In this analogy cancer is advertising, and broken arms is privacy.
this is off topic, but medical training (at least in the US) is unfortunately about as dysfunctional as you describe.
there's are years of inefficient labor from students, residents, fellows, and junior doctors on procedures they'll never do again (because they relatively cheap)
First of all, I'm not sure where this "10 years" is coming from. I know many/most "senior" developers who reached that level long before 10 years out of university.
Secondly, programming doesn't have a standard licensure process like medicine. If it did, I think a lot of these kinds of interviews that companies do would not be necessary. But as it stands I've interviewed many engineers with years of experience who couldn't competently program, and I'm talking about maybe a tad above FizzBuzz level proficiency.
But as it stands I've interviewed many engineers with years of experience who couldn't competently program, and I'm talking about maybe a tad above FizzBuzz level proficiency.
I've interviewed close to 400 developers over the past couple of decades, and I've not met many who can't code. Some are great, and some are clearly at the bottom end of the distribution, but most are just OK. They can get the job done, they can do good work given a good team to lean on, but they're not force multipliers or anything special. My experience is what you might expect given an normal distribution of skill levels.
If you've come away from lots of technical interviews thinking the candidate can't code I reckon it's more likely due to you. Perhaps you can't put a candidate at ease and find areas where they can talk about their ability in a positive way. That seems more likely than "many engineers with years of experience who couldn't competently program". I guess it's also possible that you simply work somewhere that good candidates don't bother applying to though. Either way, I don't think your experience aligns at all with mine.
I am not sure whether you have an incredibly good filtering system or have got incredibly lucky.
I have interviewed similar numbers and have been repeatedly complimented on my ability to put people at ease, but have encountered exactly what the grandparent comment says. It really opened my eyes seeing so many with many years on their CV but struggling with (literal) fizzbuzz.
This experience accords with most I have read about online (starting with the semi-famous coding horror article [0]). It is your experience that differs from the norm, honestly.
It really is about interviewing skills. I noticed a strong trend over time that the people I interviewed kept doing better. You need to engage with people without letting things get confrontational.
The best advice I can give is look at how entertainers
get random audience members to relax and engage in front of huge audiences. Many people lock up in such situations and can barely say their own name, yet with the right approach it’s a non issue.
Compare that to the rapid fire technical questions I have watched people get into and it’s obvious what’s going on. Someone fumbles something and then gets flustered and shuts down. But, pepper the exact same questions into a larger conversation, perhaps going so far as to occasionally complement them, and shockingly they do better on the exact same problems.
I have witnessed a huge range of anxiety levels from candidates and when you get used to interviewing it is pretty clear what comes down to anxiety and what comes down to simply not being able to program.
When a candidate struggles, I gently lead them and help move things along in a very collaborative way - I am also very tolerant of mistakes or poor starts and proactively give every opportunity for those to be discounted.
If somebody, after 10 hints as to the ordering of the if/else if/else of fizzbuzz, still cannot figure it out when you have held their hand for 30 minutes that's not because you lack interview skill.
Interviewing is inevitably vastly imperfect and many aspects that are not relevant to the job will play a role (for example - time constraints dictate that you must ask small questions that are sufficiently challenging that might not always be entirely representative of the job) - nobody who is honest could claim otherwise, but that is the nature of the task - it has to be an approximation - and you have to asssess actual ability to code and do the job.
Handholding doesn’t solve the problem of someone second guessing themselves, and can make this much much worse. Outside of pair programming it’s normally a solitary activity where people get plenty of time to reflect. Interjecting in the middle of this is again very different from a work environment.
No, I am saying putting someone at ease is only half of it you need to keep them at ease. The standard script I see people use is basically some warmup conversation where everything seems fine, followed by a grilling.
Conducting a full interview “without letting things get confrontational” is difficult. However, unless the job actually requires intense face to face confrontation you want to know how well they can do the job, not how well they can interview for it.
No you're assuming that this is what happened because it contradicts your assertion. Your opinion flies in the face of my extensive experience and that of the majority of people, you may want to start considering whether it is you who is mistaken.
I don't think a candidate who I put at ease then absolutely hammered would compliment me on putting them at ease would they? Or does your theory stretch to them somehow having short-term memory loss?
When in the face of empirical evidence I adjusted my world view from close to yours to where I am now. Based on your other comment you’ve having people do fuzzbizz, simply split things into two samples and see which they do better with. Interactive face to face help, or an open IDE they can run code on uninterrupted.
If the second group preformed better then presumably the testing methodology played a role with a higher percentage of people being able to actually program than your suggesting.
Granted it takes a lot of interviews to build a reasonable sample, but we aren’t talking about 1% better performance here.
>Interactive face to face help, or an open IDE they can run code on uninterrupted.
I've tried both. I've tried leaving them to it entirely, I've tried leaving them to it then if they get stuck helping both from a lesser to a greater degree.
It really makes no difference - the bad coders struggle on that and other problems, they just lack the ability to think through the problem.
And again I've seen enough anxious candidates to see the difference. I'm pretty good at gauging things well as to how and when to help.
Overall I'm not hearing many specifics more 'I am great at interviewing'.
The empirical evidence is overwhelmingly that there are many bad programmers out there with long CVs. That's also my experience WITHIN companies, though a lesser proportion.
Fair enough, I can accept it could be a difference in candidate pools or something. That said, I personally saw a bump from about 40% to 90% using different methods for what it’s worth.
In terms of a test I use mean, median, mode, and range for an array. Then go into basic performance trade offs.
I've only been on the interviewer side a few times (roughly 10), but even then I've run into 2 candidates that couldn't code.
If interviewers are screening candidates for certain attributes (regardless of how well those attributes map to being good at the job) you should expect most candidates to lack those attributes. Candidates who have them get hired after a few interviews, candidates who don't have to do many more interviews to find a job (or get discouraged).
> First of all, I'm not sure where this "10 years" is coming from. I know many/most "senior" developers who reached that level long before 10 years out of university.
That's because it's a near-meaningless title that has been watered down. Everyone is a "senior" now by their second year working.
As of 2-4 years ago, the number of programmers working in the industry was doubling every 5 years. That might not seem relevant until you realize that it means half of all programmers have less than 5 years experience. If you have 10 years in the industry, you're more senior than 75% of your co-workers.
That's why anyone with 5 years on the job is considered "senior", even though most in most professions you're just getting out of the entry level after 5 years.
The most frustrating thing about this post for me isn't the "10 years" issue, but rather this:
Most of these companies have solid internship programs, and almost all E3 (entry-level) positions are offered to returning interns.
What this means is that there's no track into a junior position where you can gain experience and work your way up to senior within a FAANG if you're older than a recent college grad. That's unfortunate, because as someone working for a mid-tier company I'd like to work hard and land a senior role at a FAANG but I often wonder if these companies would look down on candidates who have spent years at lesser companies.
It really depends on the place and nearly always applies only to experience specifically in the exact role you are in.
I have 15yrs experience and moved sideways a few times and I am in effect treated as if I were new in my current role.
So senior doesn't so much translate to experience or even transferable working knowledge but rather 'how well you have done politically to gain position in this specific company'. Yes I am cynical :)
You do need to take them every so often to stay certified. This cartel isn’t for slackers, come now.
(I jest - half my family is in the medical business. I studied economics for a while)
I’m not sure exactly what you’re describing but sounds like they could be getting practical experience? Like a junior dev doing some scripting grunt work that no one else wanted to do but they are gaining other skills along the way possibly?
Really bad analogy. Look at the post, these are basic computer science topics he is recommending for study, things like data structures and algorithms, not any specific technological subspecialty. A better analogy is that all doctors need to pass licensure exams in basic medical knowledge (e.g. anatomy, physiology, etc.)
>in most cases doctors have many, many thousands of hours under their belt in training before still needing to study a ton to pass their boards
The difference is that what the doctors put so much time into learning can actually be quite useful for their job. The vast majority of competitive coding stuff isn't. Interview procedures based around it completely fail to assess some of the most important abilities in software engineering, like API design. As anyone who's ever used any of Google's open source libraries would have noticed, hiring people who do well at competitive coding problems is no guarantee they'll be able to produce decent software.
My ex girlfriend is a pediatric cardiologist who recently passed her boards. When I talked to her about it, she was very much on the side that she wished she didn't have to study for it because it didn't have much to do with her job at all. She just wished she could spend her time getting better at the skills she actually used rather than a wide range of academic material that didn't matter to her day to day.
Her friends from residency thought similarly. That's just a few data points and maybe some doctors are helped, but it definitely isn't every doctor.
My third daughter was delivered by the anesthesiologist, because the ObGyn was stuck in traffic and the anesthesiologist was the only doctor on the floor. Doctors don't need that stuff outside their specialty... until the day they do.
Oddly enough, the US has the same pregnancy mortality rate as places like Latvia, Moldova, Romania, and the Ukraine. Tied for 56th out of 186 (there are lots of ties)
Similarly, I spoke to a pharmacist recently, and they said the same thing: the board exams expected the person to know information about medication that was no longer even in use.
> When I talked to her about it, she was very much on the side that she wished she didn't have to study for it because it didn't have much to do with her job at all.
I assume you're referring to your ex's exam to become Board Certified in her specialty, which, if you are, makes this statement incredibly hard to believe.
A specialty's Board exam is comprised of simulated cases from that specialty. Your ex wouldn't have to prep for geriatric internal medicine or stroke rehab in pm&r. Basically everything asked in the exam for board certification is related to one's specialty.
> just wished she could spend her time getting better at the skills she actually used
I can so relate to this when I look back at 4 years I spent studying for a CS degree. The first year had just 3 subjects out of 17 that had something to do with CS. The rest were wildly off the mark. Like engineering drawing, metal workshop, and what not. The second year was slightly better but just. It was crammed with electronics; and only from the 4th semester did things took a definitive turn towards CS topics. I'm sure the curriculum designers had a certain plan in mind but this was devised something like ~60 years ago, when engineering meant mostly civil engineering.
This was all 20 years ago, and I recently checked the syllabus out of curiosity, and no it's not changed one bit. One precious year of learning period down the drain.
> "What the student thought was it temporary concession to the system-"I'll play along just enough so that I can get what I want from the system"-turns out to be the beginning of it forced, permanent adjustment to the system."
I made no such claim. Here is what I stated, so you can read it again: "I checked before I posted and found two web sites that stated that ref= is an affiliate tag."
You can choose to believe what I wrote, or not. But it's inappropriate to try to put words in my mouth.
Either way, I'm not interested in arguing with random griefers in the internet.
I tend to be on your side of the fence but I have to nitpick your argument:
At these companies, algorithms and the basics are fundamentally important. Because you tend to work on tiny parts of a massive whole, there is no tolerance for cowboy-coding and not following best-practices. IMO the interviews test that you can fall in line and follow the patterns that have been in place for decades.
With regards to using API design as something that is not assessed: System design questions do test this. Also at a company like FB, there's a handful of people designing APIs that are at the top of the pyramid, and even then long-standing conventions around API design at those companies will short-circuit the need for most devs to think about how to organize and name their endpoints.
At my small startup where most of us write an API endpoint, it's important to know. For a UI dev or someone optimizing DB lookups at massive software companies, API design is not something that needs to be tested.
Personally I can admit to feeling frustrated that passing these types of interviews is not my forte. It sucks that I would have to study for weeks to not flop these interviews even though I consider myself a good software engineer. But that doesn't 100% invalidate their interview process.
That all makes sense for hiring people to work on big existing systems, but many of these large companies are also trying to innovate and build new products with smaller, more agile teams.
Sure, you’ll still need to integrate with established APIs and focus more on scalability than you would at a startup, but the kind of people who excel in each type of role will have very different personalities and skillsets. Grading them on the same curve in interviews seems like a pretty bad idea.
> but the kind of people who excel in each type of role will have very different personalities and skillsets. Grading them on the same curve in interviews seems like a pretty bad idea.
I haven't interviewed for senior level positions with FANG. But aren't interviews usually different based on the job? I assume that interviews for job families like front end/backend/sre should all test different skills. And if you are interviewing with a specific team the manager can judge your background and interviews for fit with their team. The interview bar for algorithms is probably too high at some places, but those skills are relevant for all engineers.
> That all makes sense for hiring people to work on big existing systems, but many of these large companies are also trying to innovate and build new products with smaller, more agile teams.
Which innovation of Facebook are you describing? Instagram, WhatsApp, or the stories?
Not products in the typical sense, but these are some interesting technologies coming out of Facebook that I can list off the top of my head (many of which I have used personally):
> I mean you listed several database libraries, static analyzers, and a code optimizer.
Correct.
> Is it your suggestion that those kinds of applications do not require solid knowledge of a variety of different data structures and algorithms?
No -- precisely opposite.
Your response confused me quite a lot, but after some thought, I think I've realized how things have become mixed up. I took this for sarcasm:
> Which innovation of Facebook are you describing? Instagram, WhatsApp, or the stories?
Why did I take that for sarcasm? Because it is apparent to me that Instagram, WhatsApp and stories are not innovative. So I thought the main point of the poster I was replying to was to take a dig at Facebook. I didn't realize that we were in agreement about the importance of data structures and algorithms, but then I also didn't realize that we were still on that topic: my intention was purely to refute the [what I believed to be the implied] notion that nothing innovative was happening at Facebook.
I listed the most innovative things that happened. They were product innovations that could have killed Facebook as a company, not RocksDB or React. At the same time I'm a software engineer, and I could write a database much easier than create something that grows faster than Facebook.
I use instagram and WhatsApp, no Facebook anymore (except messenger), as young people went there (and I'm following).
TikTok is a bit too much for me though, I think creating videos for it takes too much time, while for Instagram it's easy to take nice photos while I'm travelling.
> At these companies, algorithms and the basics are fundamentally important. Because you tend to work on tiny parts of a massive whole, there is no tolerance for cowboy-coding and not following best-practices. IMO the interviews test that you can fall in line and follow the patterns that have been in place for decades.
Is that true? I don’t know anything about medical licensing, but after having a few friends take the California bar exam, I’ve heard endless complaints about having to study things like divorce law in order to become a privacy advocate.
But in the case f doctors and lawyers, they pass it once, not every time they interview for a new job. Software doesn’t have licensing, so we do this bullshit every single time.
> We would still do it if there was licensing. Doctors and lawyers still interview for jobs.
People interview in most jobs, but people in licensed professions don’t generally have exams testing minimal professional competency in interviews because assurance of minimal professional competency is delegated to the appropriate professional licensing body, which implements entry exams, continuing education requirements, professional complaint/discipline processes, etc.
Minimal competency screening is abstracted out to a reusable, memoizing, component.
Medical boards are at the specialty level, so there is no equivalent. An OB is not going to have to answer primary care questions, for example. They'll all be very specialized.
Futhermore, you actually practice for several years prior to taking your boards, at which point you submit a representative subset of your cases from actual work, and a bunch of folks toward the end of their career grill you on them, then decide if you pass.
I agree with your comment. My wife took USMLE exams (all three steps) and she would complain to me that most of the stuff she memorize there, she'd forget them in a year or so (and eventually resort to Google and/or https://www.uptodate.com/home to refresh/review). :)
> The difference is that what the doctors put so much time into learning can actually be quite useful for their job.
I'd be curious to hear what a doctor would think about that. My intuition would be that, as for almost any exam, a lot of time is spent on things that will not be useful for any other purpose than the exam itself.
Even if it isn't, do doctors have to retake these exams multiple times (as developers have to do this for multiple interviews) every two years when wanting to switch jobs (doctors often don't have to switch jobs, they often have their own practice).
>They also have to go to school for 10 years before they’re even allowed in the job market.
Not to mention that during that time they are accruing loans in insane amounts (we are talking about $200-300k) and get worked in insane shifts (24-36 hour shifts are not unheard of during residency rotations).
Oh, and they don't get paid at all until they start residency rotations which is AFTER 4 years of med school, and their pay during residency is on the order of $30k-50k for what effectively amounts to 80-100 hours a week. Mind you, that's on top of the fact that in the US, you only enter a med school after you already got a college degree. So you enter a med school at the age of 23.
I have respect for the doctors, but I definitely do not envy their position. Their real work doesn't even start until their 30s, at which point they are already really deep in student loan debt. Of course it is manageable, since they get paid handsomely. But their work-life balance and the entire process where you start your "real work" after the age of 30 with $200-300k in loans, at that point, isn't something that a lot of people consider when they think "those doctors are having it nice."
It isn't even a second thought to me that I would much much rather study for interviews every single time i switch a job as a software engineer than deal with what doctors deal. And that's not even mentioning that studying for a typical software dev interview is absolutely nothing compared to the studying that med school students have to do in order to pass their board exams.
I am not saying that doctors in the US are poor, quite the opposite.
They are, however, very poor (and in tons of debt) until they actually become a full doctor (which is typically in their early 30s, after they are done with med school, residency, and board exams) and extremely overworked (which still holds true for most of them even after becoming "real" doctors).
You don't hear about "poor doctors", because during the decade in which they are poor they are counted as "students" by most people, and poor students isn't exactly something surprising or eyebrow-raising for most people. It's just the magnitude of that poorness and overworking is completely invisible to most people who don't have someone in their friend group or family who just recently became a doctor.
I've tried doing freelance before, and I was a terrible marketer for myself. While that's definitely an option for people in this industry, I'm not sure it's a great path for me.
Same with medicine. Although under-served markets are common you still have to market yourself in private practice. New specialists advertise to GPs to get referrals for example.
I completely agree that being good at designing new APIs is one of the most valuable qualities of a programmer and I have never seen a job interview or test that could check this.
It's one of the questions I ask when I interview people.
I could care less whether you remember some algorithm you could look up in Knuth. I want to know if you can put yourself in your customer's place and design an API that meets their needs.
Language design is one of the hardest skills to master, and as the qualities of a good language include maintaining backward compatibility and longevity, most people who do master it never get to apply what they learned. Instead we only get to see their practice pieces. Their almost but not quite masterpieces.
It’s why I could immediately see that XML was going to fail in the long run. Everyone is a language designer? Sure, that’s going to work out.
APIs are tiny languages, so learning to do it well is a microcosm of language design. You don’t have to be good at all parts, but if the API you need isn’t in your wheelhouse, everyone will know. And if you build enough of them you’ll discover the limits of your skill.
I always wondered why every OSS software project done by / blessed by Google or FB ends up having a terrible API and developer experience (think Angular, React, Go, Tensorflow, Kubernetes), while delivering great functionality (heck, I used all of these and endured the pain for it).
I was going for people scratching their own itch during their OSS-at-work time and wanting to show off - but this could very well be a better explanation.
The content of the boards exam is actually quite comparable to the content of these interviews. They both cover general knowledge and fundamental concepts that very few working programmers or doctors will ever use, but absolutely should know.
Virtually every FANG interview I’ve done has covered API design as part of system design.
My brother is currently in med school, a huge chunk of his time studying is spent on rote memorization. Their Leetcode equivalent is Anki (flash cards) which they spend hours on every day, for years. At least with Leetcode, it’s taught me to quickly recognize algorithms and implement my own when needed.
There are specialty board exams that you take once you're done with residency. Some are written exams. Surgical specialties do oral board exams where they present cases to you and question you on management. Pass rates for those are not as high. Many specialty boards make you take recertification exams every x number of years.
But again, these are not job interviews, they're professional licensing requirement imposed by the government, not by employers. And I don't think Facebook requires its engineers to re-interview for their own jobs every x number of years, so that's disanalogous too.
Ironically, the last thing that Facebook engineers want is for the government to regulate them. Just wait until they face the professional ethics boards. ;-) When has a programmer ever been kicked out of the industry for unethical behavior? More likely, they get promoted.
> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!" That seems like a ridiculous stretch in my opinion.
This analogy doesn't work. It's basically the final part of your education in that field (and others). If every hospital / medical center made you quit for a few months to study for their interviews when you switch jobs it would be an analogy. Oh we only hire people who can find a vein in 15 seconds under a suboptimal lighting situation.
If every hospital felt the need to interview doctors assuming they didn't know how to practice medicine, doctors would definitely take time off between to study. But they don't, because they know everyone has a base level of knowledge. On the flip side I've interviewed people who simply cannot do basic coding tasks.
> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!"
If the exam was used to determine seniority of both dermatologists and anaesthesiologists, instead of basic competency heck entering the field, it would indicate a problem.
Agreed, just because you're a senior engineer with decades of experience doesn't mean you shouldn't brush up on general fundamentals every once in a while. Leetcode, while being pretty useless in the real world, does get your brain into "answer hard questions under pressure" mode. Systems design questions prompt you to architect things which may be considerably different than you deal with during your day-to-day.
Preparing for an interview, for more senior developers, is mostly mental - even if you know the information required, can you retrieve it quickly? Do you get flustered under time pressure? Are you in hour 4 and getting tired/sloppy? A bit of studying can help make some answers automatic, and help you present your best self.
I don't think that a comparison to a doctor is warranted:
1) Every employer of a doctor doesn't force them to sit boards for every interview, or ask a cardiologist to know the same as an oncologist. (Sure, there is a good deal of overlap, but there is a good deal that isn't either.)
2) Doctors are a licensed profession and have specific requirements.
> If a doctor posted a plan for passing the medical boards would your first thought be "Wow, look at that massive medical monoculture problem!"
That is fairly close to describing a well known issue with MCATs and medical school admissions, as well as boards, see [0] - note, while I'm not familiar with Pacific Standard, I felt that article gives a good overview of the issue and acts as an omnibus to a number of links of the supporting scholarly information.
This feels like a troll post : comparing a final exam with a job interview. One is the end, total sum, of 10 years of study, the other is just... a job change. It's important, but not worth a month of my lifetime. I've only got a few hundreds of those.
A better comparison is getting into Harvard. Do you really want to go to a school where getting in is a matter of acing a prescriptive test? There's a reason college applications value experience and diversity.
I can't speak for Harvard, but in the vast majority of the world, going to college is strictly on the basis of entrance exams, with some countries also using high school grades, nothing more.
This is done to avoid bias and/or favoritism. I am not an expert in U.S. admissions but my understanding is that they give points for things like whether your parents are alumni or have donated, whether you play sports, whether you were school "president" or other tests of popularity, and a host of things that in my opinion are pretty poor indicators of whether one should be admitted.
High stakes entry-exams have their own problems. Among many other issues, they measure peak performance, rather than sustained performance.
US college admissions have many problems, so don't hear me say they don't need reform, but you are also assuming that academics are the sole thing that college is about. It isn't, at least not in the US. US schools value many things beyond pure academics. Among them being leadership (whether or not you were class president is one such indicator), personal initiative, success against the odds and many other things.
"[T]hey measure peak performance, rather than sustained performance."
I never saw it expressed so succinctly. Excellent!
It captures well the frustration around tech interviews. You might be a very competent worker (sustained performance), but fail miserably during interviews (peak performance). Ideally, you could show a body of work during your interview, but this isn't possible with most commercial software companies. If you are lucky to work on open source for your job, it is easy to show your work.
To manufacture a public body of work for myself, I built two open source projects and published them on GitHub.
(Please do not read that as advice!) I can share and discuss them during interviews.
> The author is basically just putting out a detailed study plan for passing an exam.
My issue is that someone at a senior level (yes I realize at some of these companies "senior" means "two years of experience") should have to study for 30 days to pass an interview. It should not require the equivalent of preparing for an advanced CS course final exam to evaluate the abilities of someone who has presumably been in the industry for many years.
To your second point, I hear this all the time in threads about tech interviewing: "Tech interviews are biased and make no sense" and also "I'm too busy to have to do a lot of work for this interview." If you don't want to put the time in to prepare, fine, don't, and then see how you do. Again, in my mind it's very similar to studying for the medical boards - in most cases doctors have many, many thousands of hours under their belt in training before still needing to study a ton to pass their boards.