> Workers who fully commit to Epic — who survive the long hours and grisly sights — are treated to a remarkable perk. After five years, they get a sabbatical, including round-trip airfare for two to travel somewhere they’ve never been for a month, plus a per diem for meals and lodging. (They get another sabbatical after 10 years, 15, and so on.)
Obligatory snark: In Europe we call this paid vacation, and we get it every year.
But on a serious note, it's so funny how experiences temper expectations. Only in a place where most people's vacation time is used for familial obligations or not used at all, does a month of traveling sound like the ultimate luxury. And they're willing to slave away for five years to get this?
When me and friends briefly served a stint as middle managers in corporate America, we had a vacation policy of "always yes". And people would still start their time off discussions by laying out arguments as to why they really needed time off. No, stop, you need zero arguments to get a yes from me as long as you have earned the time off according to company policy. It's my fucking job to make things work despite your absence, not yours.
The fact that it's a paid for trip is why it is worth mentioning, not necessarily the length. Five weeks of vacation, while not very common, is common enough that it's not really worth writing about otherwise.
Edit: Agreed that 5 weeks of contiguous vacation is rare
> Five weeks of vacation, while not very common, is common enough that it's not really worth writing about otherwise.
Where do you work that you think this is common?
My wife and I are both in reasonably well compensated professional careers, and while we get to take more vacations than most americans, a solid 5 week block is basically impossible. And I don't think that's atypical: the Bureau of Labor Stats certainly doesn't support that idea (https://www.bls.gov/opub/ted/2018/private-industry-workers-r...)
In Sweden, five weeks of paid vacation per year is the legal minimum, and you also have the right to take four weeks contiguous in the summer if you want. But you don't have the right to choose when exactly if you exercise that right. Different industries do it differently, some shut down and kick everyone out in July, others try to get their employees to spread their vacation over summer so that there's at least someone in the office.
The difference in mentality and expectations is absolutely crazy.
It is the length that makes it worth mentioning. A month long consecutive vacation in the US is rare. The paid vacation portion is not particularly generous, liberally assume $200 for lodging and $50/person for meals, it's worth somewhere around $12 to $14k including flights on the high end, i.e. $2k to $3k per year bonus.
A paid five weeks trip, flights, hotel, food for two people is maybe $20k.
Split over five years is $4k/year. I don't know how much Epic pays, if they're up to silicon valley standards, but say you make $120k/year there? An extra $4k is fucking peanuts.
Also multiply that with the five-year employee retention rate, and you get the true cost for this "perk".
If a perk costs the company peanuts, the proper valuation of the perk should probably also be peanuts. Don't get suckered in by companies that do these kinds of things. Always think about what each perk actually costs the company.
I didn't realize that companies in Europe were requires to actually pay for the vacation, on top of normal pay, by providing airfare, meals, and lodging.
Not sure if it's required, but it's common to have a 13th month of pay on top of the paid time off. I don't believe it's considered a bonus (ie it's not performance based) - it's vacation pay. It's talked about as spending money for while you're on vacation, although there's no actual restrictions on it that I'm aware of.
Usually not required by law, but mandated by the joint agreements between the employee unions and the labor unions. I.e. it might not be legally mandatory, but de facto it is.
It sounds like you know about this -- what could I google to find out more? Is it applicable to the whole EU or just certain countries? All industries or just some? I've never heard of this before (as an American who's lived in Japan for over a decade and has had multiple German/French/English expat friends who've chosen to stay here).
Honestly that doesn’t sound like that great of a deal. I’d rather have continuous work life balance than kill myself for 5 years so someone can buy me a 5 week vacation.
I interviewed at Epic Systems on-site and this article hits on basically everything I saw and felt. It's a very interesting, unique and weird place. But you also get a kind of weird vibe from it, it seems like a large facade.
A few things the article missed: The offices are shared by up to 3 people in offices designed to have 1 or 2. About half the company is akin to consultants where they fly out to a medical facility every Monday and fly back every Thursday. The vast majority of hires are new grads and turnover is very high. Oh and the article touched on this but the selling point for switching to Epic software is that Epic has nearly every person in the US's medical history in their databases (since their usage is so widespread) so if you sign up to use Epic you get the medical history with it.
If you ever interview there I recommend trying to schedule the flight in on a Thursday, your flight will have a transfer at MSP Airport and the next flight will be all Epic employees whom you can ask questions and they can answer honestly. Every employee I talked to on that flight said they planned on quitting soon and didn't like working there. This was several years ago.
Epic EHR is typically deployed as a separate instance on customer premises (not cloud SaaS). Epic customers don't automatically share patient charts with each other. However they can do so if desired through the Epic Everywhere product. And they can also share the same patient charts with other third-party EHRs through standards based APIs, although that requires configuration.
> The offices are shared by up to 3 people in offices designed to have 1 or 2.
Yes and no. The campus is rapidly expanding to accommodate new hires.
> The vast majority of hires are new grads and turnover is very high.
Turnover is only high in implementation, other positions have veterans of 15 and 20 years.
> ... it seems like a large facade.
The look of the place does not translate well to the intensity and energy that many people bring to their work. There isn't time for most people to 'have fun'. They're working.
Epic caught up on building new buildings and I don't think there is a single 3 person office on campus. The general trend is two to a window office, one to an indoor office. Higher tenure often can get solo window office now if they want it.
> Epic has nearly every person in the US's medical history in their databases (since their usage is so widespread) so if you sign up to use Epic you get the medical history with it
While Epic produces the database/electronic health record system, the hospital or health system ultimately owns the data. AFAIK patient data don’t sit on Epic’s own servers outside of some research/pilot initiatives.
(Source: my personal experience working extensively with EHRs, including Epic products.)
One of the first forms new patients sign at a hospital or private practice is a form releasing allowing their healthcare provider to request the patient's medical records from their other providers. Once that is filed, Epic provides a HIPPA compliant system to get those medical records from other linked databases.
Epic is a steaming pile of shit. I hate the medical software industry so bad. I don’t understand why the current EMRs are so bad. I’m in medical school now but I hope to make a better EMR some day.
I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.
I own a company that is attempting to modernize electronic medical records, and there are plenty of legitimate reasons why medical software is bad. The decision makers at large hospitals are even more conservative than other large enterprises. Nobody is willing to risk their career/hosptial by writing an eight or nine figure cheque to an unproven enterprise to run their critical infrastructure. So the market is dominated by companies that were earliest to market (Meditech, Epic, Cerner, Allscripts) or have big enough pockets to compete (GE's Centricity, McKesson). Nobody ever got fired for choosing IBM.
Hospitals were some of the earliest adopters of computers and the systems that were developed have been in place for decades. Most of these systems carry a lot of baggage from their development history and are too risky or brittle to modify without good reason. It's the same story that most big banks find themselves in. Everything is clunky, confusing, and old but the job gets done and that is good enough.
The people making purchasing decisions do not care about the usability of the product, as they are not going to be the ones using it. They mostly care about billing, compliance, data integrity, security, and managing costs. Electronic medical records primarily exist for billing an insurance company or the government. Every other reason given for their existence is secondary to that need. If you don't believe me, check how many staff members are dedicated to billing at your hospital. For reference, the average staff ratio is 2.7 billing professionals for each physician across the industry.
Medicine is both an art and a science. Even physicians in the same discipline vary greatly in the way that they practice their craft. There is no way to turn a hospital visit into an assembly line. Nothing is standard, everything is specialized. This is at odds with the ideal software project, where everything is defined up front and can be turned into an efficient repeatable process. If it were easier I think you would have greater competition which would lead to better products.
Can we do better? Absolutely. The limiting factor is not software development talent. You need to understand how the industry operates to be able to find a foothold. Attacking the incumbents directly will end in certain doom. If you want to learn more about how we're approaching the problem my email is in my profile. We built a product to run our own clinic and are almost ready for wide release.
Spot on. Epic isn’t designed for patients or clinicians. It’s designed for up-coding patient encounters, that is, to maximize the amount of money a hospital bills insurance or Medicare.
When a hospital switches to Epic, they do so because they know it will result in more money billed per patient. This justifies the outrageous price.
> I’m upvoting this in hopes that someone with more knowledge than me can explain why the EMRs are all terrible.
As another poster said: EMRs are billing and compliance tools, paid for by administrators that are intending to buy billing and compliance tools. They support that function very well.
The people using it clinically (a) aren't the ones paying for it, and (b) tend to be inconvenienced by the very same billing and compliance elements that make it worth paying for.
EMRs don't suck for clinicians because it's impossible to have a nice clinical interface. They suck because they're a non-clinical tool being shoe-horned into a clinical setting and forcing clinicians to do the data entry work.
I went into medical school with the same goal. Intended to do an informatics fellowship after residency. After witnessing the Epic rollout at my hospital, I want no part in EMR development. The beuracracy is disheartening.
I’ve found other places in medicine to make software and have an impact.
That said, I truly hope you succeed. We need more hackers in medicine.
i tried for 3 years to create an emr. we had some success (its being used in the real world) but not enough to be sustainable against the monoliths like epic
my 0.02 on why they arw so bad:
1. the number one goal of emr software is not quality of care. its not user experience. its suppprt and integration for billing. ie, they are accounting systems
2. this partly follows from the fact that emrs are not purchased and implemented by the same people who actually use them. a government mandate and high level health execs make the decision and their priority is the bottom line, in terms of $$$.
3. its not an encouraging field to get into. there is lot of regulation and standards to deal with and not much money to go around to pay for it
Enterprise sales into a heavily regulated industry are really, really hard. On top of that, the primary purpose of an EMR in the US is to provide accurate billing information. So the usability of the system really only matters to the degree that it affects the efficacy of billing.
Healthcare tech is notoriously bad, but over the past 5 ish years there has been a wave of healthcare tech companies who focus on making their products consumer-friendly (ZocDoc, DrChrono, Oscar, PillPack, Capsule etc). NYC in particular has a large healthcare tech industry.
So why are EMRs so bad in the US?
1) Most EMRs are on-premise software with that being the preference due to regulatory/compliance/security risk. Because the EMR companies don't have the ability to deploy changes or updates on their schedule, the rate of change is much slower and updates made for one client aren't made for all clients.
1a)Many of these EMRs are heavily customized per client (think Epic in particular). These customizations aren't often being brought back into the core product but are one-offs. Think of it like starting from scratch with each client.
1b) Unlike the Googles/Facebooks of the world which are built on web software, there's no easy way to deploy. This means that where tech first companies are probably deploying multiple times an hour, Epic/Cerner installs are probably being updated once a month or less. Some hospital systems are running on software that's 10+ years old.
2) Large initial barrier to entry. The sales cycle for most healthcare software is close to a year minimum. For EHRs, which affect how the entire hospital runs, it's almost certainly a multi-year effort. Most EHRs are signing 5 year contracts, so providers can only switch every 5 years. And for the large providers it can take 5+ years to implement a switchover from one EHR to another [1]. This means that any new entrant needs a lot of startup cash and the ability to sell to provider systems.
3) You're building regulated software, which means that most of your third-party components have to be secure and HIPAA-compliant. Also your developers probably don't have access to production data or error reporting, so fixing issues can take a long time.
4) You're building enterprise systems. Whatever you build has to support EVERY department in a provider from the ER, to the pharmacy, to billing. What makes sense for one department won't make sense to another so you end up with products built by committee.
PS You may be interested in looking into some of the modern EMRs that have come out. They seem to focus on either small practices or specialties. DrChrono is one, Flatiron Health is another.
Does ZocDoc work well for anyone? My experience with it has been that none of the appointment availability is accurate and administrators don't even know about it when you call them up to make sure the appointment has been made.
I'm a big fan of Sherpaa though, from when I had it through a previous employer.
It tends to be hit and miss. Some places have it work well and sometimes it just hasn't gone through. I'll have to take a look at Sherpaa, I hadn't heard of it before.
The database contains 18,000 tables. The same underlying data might be represented in multiple different ways in each of these tables. I say "might" because there is really no way to know - imagine how hard it is to search that vast schema space to find the data you are looking for. The problem results in proliferation of new types whenever a new person shows up.
But most of the useful data is in "patient notes" anyway. These are mostly unstructured, because constructing good medical ontologies is hard, and medical professionals hate using them because the interfaces are bad and the ontologies limit their ability to describe what they need to for patient care. This effectively means it is impossible to search. There is a half-hearted attempt to work around this with "structured notes" which allow you to enter some parseable fields into the note, you can imagine what a mess that is.
It's not written in anything you've ever heard of - it uses a custom database language called MUMPS invented in the 60s. The database is not relational - although every night, the data is ported from the actual Epic database into a relational DB ironically named Clarity. You can get access to Clarity by attending a 5-day training session at Epic headquarters.
Finally, it's a huge monolith - one company runs the systems for hospitals all over the country. You can imagine how responsive they are to requests for change.
Part of the reason why change requests are so hard at Epic is because most of the system doesn't have automated regression testing at all, so any change that isn't a totally new feature requires laborious manual testing just to convince yourself that you haven't broken anything.
To be fair MUMPS isn’t the problem; it’s actually a very interesting programming language, but it’s so far removed from modern programming languages and syntax that is is a pretty big pain to work with.
MUMPS is definitely part of the problem. Easy access to B+ tree globals don't make up for dynamic scoping, loose typing, no namespaces, no 3rd party libraries (and an embarrassingly small standard library,) a terrible console-only debugger, a godawful error handling system, etc.
and lines like this (from VistA) which is, I believe, doing some sort of string parsing.
S PSRT=$S($P($P(BPSORT,U,1),":")="N":PATNAME,$P($P(BPSORT,U,1),":")="P":PINS,$P($P(BPSORT,U,1),":")="S":$S('BPCRON:-DOS,1:DOS),1:BPDIV(BPDIV))
I remember stumbling across code for implementing SHA1. Of course, MUMPS has no builtin code for bitwise operations so there was some code built for it that looked like
switch(operation, operandA, operandB) {
case 1: //AND
{{AND A and B}}
case 2: // OR
{{OR A and B}}
...
}
which manually implemented bitwise operations using integer arithmetic
At least MUMPS gets the "noSQL" thing better than any noSQL tool invented by people who weren't even born when MUMPS came out. But coding anything sufficiently complicated in MUMPS is not the most pleasant task.
Epic has coded around most of these issues internally. So it'll be a problem for anyone trying to pick up MUMPS out of the box, but not really for Epic.
Well, the other language you can work in at Epic is Visual Basic 6, which powers the backend of the patient portal. Newer features are in C#, but anything developed before a few years ago (which are the core features) is all in VB6. Not VB.NET (unless it's changed since I worked there), actual honest to god VB6 plugged into IIS.
It's a lot like PHP, in that everything is performed by string concatenation, except that unlike PHP the language was EOLed in 2003.
MyChart is VB.NET. The main client is still VB6, which is why there has been a big push to a web based client. A few more years and VB6 can be fully retired.
Now on to your question. A lot of the EHR systems have grown organically and in the end they are made by people with software experience but not per se medical experience.
Disclaimer first: I work on a competitor for Epic (Well, they only run in 3-4 hospitals in my country and we run in 30, so they're not really a threat). And I'm not saying we are doing it better than Epic, but these are a few of my thoughts (loosely collected).
1) Most of us don't have medical training. Our campus is shared by a university / hospital, so we do have access to a lot of doctors and when they work with us, their sides of the program tend to run quite well. But, not all doctors want to spend time on this (understandable) so one system might be well tailored for doctor A, but not to Doctor B.
2) The systems are _old_. They grow organically, but Epic is a few decades old and our system started in 1992, so it's by no means 'young' either. The Medical field evolves and so does the software field - we are playing catchup on both most of the time.
3) We can't afford downtime. We can't just decide "upgrade tonight and go offline for a bit". So we have to engineer around this. We release a new system of our software every week (one week testing by a dedicated team with medical knowledge, then production). But since we can't do a bulk update and force people to restart, we need to deal with different versions which impacts the code quality.
4) We run on multiple hospitals. Hospitals have their own way of working, but to tailor to each hospital directly becomes impossible at some point. In the end you get a system that doctor Y from hospital A really likes, but doctor B from hospital A doesn't. Here, sadly, money will factor in. If you want the software more tailored you will have to pay more. And this is not just to the doctors to decide.
5) These systems are _huge_. (SVN reports a linecount of just over 37 million at the moment). Because they do a lot, to give an idea:
* Patient scheduling (find optimal time for a patient to get X therapies)
* Decision support for doctors (suggested medication, ..)
* AI System to monitor patients in the hospital
* Scheduling for the devices (MRI, CT, ..)
* Communication system between specialists (GDPR compliant nowadays, yay)
* Import/Export to share with all other hospitals
* Billing system
* Social insurance integration
* Government integration
* Medication system
* ER System
* ....
This is a pretty loose collection of some things that come to mind. :)
> We can't just decide "upgrade tonight and go offline for a bit". So we have to engineer around this... But since we can't do a bulk update and force people to restart, we need to deal with different versions which impacts the code quality.
This is pretty typical of almost any customer-facing software written these days. Every mobile app has this problem. Web apps have this problem to a lesser extent.
Because the primary contribution to a patient's health is factors beyond the healthcare provider's control, like the patient's wealth, education and genes, followed by a mix of real and placebo effects in evidence-based medicine.
Generously, if IT is number three, it's just not going to work as much per dollar as say, transferring money directly to the patient (in the form of free healthcare) or R&D funding (in institutions like the NIH).
I know of this industry, in the hardware side, that if someone "has a way" to get a device certified to selling in a country, that someone is sitting on a lot of money. It's ridiculous. The laws made to protect user's from low quality products became a corruption-bureacracy user's money exploiting shady horrible industry. Not to mention the ethics on the Patents related side of the medical tech.
It gets into some (though hardly all) of the issues of why EHR software is the way it is, and why (some) doctors hate it. (Among my friends who are doctors, some hate Epic, and some absolutely love it - depends on specialty, age, institution, how it's configured, etc.)
Among some interesting issues:
- As others in this thread have noted, the buyer (administrator concerned with maximizing billing) is not the user. That's the easy one that's common to a lot of enterprises.
- Epic makes it easier for medical directors to track population health and impose standard protocols of care. Individual practitioners don't always like that! I am not expert enough in those fields to say who's right, and I suspect there's not always an obviously correct answer.
- A lot of doctors dislike the underlying mechanic - being forced to actually write down everything they're doing and why - on top of sub-par UIs. The goals of the system conflict with the goals of the practitioner.
- Interoperability sucks, but it's true that standards aren't really there, and it's hard to get consensus... plus everything you put in prod needs to be back-compatible approximately forever. A lot of institutions got burned by maintaining internal software built over decades that you can't turn off because lives depend on it, and Epic/etc. are part of trying to avoid repeating that mistake.
There's more. I only have a toehold in that world now, but love to chat about it. Email in profile.
The interoperability standards are actually pretty much there, at least for the more common types of patient records. The situation has improved tremendously in just the past few years. Epic and their major competitors are doing a decent job of supporting the lastest HL7 CDA and FHIR standards, including specific implementation guides.
The bigger problem now is that many provider organizations haven't upgraded to current EHR release versions, or haven't opened up their systems to access by other providers.
> - Epic makes it easier for medical directors to track population health and impose standard protocols of care. Individual practitioners don't always like that! I am not expert enough in those fields to say who's right, and I suspect there's not always an obviously correct answer.
This is more complex than it looks. Picture this: "I only have 12 minutes to spend with this patient, the initiative wants me to spend 7 minutes talking about things x,y, and z but the patient has come in with an urgent pain and rash that have nothing to do with x, y, and z. I must fail on this initiative in order to do what the patient has actually come to me for."
There are a lot of things that intersect here. One is creating initiatives that really belong to public health and creating an unfunded mandate to make healthcare organizations provide that (e.g., active outreach to get people to come in and get their flu shots). No specialist in X - whether it be tech or healthcare - wants to get tangential work piled on them that has nothing to do with their actual work, and not get paid for it to boot. But if you don't do it, your reimbursement gets dinged. Essentially all healthcare policy in the US is built around sticks, not carrots: do X or we will withhold your pay.
Two, is that these initiatives often diverge from what the patient wants. A patient comes in for an acute rash and pain, and they really don't want you using up the time you need to examine them to discuss something else. "What about general check-ups?" One of the discoveries early on in the ACO program roll-out was that regulations built on the assumption that patients had annual check-ups went belly-up. Patients tend to go to their doctor a lot less often than that. Many people only go once every 18-24 months - too infrequently to pass the standards the government is imposing.
Three, the system as it stands only funds brief visits, often inadequate to properly taking care of patients.
Four, all of these things have to be documented in a very rigid way, to ensure that the EMR can ultimately be used to upload the results to the government or insurer so that they can assess how you did.
Five, the EMR strong-arms you into doing these things, jumping through a bunch of bad UI along the way. If it's inappropriate to provide, you still have to do a bunch of mandatory paperwork, because ... well, the EMR is really trying to strong-arm you.
All of these issues compound and intersect. The EMR is there to force you to do the thing that isn't yours to do and that the patient doesn't want and you have to choose between that and what they want because the funding is built around visits too brief to do both.
But, isn't it good to try and get docs to actually give everyone flu shots? Yes it is. I used to administer one of these programs, and I assure you, doctors' perception of how thoroughly they provide preventive care is wildly divergent from how thoroughly they actually do it. But instead of offering a carrot, we've created a stick, and system to apply it to the bottom of doctors' feet.
> - A lot of doctors dislike the underlying mechanic - being forced to actually write down everything they're doing and why - on top of sub-par UIs. The goals of the system conflict with the goals of the practitioner.
That's not the problem. The problem is that the reimbursement agency - be it CMS or an insurer - wants things documented in a very particular, rigid way that requires a shit-ton of boxes to be clicked and fields to be filled out, so that every little task becomes magnified by an order of magnitude.
Teaching docs to link together assessment + plan wasn't very difficult. Convincing them to fill out a form every time they don't give a hypertensive an ACE/ARB is more of a pain in the ass ("Because this guy's going to be dead in three to six months, so the monetary cost and potential side-effects aren't offset by any clinical gains whatso-fucking-ever" is annoying to repeatedly fill out. Or more realistically, "because he's telling me his urine output in response to his diuretics is going down and I'm concerned we're boxing his kidneys, so maybe I'll give him an anti-hypertensive that doesn't directly beat on his kidneys... even though his creatinine hasn't jumped yet, so I have no actual evidence to present to the government/insurer to support this, so it looks like I'm just ignoring standards willy-nilly.")
I have to mention that having seen the software used that the UI is awful. Perhaps this is mandated by the hospital customers or made difficult by HIPAA.
However, when the database for patient records of two Epic systems in the center of silicon valley do not interoperate that is just embarrassing. When the designated procedure for a patient transfering to a hospital is, "print out the entire record, fax it to the hospital, hand re-enter all data, shred both copies of patient data" that is asking for horrible transcription errors and missing data. Sorry, no donut.
Is your experience with Epic from over a decade ago? Transferring patient data, especially between two Epic systems, is much easier than that. As far as the UI goes, over the last four years Epic has had a big push to hire experts and make processes to help develop and test good user experience, as well as trying to make it look better. But that takes time in a big, old, complicated system, and you still have hospitals who haven't upgraded from 3+ year old versions. The latest version already looks immensely better in lots of areas, but you also can only do so much to make an easy to use program that also gets dense medical data in front of the right pairs of eyes so that patients don't die.
Re: record transfer, I recently found that there is a way to create an encrypted file from the patient’s chart that can be emailed , put on a flash drive, whatever. I’m planning to give it a try soon, but in the meantime, my clinic still uses the prehistoric method you describe.
the problem with EMR is that it fosters copy-paste. you read the same misinformation over and over. If copy-paste is disabled, content will degenerate to fiction.
in our data driven medical system, human narrative has lost value, just as the physical examination is the equivalent of judging a book by its cover. Today we rely on invasive and computationally intensive tests to tell us what's going on. Ultimately i see AI as offering a 'tree of choices' at each step in the diagnostic and therapeutic decision tree where we doctors only need to click on the most right (least wrong?) choice as we pare the tree to the situation at hand.
Drug recommender systems are the crude first step i see being implemented. but these are choices made in isolation without integrating the numerous other data points available for a particular patient.
currently, the health care industry is the largest employer in many towns. the social disruption by further 'unemploying' these people will convert gainfully employed individuals into the depressed patients of the institutions they used to serve. so some wisdom is needed here to temper the zeal of our blind pursuit of the electronic medical record.
When my mom was taken to the emergency room last year, it was common for the doctors to be followed by somebody who would enter things into the computer for them.
It seemed like a reasonable way to handle entering medical information without having to wait for it to be transcribed. It seems like doctors making rounds would not have that.
I'll just leave this here to try to help explain the complexities on medical technology. These systems are all the complexity of medicine (and medicine is hard) with the difficulties of a large enterprise system.
> Epic is constantly scanning the undergraduate ranks for new hires. Rather than sticking to engineer incubator schools like M.I.T. or Stanford, it scouts institutions like Carleton College in Minnesota and Clemson University in South Carolina. Candidates take online tests to gauge their problem-solving skills and, if they pass muster, are whisked to Madison for an on-campus interview and tour of the area.
Obligatory snark: In Europe we call this paid vacation, and we get it every year.
But on a serious note, it's so funny how experiences temper expectations. Only in a place where most people's vacation time is used for familial obligations or not used at all, does a month of traveling sound like the ultimate luxury. And they're willing to slave away for five years to get this?
When me and friends briefly served a stint as middle managers in corporate America, we had a vacation policy of "always yes". And people would still start their time off discussions by laying out arguments as to why they really needed time off. No, stop, you need zero arguments to get a yes from me as long as you have earned the time off according to company policy. It's my fucking job to make things work despite your absence, not yours.