I think hiring has become more difficult now that programming has been discovered as a well paying mainstream career. When I started in the 90s most people I worked with had a passion for the craft but now I find we interview a lot of people who have a CS degree just for the career prospects but not out of interest for the craft.
I find it much easier to deal with someone who has no relevant experience but cares vs someone who had 10 years experience but doesn't care. Now someone who has 10 years AND cares is rare but pure gold.
By all means, you should use whatever criteria you would like to hire your own staff.
But in general, I would encourage folks in computer tech industries to be hesitant to assume such a binary approach to evaluating prospects. "Did you code for fun in high school?" might be a useful question now, because software development as a field is so young that high school students can try out significant work easily.
But in most high-end professional fields, that's not true. Imagine asking a prospective medical resident "did you treat any diseases in high school?" or "how much surgery do you do in your spare time?"
I think we should take it as a positive sign that people are approaching software and computer technology as a professional career that they can professionally pursue. That approach can produce great work too, and a growing field means a greater diversity in how people find and display their passion. Getting a CS degree is not easy, and requires some base level of interest and commitment to complete. Even a bootcamp is not free, and takes some focus and work.
Anyone above a certain age (like me) came into the industry sideways, as it was developing, as a result of personal passion and interest. Let's not mistake that for an inherent property of a good tech employee... every industry on Earth started that way at some point.
Computer technology industries are maturing, just like railroads, oil development, aviation, telecommunications, and dozens of other industries have over time. That's not bad, and we will have to take it into account as we consider the model employee.
Hiring people who are "not proven" might also mean hiring people who are well trained, but maybe have not yet proven their passion in a way you recognize.
I agree with you, but I'd like to add to the "did you treat any diseases in high school". I knew someone in high school who wanted to be a doctor. She didn't cure any diseases or perform surgery, but she did read all that she could and was fascinated by medical-themed tv & movies. She had been inspired by her pediatrician when she was young. She did't treat people before becoming a doctor, but from early on she had the inspiration, passion, and drive. She became a doctor. She did it for the love of the profession, not solely because it was a "good paying job" (though, I'm sure that helped). I think coding in high school is the expression of having passion -- it's the passion that you should really be looking for, however that is expressed for profession X.
Ironically, med schools are taking the opposite tack. Because reading books and watching TV shows about medicine are so wildly divorced from the real thing, and because so many kids are really launched towards medicine by their parents, "I always wanted to be a doctor" is considered a (mild) red flag: it's an indicator that someone is pursuing the field based on childish fantasies rather than a rational, adult decision. The former tends to create more failures and burnouts, which med schools try to avoid if for no other reason than because drop-outs are lost tuition.
As a doc: you can't become a doc for love of the profession, because it's a profession you can't test drive. You can become a doc for love of the fantasy of the profession. It's awesome that programming is different in that way: you can't produce an OS in HS, probably, but you can certainly take a run at making simple stuff in python or simple iphone games.
You can absolutely become a doctor for the love of taking care of people that are sick and help them overcome a bad situation. Many of my friends displayed a caring side very early on (middle school).
> become a doctor for the love of taking care of people that are sick and help them overcome a bad situation
That’s the fantasy. And, hey, when it pops up, awesome - it’s a very energizing moment. However, most medicine has absolutely nothing to do with that day to day. The day to day is subject to Pareto’s Law. A surgeon may occasionally get to “take care of the sick,” but 80% of the time they get to do a five minute chart review of an obvious gallbladder passed along from the ED, a cookie cutter GB removal, and an uneventful recovery that involves a daily stomach poke and the same handful of questions they ask every other post-op pt on the floor. Medicine is a technical profession.
Im confused. All those small day to day technical things you described are opportunities to help and care about sick people. On the otherside of the chart is someone in pain. Its maybe not House, but it will make a huge difference in their life. If I was hiring a doctor, I'd want the person that understood that.
It's a Nobel laureate's lab. They work on biochemistry. They work on producing drugs that might one day cure cancer. Everyone that works there gets to say, "all the small, day to day, technical things I do ... are opportunities to help advance the fight against cancer!" And it's plausible! They're rockstars!
The primary investigator, he still has to chair like six goddamned committees because that's the institutional politics of his job. But it lets him do his job, so it gives him a chance to cure cancer! Surely that somehow makes all those committees less tiresome and boring. Every time someone spends half an hour arguing the merits of switching what brand of coffee pod they want in the faculty lounge (read: closet), he can think to himself, I'm doing this to cure cancer! Certainly that makes all the boredom just zip and go away.
His senior PhD student? When he's up at three AM writing a last-second response to a peer review of his latest publication of a boring and predictable iteration of their last study (but needed, to juice his pub count and help him land a job FIGHTING CANCER!)... when that response makes it abundantly clear the reviewer didn't bother reading his damn paper and just wants the student to revise it to cite the reviewer's last paper (to juice their pub count)... well, that student can rub the grit out of his eyes, pour himself another cup of discount-brand pod-coffee, and say, this is awesome! I'm helping to fight cancer!
When the janitor comes in in the morning, and gets pissed because the water has turned blacker than the faculty's discount coffee but the nearest closet with a hose is on the other side of the goddamn building, well... hey, that's okay. Because he's keeping this lab clean, which helps the lab workers do their jobs, which means he's helping FIGHT CANCER!
None of that is un-true. All of that helps people get out of bed in the morning. But just because your job, big picture, has a noble end doesn't mean the every-day misery of every-day work is somehow magically awesome.
If I was hiring a doctor, I'd want the person to understand that. Because if they didn't, they'd be a goddamn train wreck once they found out that hours of paperwork hoop-jumping isn't any more exciting just because it's medically related.
I don't mean to go ad-hominem here, but honestly: are you a college student or something? If you've held down a job, you should fully understand that the "mission" of the job is separate from the day-to-day tedium of ... work. Work is work.
One likely won't get that good at surgery unless they practiced a lot. And if they had no interest towards that profession they likely won't be putting in crazy hours in their prime early career time becoming a surgeon.
You can't even become good at flipping burgers without being interested in doing it.
My parents are surgeons and considering all the stories they’d tell me growing up about the conditions they treat and the surgeries they perform I’ve got to say it always sounded like what you describe as the fantasy. They still enjoy it in their 60s.
Boredom has never been an enemy they’ve faced. And I’ve thought about it and over the last decade of programming I get it. Boredom hasn’t been an enemy I’ve met. And I look around at my friends and nor is it an enemy they know.
I think the cynicism just misses the joy most people get from performing their craft right.
Of course they don't discuss the boring routine. When I get home, I talk about the highlight of the day/week, too - no one talks about the ubiquitous routine. But it's a job, not an episode of ER - most of it is the ubiquitous routine of jobs everywhere.
No, I'm talking about 99% of docs 99% of the time. It's a job. It's a great job sometimes, but it's paperwork most of the time. For every hour we spend rounding in the morning - when we're given at best 2/3 of the time we need to actually do the bare minimum, and half the time we need to really talk to people - we spend another 1-2 hours (minimum) in a windowless room doing a pile of paperwork notating the hell out of the morning's visits. I won't mention the X additional hours doing bullshit like wrangling with insurance companies and home healthcare and calling the nurse to very-politely-because-we're-all-a-team-here find out why my STAT EKG on last night's chest pain didn't get a fucking EKG. No one is passionate about paperwork in windowless rooms and workplace political wrangling. No one. But that's what it is most of the time, because it's a job. A real world job, with TPS reports (heh) and never enough printer paper to go around.
Would being a doctor be better in a system where there was /only/ a choice of either single payer or bring your own all-cash payment? (No 'insurance' at all.)
I don't know, to be honest. I know a lot of docs blame insurance for this, but I've worked in health policy and insurance - the problems are bigger than that.
A lot of the documentation is an attempt to create "quality standards". I like that in theory, and it's independent of what kind of payment mechanism is used, but ... docs will have a riot if we're held accountable for final outcomes ("This guy has had 30 docs in 20 years, smokes like a chimney despite my repeatedly trying to get him to stop, and I'm getting my wallet drained because he had a heart attack?").
Alternatively, process measures ("Did you put everyone with high cholesterol on a statin?") kill autonomy, require documentation, destroy nuance (there's a good reason I don't want this patient on a statin) and also calcify medicine (advances in medical knowledge occur faster than Medicare updates its performance metrics).
Unfortunately, "quality care" is also a PR move to cut costs. Create enough metrics over enough things docs have no control over, and a documentation slip-up becomes a good reason to ding us our reimbursement. This documentation is also a way to cut government and insurance budgets: they want the information for their programs, but don't want to pay for anyone to convert unstructured medical notes into structured data. Therefore, it becomes an unfunded mandate plopped onto physician's heads. That's not going to go away, unless all insurance - public and private - go away.
All-cash payment removes documentation because there's no one to be accountable to. There's no central party trying to track your outcomes. But... I like the idea of tracking performance. I like the idea of encouraging quality care. I wouldn't mind if we could divorce quality metrics from centralized payors, and put the cost burden of data entry onto the party using and benefiting from that data rather than physicians.
Some of the paperwork headache won't go away regardless. Primary Care docs spend most of their time doing bullshit paperwork tasks. As often comes up on HN, an employer won't let you bring your own chair to work - unless you get a doctor's note. Family med guys write stupid notes every single day, and it occupies a significant percentage of their workday. It's disheartening, and it's not going anywhere.
Another big thing that's happened is social work. Every issue that society doesn't want to deal with rolls down to healthcare: the homeless, the mentally ill, the uninsured, eventually land in an emergency room. That means we're the central clearing house for social services. Psychiatry - especially ER psychiatry - spend probably as much of their time (or more) networking with social work and the state trying to secure Medicaid and housing for patients than they do addressing their mental health needs. It's work that needs doing, but man is it heartbreaking to train to be a physician just to spend your day trying to arrange housing.
Lastly, even a single payer system has incentives to deny services. That's still a cost borne by the system. Accordingly, docs will still find themselves fighting paperwork battles with the insurer to justify a course of treatment - they'll just be doing it against a single bureaucracy instead of several.
That's a little outside of the specific question I was asking, so I feel like an addition is warranted; I'll try to return to the main topic where possible as well.
My outside knowledge is that a medical facility focuses on: diagnosis, confirmation of diagnosis, selection of treatment along with annotations about EXCEPTIONS to standard treatment, finally actual treatment. I'd like for doctors to focus more on the keen observation and decision parts and would not mind automated transcription of doctor / patient interactions to be reviewed and possibly have a summary forward (but not replacement of actual data) added by other staff. That might be an opportunity to hire/train other types of staff and gain experience in a more concrete way; much like the source article wants to make it easier for potential experts to grow in to a job.
If there's a typical outcome given an input it's important to document the decisions that affected the selection of non-generic courses of action - exceptions are things that should be known in the future. That's something that any worker should do.
The NTSB, as seen in a different recent hacker-news linked article, has excellent postmortems, even for incidents which only came close to being disastrous. A cascade of failures and lack of good decision processes seem to be the typical cause and review with recommendations on how to prevent them from occurring in the future is good. An honest mistake or poor circumstances for otherwise good people are worthy of overlooking and avoiding in the future. Lack of training can be identified and refresher courses or other supplementary training can improve the situation for everyone. Much like making sure someone is addressing problems in their job and growing to accommodate the required work.
Though there might be a bad fit for a job; either someone not able to do the expected work of an individual in that position, a job that's poorly defined and/or not broken up in to manageable units of work, or a worker that is a bad actor to some degree. All of those defects are situations that review and recommendations for remediation should address and resolve.
In your specific case, I believe having a single payer system would improve the outcome related to the above considerations. Affected individuals would still be covered by 'the system', good doctors would not be burdened by specific negative outcomes that happened to occur under their care, and bad workers of any type would be removed.
The actual outcome of individual patients shouldn't factor in to compensation. However addressing that in detail is clearly off the main topic.
I think it is both ethical and practical to recognize and classify cases that are bad fits for a given worker and to attempt to route them to someone that is a proper fit; while providing the best intermediate care and transition possible.
Also of note is that for a 'single payer' system the costs SHOULD be divorced from the actual treatment; though might be a considered criteria when a given standard of treatment is selected.
2.
> I'd like for doctors to focus more on the keen observation and decision parts and would not mind automated transcription of doctor / patient interactions to be reviewed and possibly have a summary forward (but not replacement of actual data) added by other staff.
The patient history we track isn't a literal transcript: it's a transcript of what we find pertinent from our clinical interview and observations. The word "pertinent" there is key; it's intimately and inseparably attached to our decision-making process and diagnostics. Think of it as a persuasive essay. The facts and the deliberation are what a medical historty is, not just a list of data. Med students spend half of med school learning the very basics of this.
> That might be an opportunity to hire/train other types of staff and gain experience in a more concrete way; much like the source article wants to make it easier for potential experts to grow in to a job.
In learning hospitals, we already have residents and med students doing this. And then an attending will come and do it again, because we're better, and this is a learned skill built around our clinical acumen, not a literal transcription.
> If there's a typical outcome given an input it's important to document the decisions that affected the selection of non-generic courses of action
The combinatorics of medicine are too huge for "typical input." That said, we justify all of our decisions, so that someone reviewing our actions can decide whether our behavior - the outcome - was justifiable given the input. The "reviewer" tends to be someone in our own specialty, though - replacing this with something standardized and codified would require, literally, encoding the entirety of medical reasoning. It's a bit beyond modern EMRs.
We have what are called "morbidity and mortality conferences." If something goes to shit, the doc responsible gets to take the stage in front of his and all related departments next week, and explain the entire course of the medical episode and the decisions taken at each step, while being monday-morning quarterbacked by every doctor they're even vaguely familiar with. The episode is also forward to Quality Improvement, which is a hospital-led group looking to address systemic and process errors. And, lastly, malpractice suits are the final inspection.
When docs fuck up, there isn't a shortage of post-mortem. None of that does anything to shield physicians from malpractice liability.
(An exception: if you operate in a FQHC - federally qualified health center - for the underprivileged, and you maintain a QI program that meets government standards and audits, the government assumes your facility's liability risk. But physicians are still fire-able at the end of the day as part of the QI process, so the incentive for Cover Your Ass medicine remains.)
"Bad Doctors" are a rarity, in my experience. What is more an issue is "doctors good enough to practice good medicine under modern time constraints, and those that aren't." Not everyone can manage a complex patient in 3 minutes. In fact, most can't. But with everyone squeezing down hard on reimbursement, that's become a necessity. No one wants to pay for the time that good care requires. So, docs default to shotgun medicine - throw all the tests at the patient so you can't be accused of overlooking something, and hope that something comes back unambiguously positive. Next patient.
> In your specific case, I believe having a single payer system would improve the outcome related to the above considerations. Affected individuals would still be covered by 'the system', good doctors would not be burdened by specific negative outcomes that happened to occur under their care, and bad workers of any type would be removed.
I think I should clarify what a single payor is. It's often abused in popular literature to mean something like "government monopoly on healthcare." It's more literal than that, though: it's a single payor. So that can mean things like:
a) A government monopoly on healthcare, where all healthcare facilities and providers are owened by the government, paid by the government, etc. HC is distributed as a utility, and people assume it is covered by their taxes (UK) or they pay a nominal fee (Canada, if I'm not mistaken).
b) Government monopoly on health insurance, but healthcare facilities and providers remain private competitive entities. Healthcare provision remains fragmented as a competitive market, but at least these facilities can expect uniform negotiations and documentation across all their patients, since they're all coming in with the same insurer. Patients expect their care to be covered by their taxes, premiums, or some combination of the two. This is closest to "Medicare for All."
c) Regional monopolies on health insurance. As per "b", except that inter-state entities continue to see some heterogeneity in payors. This regional monopoly might be governmental (e.g., Medicaid For All) or private (such as areas where only one private insurer is available.)
None of these things change the liability landscape directly, although in "a" malpractice liability is usually assumed by the government as hc providers are employees. This doesn't eliminate CYA concerns, but does shift them from "do everything the patient wants, whether or not it's best for them" to "follow local policy and guidelines, whether or not it's best (for the patient)."
> Also of note is that for a 'single payer' system the costs SHOULD be divorced from the actual treatment; though might be a considered criteria when a given standard of treatment is selected.
Why is that? Regardless of who the single payor is, they have budgetary constraints. The appetite for healthcare is infinite compared to resource inputs. Someone is going to be squeezed to make those resource allocations. Currently it's the physicians, but if not physicians, someone else.
When I say 'single payer' (or payor as an en_UK spelling might prescribe) I mean a system with the following features:
* Everyone is covered by one pool
* The pool is funded externally
* absolutely no incentive to defer detection
* absolutely no incentive to defer treatment
* absolutely no incentive to defer care
* because everyone will be covered by the same system in the future.
* Competition can still occur as far as offering services /to/ the pool.
Compensation for services will probably be some form of rate per area determined by an auction/bid system in advance.
Sorry if I went afield. I think my answer got a bit rambly. I appreciate you clarifying what you're aiming for, and I'll try to edit this response to the same level of clarity. Hopefully.
I'm going to have to give my response in a couple of posts, since HN says it was too long.
> My outside knowledge is that a medical facility focuses on: diagnosis, confirmation of diagnosis, selection of treatment along with annotations about EXCEPTIONS to standard treatment, finally actual treatment
The first thing to clarify is: there are a number of different types of medical facilities, ranging from private primary care to massive, regional specialty care hospitals, and the modifications to the above really depend on what type we're discussing. I'll pitch my answer to small-to-mid-sized secondary care (bread and butter specialty care like cardiology; general surgery, some onco surgery; little or no sub-specialty care) because that's the most commonly encountered facility. That's with the caveat that, again, the answer to that is different from other facilities (e.g., your family care practice) that are just as important to discuss.
Your list of things facilities focus on is correct except for your idea of annotations of exceptions. Our documentation focuses on the entirety of the patient encounter, all of the physical and laboratory exam findings we consider pertinent, our treatment choices, and often some degree of our treatment rationale. Outside observers often think "well, don't you just give a standard CHF treatment to someone with CHF, unless there's an exception?" A large purpose of our standard documentation is to provide an outside observer the chance to recreate how we came to our conclusions regarding diagnosis and the best course of treatment. In short, we document to cover our asses from malpractice.
Second, we document so that the hospital can bill insurers. Insurers create increasingly specific requirements for what must have been done or detected before a service can be provided - and those things must be in our note (or else the insurer assumes it didn't happen), and must be linked in our writing (Patient had finding X therefore we did Y). Increasingly, if one doesn't link it, they argue that they couldn't infer that Y was because of X. (That comes up more with performance metrics - oh, you told the patient to lose weight? We didn't realize that was meant to be an intervention for being overweight. We can't just assume what you mean to be treating.)
Lastly, we document for government and insurer mandated performance metrics. For instance, I need to do a depression screening for all over-65s annually. So, a helpful person working on our EMR built-in a reminder tab - did you do a depression screening today? I have to go through a drop-down to select "No", and then another for reason why ("Already Performed", "Patient Not Eligible", "Patient Already Diagnosed with Depression") about 30 times a day. That's our simplest metric, and one of dozens (because there's not a consistent set of metrics across all insurers.) You're about to suggest a way that this can be automated to suck less. I can suggest that, too, but as you may have noticed, this program is paid for by the hospital, to benefit the hospital's performance with insurers and the government. Physicians aren't the customers. Dev time is committed to making it suck less for us only enough to keep us from storming the hospital with pitchforks and catapults hurling ICD10 printouts.
And, lastly, something I truly didn't understand when I worked in health insurance but I do now: there's absolutely no such thing as a standard patient, plus or minus exceptions. The reason for that is because there's no such thing as "a patient with CHF". There's "a patient with history X, which leads me to believe they have CHF subtype 2C, with complications X, Y, Z, and complicating factors 1 and 2." Good doctors keep all diagnoses provisional, because the evolution over time will absolutely change your understanding of the patient - whether to CHF subtype 1Zebra or because what you thought was Complication Y and Z was actually parallel disease Ampersand. This is why we constantly communicate the story of the patient's history to one another, and why every doc takes their own history. Accepting a diagnosis from someone at hand-off is called a "chart rumor," and making a habit of it is a fantastic way of mis-treating patients. I cannot possibly tell you how many times I've improved patient care by just starting over from zero rather than accepting a chart rumor.
Sorry if I was unclear; I meant that those would be highlights of the record. What you're describing sounds like an underlying debug log (which includes a full record of the doctor/patient encounter would be kept as I think I also mentioned).
You can't be passionate about boring work 24/7 and most jobs are boring work. Even if they aren't when you start, once you've done something 1000 times it becomes rote. Why do you think there's stories of burnout from places like google where people join up to do great work, but get stuck doing CRUD apps to support the business?
The only people I see claiming everyone needs to be passionate all the time are business owners and management who then channel that passion into unpaid overtime
> you can't become a doc for love of the profession, because it's a profession you can't test drive
oh, I don't know about that. It's like a 6 week community college course to become an EMT. There's a test drive for you. There are 2 year programs that will get you a nursing license.
You can get a taste of the medical career path without going the full MD route. Maybe not as accessible as coding, but it is accessible.
As my kids are just now graduating HS, this is something I try to drill into them. College can be like an assembly line that spits you out saddled with the equivalent of a 30 year mortgage, trained for a job space that you literally have no idea if you'll even want to do ... or it can be like a Baskin Robins of careers, and you can try every last one of them until you find what you really like.
passion and knowledge of self are everything. the rest is a commodity.
> It's like a 6 week community college course to become an EMT. There's a test drive for you. There are 2 year programs that will get you a nursing license.
EMT and nurse aren’t “mini doctors,” any more than doing video game QA is “mini programming.” It gets you near the profession, it doesn’t put you into the shoes.
I don’t know how to articulate this. The job that requires about eight years of post-grad training, including four of them as heavily supervised on-the-job training with slowly increasing responsibilities for 80-100 hrs/week, is wildly different than the job that you can start doing in six weeks. Working in the same setting as a physician is no more “test driving” what it’s like to be a doc than being a secretary at a hedge fund is test driving what it’s like to be a hedge fund manager.
The thing is, the salient bits of being a doctor have to do with the thought process going on in their head, the stresses of responsibility and decision-making, and all the considerations they weigh with each patient. It's just not an "observable" thing. Docs don't really start sharing their internal processes with you until you're in the second half of med school, and even then not commonly. From the outside, it just looks like... guy in a white coat, often at a computer, making pronouncements. And then doing paperwork, which largely consists of documentation to prove to the government and insurers you did everything they decided should have been done for that patient and if not, why not. The combination of accountability and lack of autonomy is a leading cause of physician burnout and, again, is all internal.
The other part it leaves out is the hours. "What do I do with this patient?" is a very different thought process at hours one, eleven, and eighteen respectively, of what should have been a twelve hour shift. One hospital I know of has its trauma/SICU surgeons do 5 days on and 5 days off where they pull 12 hour shifts daily, and they're on call every night. But trauma/SICU doesn't really sleep, so these folks are making critical care decisions at hour one-hundred-and-twenty, of which maybe eight hours involved sleep.
All of these things occur in the internal landscape. Shadowing is ... not effective.
Most med students have done clinical research, shadowed doctors, volunteered in hospitals, etc. Back in the day, I did hospital volunteerism, clinical research, hospital QI, and I worked in health insurance. I'd seen medicine from pretty much every vantage point before I second-careered into being a physician. And every senior med student and resident and physician will tell you, "holy shit, I had absolutely no idea what it would be like." Even the occasional nurse that decides to go to med school, who most commonly think they're halfway to being docs already, will say "omg, I had no idea how much I didn't know, and how much you guys have to do." We had two in my med school class back in the day. When we were in didactics, they were shocked by how much docs had to know. When we got to clerkships (the second half of med school, where you work in hospitals) they were floored by how much was involved in being a physician that simply wasn't visible to nurses. And that's... you know, nurses. Folks who work in our vicinity on a daily basis.
Thank you for the eye opening insight, my significant other was accepted to med school in the states and she/we are double minded on her pursuing the field of medicine due to the dismal work life balance you mentioned, considering she has a science masters and works a 9-5 in medical research. She didn't have the undergraduate grades and did masters + high MCAT score to finally get in at 30 years old.
Given the current state of medicine in the states, you touched upon the topic of insurance companies. The endless paperwork seems to be a side effect of physicians being beholden to insurance companies to supply a steady stream of patients that afford an income that will offset the
steep debt and decades of opportunity cost spent in school. This seems unique to America from what I can tell and is only getting worse, along with what I'm told regarding physicians (MD/DO) competing with nurse practioners and physician assistant, government oversight, etc over area of practice.
I sincerely hope you and all overworked physicians take care of mental health and avoid burnout. I think private practice and limited hours for certain lower specialties might be the answer for my significant other if we plan on starting a family anytime soon.
> Finally, the topic of burnout and physician abuse (lack of sleep, working overtime and being on call), is truly disgusting.
The simple truth is this: pay has been dropping like a rock, every public mention of doctors is about how much we suck, regulators and bureaucrats are telling us how to practice medicine (but we continue to carry the liability), we're given 5 minutes to see patients when we should be given 20 (and when we rush out the door, patients think it's because we don't give a shit), and and and. .
The worst of it is: everyone else has a "career" - they're allowed to worry about work/life balance, about trying to get paid for their time, about trying to build a nest egg. When physicians do that, well, medicine is a /calling/. You're not allowed to worry about paying for your kids' schooling, or paying off your debts, or etc. That stuff is for programmers and accountants; you're just working with "sick people in their worst moments," so you're not allowed to be anything but self-destructively selfless. No one is allowed to discuss physician misery (I hate the word "burnout" - those docs aren't a resource that came to the end of its useful lifespan, they're human beings in desperate misery) except when residents are throwing themselves off the roofs of hospitals. I've lost -two- friends in the last year. TWO in the last YEAR.
And the only people that pay attention to that are the residents who have to carry on and the attendings that go, "well, it was still better in my day, when residents didn't expect to sleep or ever go home. It was better for patient care continuity if their doc never went home."
Private practice is dead or dying for most specialties as well. The healthcare field is heavily concentrating into large regional networks.
I knew this all going in. So I can say to your wife what I said to myself: The only reason to become a doc is if you cannot, for the life of you, force yourself to become anything else. It has to be a fire in your goddamn marrow.
And for all that, I recommend choosing a residency in psych. They work 9-5 even in residency - call tends to be 9a-8p or 9a-11p (rather than 24-hour shifts like the rest of us) and every other weekend they tend to work 9-9 Sat and Sun. It's the lightest residency on the planet, and they still make - per hour - the same money as IM and FM. It's the best thing I've ever heard of for people that want to have work/life balance and a family. Unsurprising, as they're the ones who spend every day seeing stressors break people's minds in half.
It remains that there are young people who understand this and still long to study arduously to be doctors, and then put in the work. It seems there is something appealing about the work that can be done, even if it’s imperfect. Is there any kind of enthusiasm you could accept as beneficial?
I don't think I said that enthusiasm was harmful, or non-beneficial.
So I want to clarify: what I said was that people who aim at medical school because "they're passionate about medicine" are mistaken. They're passionate about a fantasy of what medicine is, because you don't really know what it's like until it's there (and popular depictions of it are as unrelated to actual medicine as 1980s hackers movies are unrelated to actual programming.)
Many people are deeply hurt by the gap between fantasy and reality. They don't complain about it openly, but inside the doctor's lounge... oh yeah.
Some find a new passion, for what medicine actually is. Sometimes this is closely related to their original ideas, more often, it's only tangential. But they're on fire, and that's great.
Most just grow up, and find that they do a difficult but worthwhile job. They don't necessarily have a "passion" for it, but they appreciate the importance of what they do, and concentrate on doing it well. They work to take care of their patients, but also to avoid liability, and to earn their colleague's esteem. They're normal physicians.
I'm discussing the fact that what people think medicine is vs. what medicine is has a huuuuge gap. You can't be passionate for a thing when you've only seen its mirage. That doesn't mean enthusiasm is inherently bad. It's misplaced.
>it remains that there are young people that understand this
No, there pretty much aren't. That's rather the key point. I've never met a student, resident, or practicing doc that said, in retrospect, yeah, they had anything resembling an accurate clue about what medicine would actually be like.
“Many people are deeply hurt by the gap between fantasy and reality.” This is another expression of the harm or non-benefit I was referring to you having said.
I agree public perception of a field lags behind reality, but it’s only a lag. Medicine has been a tough job for awhile. There are students who understand this well enough to handle the adjustment (since they don’t have first-hand experience yet.) It’s not a failure of “passion” if it’s crystalized into tangible goals, and better developed motivations and principles, as the student matures. It’s also not fair to equate surprise at some of the reality of a job with regret.
Finally, I know people who pursued medicine from childhood and are doing well in it. Granted, most of them had doctors for parents, but they were still quite excited.
On the other hand, it's hard enough to expect 18 year olds to know what they want to do with the rest of their lives, if we only hire people who showed passion in high school now we're pushing that all the way back to 14 years old.
I didn't even know my career existed until after my freshman year of college, but no one I work with would say I'm not passionate about what I do.
I don't think the issue is when people show passion for anything but if. I started playing guitar late in life, but it's a consuming passion of mine. I fell in love with programming early, and out of love with it during college. That's why I moved in a lateral field (product management) where the skills I learned are useful but it's not required of me to do something 10 hours per day that I really don't love. I love my current profession, I spend a lot of time privately to study and get better every day, I work on building my toolset of templates and a strong reference library. I think that's the important part, showing dedication to improvement.
Why penalize folks who didn't know what they wanted to do in high school. It took me a long time to get a vague idea of what I wanted to do for a career and it's something I have to constantly contend with. In fact, I'm still trying to pinpoint what exactly I'm looking for. I know things have changed in the last few years, to the point where high school kids are in pre-engineering or pre-cs programs and getting special instruction.
As an aside, the advantages of knowing what you want early are huge assuming that you continue down that path for a long while. If we consider something like graduate school, knowing as a freshmen that you want a PhD means growing your network early, cozying up to professors to write recs, doing REUs. You could have someone figure out towards the end of undergrad that they want to continue on and really struggle to put together a compelling package even though they might be just as passionate or have just as much potential.
I think that the metaphor is wrong - comparing writing software with other fields such as medicine makes little sense: there's a lot of basic knowledge necessary to perform even the simplest steps as a doctor (or an engineer or a lawyer), meaning a higher barrier to entry.
Software development is more easily compared to things such as cooking, playing some instrument or even writing.
There's some knowledge and training involved but that can be learned very quickly and a lot of stuff can be done on intuition.
There's been a number of geniuses composers who wrote songs at very young ages; there's potential for that in software as well.
It doesn't means that more experience doesn't matter - whatever someone developed at an early age is bound to be worse than after more years of practice, but you can start programming very early.
However, humans are complex and you can have boy geniuses and late comers that are equivalent.
Sure, I didn't mean to imply that there aren't people who are passionate from a young age about being doctors--there certainly are!
But, I think it's not taken as a necessary attribute within the medical field. There are a lot of great doctors who didn't decide to pursue medicine until college, or maybe even later, and as a whole the field seems fine with that.
> There are a lot of great doctors who didn't decide to pursue medicine until college, or maybe even later, and as a whole the field seems fine with that.
Med schools are increasingly selecting for that, in fact. Second careerists tend to do better (because they're adults), and have less burnout (because they're more likely to have made a knowledgeable adult decision about what they're getting into, rather than being disappointed reality didn't live up to fantasy.)
> But in most high-end professional fields, that's not true.
Yeah, for some reason, when you're interviewing as a forensic pathologist, mentioning that you're cutting up partially decomposed bodies in your spare time does NOT count as a positive.
I still think there is value in looking for passion in people, but maybe passion for craftsmanship in a field other than software should count equally well.
Except software is one of the only high-paying careers where you can get by purely on merit with no formal education. I'll take our, sometimes ridiculous, interview processes over requiring X, Y, and Z degree, certificate, etc...
FWIW, we've found that passion for music is a huge positive signal that somebody will be successful as a developer within our product line (small portion of a large company - don't know if that signal holds true outside my group).
Obviously, we don't limit candidates to those who are also musicians. Heck, we don't even tend to ask about it in interviews. But, it serves as a general "we probably did ok with this hire" shortly after on-boarding.
Personally I am not a big fan of the word "passionate" as the number 1 attribute for employees. I think there are better words like competence, commitment, empathy, independence, maturity, etc.
There was a time some while ago (as I blow mental dust off my college literature studies) when "passion" was not a word that carried wholly positive connotations. It came with implications of things like irrationality, moodiness, strong emotions, even violence.
Passion can be an asset if a person must maintain momentum in the face of hardships and competition. It can be the base for tremendously hard work (which is one reason I think employers like it). But, it could potentially be a liability too, if it drives a person to create conflict or inhibits teamwork. Depends on the role and the team.
Empathy is not part of computer science, but is incredibly important in software engineering. In software engineering, much of the day-to-day work includes things like:
* Discussing and ultimately making decisions
* Learning about how things work from people with a different set of knowledge than you
* Doing things which optimize for the understanding of other people after you, as opposed to optimizing for your own productivity in this second
Software engineers who do these things with low empathy end up contributing to the stereotypes about engineers who are unpleasant to work with because they don't consider other people.
If you mean CS in the academic sense, e.g. algorithm research, probably not much.
If you mean CS as in "occupation that involves designing and/implementing software" then I'd argue empathy is an integral part of being an effective professional. Empathy facillitates effective communication and ethical/moral decisions.
I think the idea that "all that matters is your code" is flawed. It's very short-sighted and narrow minded, and it does nothing but to artificially limit oneself. The world is bigger. You interact with other people and can have either a positive or negative effect on them.
Companies are made out of people. A person writing algorithms in the corner does not create value; in order to create value, they have to work with other people to make decisions, deliver work, help each other, etc.
Some of those other people might not know as much about CS, but might have other skills like design, marketing, management, etc. Empathy is a trait that helps one to appreciate and adapt to these differences constructively.
"Passionate" in programming is shorthand for "cares for quality" AND "will improve on their own". Companies are unwilling or unable to train on the job (because it requires tech mentor resources they dont have /wont spare) so they are looking for people they can drop in and see payout for without further investment (particularly in time).
I think it is a shortsighted strategy, but not one without basis. The supply problem is real.
When hiring managers talk about “passion” what they usually mean is that they want to hire a geek who is willing to work crazy hours because of a love of programming and won’t dare negotiate for higher pay or leave for a job that will pay them more.
Saying that you shouldn't hire people because they're only in it for a paycheck and not passion is just shorthand for I want you to make this your life, but not pay you to make it your life.
Subsequently, what I've seen is that most problems in the field of k-12 education in the states can be tied to this sentiment.
I've heard this distinction before, and I think it's a difference in the base quality of the place. My last three jobs all put "passion" as a major hiring criteria, but all maintained a strong work/life balance (average work week was 40 hours give or take a few, and though crunch times happened more than a few weeks a year was considered a bad thing. I conducted plenty of interviews myself and helped write interview questions so I'm pretty confident in what _we_ meant at least, even if I wasn't a hiring manager.
One of those places, however, did slide after a few years into the nastiness described (I left when the slide started, and it reportedly continued). Another
So while "Passion" CAN mean "we want huge levels of uncompensated work without complaint", that has not been the norm for mean and I think it's a mistake to assume that is what is always meant. Certainly I've been at some great places to work that I'd have avoided if I thought asking for passion was a negative.
You would be surprised about how many founders who post on HN bemoan the fact that they can’t find developers who have passion for the founder’s “vision” and only care about the money.
My usual retort is why should I care about a founder’s vision if I don’t have a substantial amount of equity in the company? They find that highly insulting.
I have zero disagreement here. I have a similar reaction when someplace tries to attract me to the "challenge". Finding hard, interesting work is EASY - I'm looking for interesting work (often but not always hard) that also pays well. ...and it'd be nice to be able to tell people who I work for and what I do without feeling defensive.
Nothing wrong with believing in the product or the company, but there is something wrong with thinking that would be enough. I don't think the entitled executive syndrome you're discussing is really the norm for companies, but yeah, I've encountered it and it's annoying.
Sorry - that was a mostly removed sentence, because it wasn't very interesting: "Another is a new job, so we will have to see how well they sustain it".
You're not entirely wrong, but that's a very bitter interpretation.
A more charitable interpretation of "passion" would be... I'm nominally a Python & Scala programmer (according to my CV), but I can also competently talk about OCaml, Haskell, Rust, instruction scheduling, tracing JIT compiler implementation, propagating type inference, TCP stack, C memory model, register allocation, hardware concurrency primitives and ring 0 privileges.
Compare that to another Python programmer that once tried to convince me that when a C++ program tries to access unallocated memory "the computer just throws an exception".
Honest question, I’m not trying to denigrate anyone who takes an interest in software development for its own sake.
But would you consider someone passionate if they said that they only care about learning a language/technology/framework that is marketable and doesn’t believe in learning for its own sake?
Unless the Python developer is actually writing C++, I don’t think he would ever need to learn the intricacies of C to be a good developer.
But take that opinion with a large grain of salt. I spent 12 years bit twiddling in C/C++, 10 in C#, and have been doing Python for a grand total of 6 months so I definitely haven’t done anything complicated with Python.
Nah obviously not. I just listed what I know. I mean looking at the list you could maybe tell that I'm mostly interested in programming language implementation (I forgot to list all my Linux and Windows sysops skills that I've gained from years of managing said systems).
The end result is, that (1) my knowledge and skills extend way beyond any of my past or present job descriptions, and (2) (this is probably even more important for employers/productivity) that I'm capable of, and curious enough to actually want to, learning quickly/deeply and solving hard problems that might not have an obvious instant-knowledge-based solution.
I think that anyone that has ever had an interest to go "beyond" (in any way) the obvious, or immediately what's necessary in his/her day job, would built such a knowledge base - but could of course be completely unrelated to mine (e.g. networking specialist, cryptography geek, hardware/embedded engineer, ...).
It's a little dangerous to expect companies to train junior employees well when their focus is on making product/revenue. Generally they would prefer solving immediate problems over developing the craft, so over time most training would align with short-term solutions rapidly executed. Perhaps we need to be thinking about building trade schools as a service which can be hired by companies to institute part-time professional development for engineers, especially in junior roles, so that craftsmen be the ones pushing the field forward rather than the business analysts who make use of them.
I'm all for trade schools, but I feel like that's a slightly orthogonal issue.
There's no immediate reason to expect a company to help train up employees (not just juniors, but moving people from every level to the next step)....unless those companies want to improve the outcomes of their staff, want to improve morale, and want to resolve their perpetual difficulty in finding people senior enough for their needs.
Don't do it out of social responsibility, do it for keeping your business functioning long-term. I've worked too many places that have almost exclusively senior devs with more work than they can handle. They focus on hiring MORE senior devs (but don't have much success), meanwhile their senior devs are spending a lot of time doing work that junior devs could accomplish.
There are numerous side-effects too - mentoring (if you like it) can help improve your own skills and outlook. Fresh perspectives are always good, and once someone gets their first few years in, they will occasionally have insights that seniors can learn from. At the best places I've worked the more senior devs have wider perspectives and deeper experience, but the "who is right" between junior and senior becomes more of a statistical model than a certainty.
There are certainly benefits for the company but between predominantly revenue-centric attitudes and a lot of poorly trained "senior" engineers I wouldn't trust the majority of companies (outside of Google, Apple, Netflix, and other great engineering orgs) to do it well. Independent schools dedicated to progressing the craft and tools would benefit more, I think.
CS/programming is almost unique in this regard in that there's a significant school of thought out there that, if you haven't been programming as a hobby since you were a kid, that's a disqualification. As you say, there is pretty much zero expectation in any other STEM field that you did much more than take some science classes in high school and liked them.
(In STEM. Obviously you presumably don't apply to Juilliard because you decided you might want to give this music thing a try.)
It may not be terribly unique, at least not in my perspective. Because passionate people tend to enjoy doing what they love, even in off hours. Sane people value their off time, so I'm not saying passionate people must work non-stop.
Take a lot of craft trades. Ie, wood working, painting, music, writing, whatever. Those can often be people who just love doing the area, they love creating with their medium. I feel passionate tech people are similar.
The example of a medical professional was.. unfair. Yes, free time usage as a measuring stick for passion in some fields (like medical) is a terrible measuring stick, but I'm not legally inhibited from wood working in my free time.
Note that I'm not at all speaking about whether you should be binary about hiring (passionate people vs non-passionate). I'm simply talking about how in some crafts, crafting outside of work-time is a decent indicator to passion. Another indicator is, I feel, knowledge outside of their professional experience. I'm not a frontend programmer, but I enjoy learning and following tech trends, so I've used and can speak somewhat comfortably with frontend frameworks, my preferences in them, and etc.
Actually the medical example is a pretty good corollary with software. Getting into medical school is extremely competitive, probably harder than getting a job at a top tech company. And while grades are a major part of selection, most schools also want people who spend their free time doing biochemistry research, volunteering in hospitals, running clinical trials. Then once you become a doctor, the amount of time you spend working becomes a big part of how your colleagues judge you—if you just work the minimum to keep your license, other doctors probably won't respect your skill much. The difference is that I guess doctors don't usually practice medicine "for fun" on the side.
It’s messed up in the other direction too, though. There’s no other STEM field where you attend a six week “boot camp” and expect to get a job. Or where people with two years of experience are “senior”.
I suspect some of it is the terminology. If your job is mostly routine tasks in a lot of fields, you're usually called a technician (well, or a "genius" if you work at an Apple store). In Silicon Valley-style tech, computer scientist/programmer/developer have all been sort of munged together.
There are other areas where "engineer" is thrown around pretty liberally as well in the US. But title inflation in software is probably more pronounced than just about anywhere else.
Your opinion is not the established nomenclature. Senior is widely understood to be 4 yr degree + 5 yrs experience. This means you have all the technical training plus enough professional experience to be considered fluent.
At ten years you should be absolutely expert in the areas you've worked in. This is staff or senior staff level, if you also have some business acumen, ie the ability to see beyond engineering requirements.
I don't really care what the established nomenclature is. I was stating what I consider senior and 5 years of industry experience doesn't cut it for me.
What's your experience cutoff for someone without a CS (or equivalent) undergrad degree? Or someone who has an unrelated undergraduate degree and spent 2 years getting a CS MS?
Slightly irrelevant comment, but I studied Jazz at a good conservatoire, and after years as a pro musician, I ended up spending years as a pro software engineer. There is weirdly some cross-over, and that vocational drive is actually pretty handy for start-ups and things. I do think that technology is often vocational. It can be just a job, but from where I sit working in different startups, I think I thrive most off people for whom it is a vocation.
Doing software development in high school requires a computer (even a ~$400 that is shared with the family is sufficient), interest, and time (so one can spend hours required reading tutorials/watching videos). Basically, nothing too much out of the reach of your average teenager -- with the exception of interest/dedication to the art.
Doctors, and most other professions, cannot be practiced without a lot more investment. If we lived in a society where access to resources required for practicing those careers would be easily available to teenagers, we would see young high school students do that too. I don't think you're making a fair analogy here, there is basically no way a high schooler could even _attempt_ treating diseases but it's very possible for a high schooler to program 6-8h a day and learn.
> Doctors, and most other professions, cannot be practiced without a lot more investment. If we lived in a society where access to resources required for practicing those careers would be easily available to teenagers, we would see young high school students do that too.
This is not true at all. I was fascinated by bugs, cells, and other bio stuff as a kid and a decent microscope is not that expensive. The fundamentals of being a doctor - biology, chemistry, observation - are well within reach of teenagers. A lot of medical knowledge is also freely available. Obviously no one expects a teenager to successfully perform surgery, but teenagers also aren't expected architect operating systems used by thousands of people.
> I don't think you're making a fair analogy here, there is basically no way a high schooler could even _attempt_ treating diseases but it's very possible for a high schooler to program 6-8h a day and learn.
Again, not true. Treating a little sibling's cuts and bruises is well within reach of most people. It's really a question of being around people who get hurt more than average - having an energetic, younger family member provides a lot of opportunities for treating small injuries. As does volunteering as a coach/mentor for little league sports.
The more interesting distinction is that doctors generally don't build anything. They diagnose and fix. So, while a teenager into programming can show off a webpage or a game they've been working on, a precocious youngster who knows how to treat wounds, set breaks, inject insulin, and identify a stroke doesn't have a cool portfolio of projects to show off.
That is a great point -- maybe my argument should be appended to include the fact that CS makes it ridiculously easy to create and present a portfolio of work (GitHub pages!) which seems to be impossible in other fields. Regardless, it does seem that these few special traits that CS has allows it to be one of the few where it actually makes sense for a high schooler to build up experience & a body of work.
I've seen teenagers submit great projects to HN and get feedback from the knowledgeable crowd here, that really seems to be impossible in any other field (unless you have connections).
> and time (so one can spend hours required reading tutorials/watching videos)
This is maybe not out of reach for an average teenager, but it is definitely out of reach for quite a substantial portion of the population, the poorest percentile might just not have the time to dabble in programming. They might have to take care of siblings, work for a living or to pay for college later.
Right, looking for signals of "passion" has to be done carefully so it doesn't become just a proxy for socioeconomic class. This is also true when thinking about "cultural fit" within a company.
This is an interesting case where the laws around interviewing may make this harder.
What you want to measure in the interview is passion. What you can see is their accomplishment. But accomplishment is roughly passion × means. A rich person can accomplish more for the same effort because they have more power at their disposal.
But you can't easily cancel out means in the interview because you sure as hell can't ask any direct questions about their socioeconomic level, for good reason.
I agree, and I was trying to phrase my comment in a way that makes it clear (but failed!). You are right, doing CS in high school requires some amount of privilege.
> Doing software development in high school requires a computer (even a ~$400 that is shared with the family is sufficient), interest, and time (so one can spend hours required reading tutorials/watching videos). Basically, nothing too much out of the reach of your average teenager -- with the exception of interest/dedication to the art.
I grew up in the country, got the internet in grade 9 on a 28.8 connection over a single land line (so my time was very limited), had a computer that couldn't load the QBasic help files (it didn't have enough RAM), and our town library was painfully out of date. I never got past basic "if/else" as there were no resources available to me, so I quickly gave up. It's become much easier to get access to all these things, but my answer to "Did you code in high school" has to be a "no". It's funny to me that we assume that developers are young enough to have had youtube in high school.
Yeah, I'm a millenial even and I know people my age who didn't have a computer with internet (at home) until they went to college. People really underestimate how insulated some rural communities are, especially impoverished ones. Most of my family still lives in appalachia, and when I visit there are a surprising number of places where you barely get phone signals from any major networks. DSL and cable internet is still unavailable at my grandparents home last I asked.
From a different angle, a good friend of mine who is now an excellent engineer was denied a computer with internet access for totally different reasons during her high school years. Her fundamentalist parents thought the internet was immoral. She couldn't even have a game console, because her parents said those were for boys.
But yeah, asking people that question basically assumes that the answerer had a degree of privilege that isn't nearly as "average" as the asker would like to believe.
> Basically, nothing too much out of the reach of your average teenager -- with the exception of interest/dedication to the art.
My father grew up, went to school, and finished university in the 70s and 80s, in the Soviet Union, where none of those things were within the reach of an average person. He's only started programming towards the end of his physics PHD. Since moving to Canada, he's done ~20 years of programming.
Biasing hiring towards people who programmed in high school is incredibly ageist.
Sure, a computer is within the reach of most teenagers now. No, a computer was not within the reach of most teenagers 30 years ago - or even 20 years ago.
Of course, this question is only valid for applicants in their twenties. I don't think anyone in their right minds would expect someone in their 30s+ to be programming since they were teenagers!
If your interview involves you asking different questions to people based on their age, you are treading dangerous ground, for dubious gain.
Why not go with something safe - like asking people to implement fizzbuzz and merge-sort on a whiteboard, or something else that has nothing to do with their age, gender, or ethnic background?
But the 80's were an excellent time for kids to learn programming. I'm almost 40 and was immersed in programming the TI-99/4a, C64, Apple II, and Trash 80 for a significant part of my childhood.
You're arguing about a specific example but there are many examples from STEM fields. For example, becoming a mechanical engineer doesn't carry the same expectation (from some) that you have spent your childhood tinkering with automobiles and other mechanical devices. There is some truth that it's more straightforward for kids to work with software than in the case of, say, chemical engineering. But it shouldn't be a disqualification if they developed an interest in the profession later in life.
Again, I don't think any child or teen is going to be allowed near any sort of heavy machinery like automobiles?
On the other hand, many students I know who are studying MechE right now did work on lego-kit robotic & Arduino projects while at school. I'm not sure if it'll play a role in their job application, but in my opinion there are genuinely very few fields (only CS comes to my mind) that a teenager can do at their home at a level equalling a professional.
Most people I know that became mechanical engineers were tearing apart dirtbikes and snowmobiles and ATVs long before they had drivers licenses.
And if you have family that is in those sorts of heavy equipment fields, chances are good that as soon as you are big enough to hold a flashlight or run and pickup wrenches, you are going to get drafted into helping out.
There are a lot of young people walking up the medical pathway, but their notion of the correct early path just doesn't involve "practicing medicine", but rather taking the right classes or getting pre-requisites like math out of the way.
Nobody is telling their kids to become a doctor by reading aimlessly about medicine.
> But in most high-end professional fields, that's not true.
Many of the top people in other fields also have a strong passion for the field, which came early.
Ex. top lawyers usually love the law and many had experience with related areas (ex. debate) from high school. I know plenty of high school students who are very excited about medicine and do things like volunteering at a local hospital or helping a professor with research.
Early passion shouldn't be a requirement, but it's certainly a good indicator. I've never found someone who is only in tech for the money to be particularly good at it.
I agree, antidotally of course. I know plenty of people who are very intelligent (by most measurable ways) so they could do any profession they like. CS is a good profession right now so they picked it. Definitely no passion, but given their high functioning brains or what not, they are good at whatever they do.
Don't get me wrong, I believe most who pick this profession due to its perks, tend to be worse then their computer inclined counterparts; but there are lots of examples of this just not being true.
Illustration, music and dance have been studied for thousands of years, but you can still tell who’s passionate about them from an early age: they do unskilled {drawing, singing, dancing} for fun. Even though there is basically no chance of their work having an impact on anyone at their skill level, they still do it. Mostly because their parents and teachers tell them nothing about how their work measures up by objective standards, instead encouraging them and appreciating anything that demonstrates growth in their skills compared to previous pieces.
I don’t see why programming is any different. There’s not much difference between a crude drawing of a house in crayon, and a crude Pong clone in Scratch.
Because CS education is in its infancy and the material changes so fast, we can’t expect college to be comprehensive. Rather than structured learning, we rely on people who are peripherally exposed to various topics to have the “spark” to become curious about them and go deeper.
To a first order approximation, someone who has been into computers their whole life has that “spark” as second nature. Someone who sees programming as “just a job” is probably not going to explore any more than necessary to fulfill the requirements of the task at hand. Sometimes less. This makes the curious more effective at approaching harder problems, and puts them in a position to spot potential improvements even on mundane problems.
I see this firsthand at work. My careerist colleagues are lovely people and capable of doing the work assigned to them, but it’s the lifelong computer nerds who solve the really knobby problems and push us forward.
Yet a lifelong computer nerd with that structured learning foundation will leave a non-passionate CS degree holder and a degreeless lifelong computer nerd in the dust.
People want to scream about CS degrees being trash and yet all the passion in the world doesn't seem to convey an understanding of memory leaks, garbage collection, and VM/bytecode/etc. hijinks (like JVM, MRI, etc.) to the degreeless people in my team.
A CS degree program worth its salt will dip you into enough low level OS programming that you can bring with you to any language. It also should expose you to multiple programming languages so you can quickly separate universal ideas (pointers, references, pass-by-value, pass-by-reference, various models of multithreading) from syntax.
Meanwhile, degreeless bootcamp people just think Ruby Symbols are nifty immutable strings and have no idea why symbolizing dynamic string keys in hashes results in a memory leak.
I'm not against bootcamps, but polyglot is still my primary requirement for hiring for this exact reason. Bootcamps need to at least integrate a week of Computer Org and a week of doing what they just did in another language into the curriculum to really be a valid way to bypass CS degree programs.
> People want to scream about CS degrees being trash and yet all the passion in the world doesn't seem to convey an understanding of memory leaks, garbage collection, and VM/bytecode/etc. hijinks (like JVM, MRI, etc.) to the degreeless people in my team.
Meanwhile the degreeless people on my team wrote their own operating system that's older than your degree and still used in production today. We're not all the same.
I was going to comment on that exact exerpt. To explain and expand further, all university gives you is a breadth of general purpose knowledge. It merely provides a guarantee of a minimum of passion, time invested, and skill. If a degreeless individual can fulfill these minimum breadth and time investments on their own, they've attained the peak of what most college folks will ever. What's more: their motivation and discipline, their curiosity and self-sufficiency will continue accelerating them well beyond the typical college kid in whatever it is they do.
And if their resume points that out they get an interview. As I said in another comment, if you show up with a junior position, no degree, and shit to show for it on Github or somewhere else...I don't have time to interview you in a pool of 500 applicants.
As a degreeless completely self-taught programmer with a strong interest in vm implementations and garbage collection (eg I found the MLKit paper to be super exciting and at the time an incredible innovation (and then rust came along shortly after that)), I feel obligated to inform you that since ruby 2.2 (which is required by Rails 5+), symbols are in fact garbage collected, and are thus now effectively the same as string interning with #freeze.
And how many companies are only know posting blogs about their upgrades to Rails 5+ and how difficult that was?
It's still relevant knowledge.
Sure, degreeless self-taught programmers who know their way around this knowledge exist. I never said they didn't. But when you've got 500 applicants and your resume says you were flipping burgers two years before you got your junior position...I don't have time to interview you.
Medicine may be more mature as an industry where education takes a little longer but it is not much different from software. Many of the best doctors (that I've had and know of) started out helping their parents with labwork as kids or interning at university labs in high school, helping with real research into biology or medicine. Likewise, there is a significant gulf between the doctors who chose the career because they are passionate about helping people and those who do it for the money or because of cultural pressure.
There's so much work to do in both fields and we need all kinds of people, but there is certainly a difference in work environment when the team is dominated by one type or the other.
> Imagine asking a prospective medical resident "did you treat any diseases in high school?" or "how much surgery do you do in your spare time?"
I think software engineering is more like writing than medicine. Most writers, wrote in high school. Many writers write in their spare time. They have blogs, zines and long posts on facebook.
I agree that not everyone has a opportunity to code in high school, nor should jobs exclude people who leaned later in life, however I think as the field matures more people will have more opportunities to code earlier in life.
While I agree with your point, the medical resident example is a poor one. Prospective medical _students_ are expected to basically devote their extra curricular free time to demonstrating their passion for medicine via volunteering, etc.
>>But in most high-end professional fields, that's not true. Imagine asking a prospective medical resident "did you treat any diseases in high school?" or "how much surgery do you do in your spare time?"
Not a fair comparison because the practice of medicine is not accessible anywhere to the same extent as the practice of programming. You need a license to practice medicine. You don't need one for programming. Similarly, surgeons need facilities and equipment to perform surgeries. The only thing programmers need is a computer.
I think the OP has a point. I know several brilliant mechanical engineers for instance, and every single one of them used to tinker with cars and gadgets and whatever else they could get their hands on when growing up. Indeed, such a background is a strong signal for curiosity, which is an important factor in success and professional growth.
To be fair, GP didn't say they wouldn't hire someone who didn't code for fun in high school, or whatever. Just that hiring was more difficult if you're trying to hire people who actually care about their craft.
Most high end professional fields have some sort of certification process, the difficulty of which roughly corresponds to the level of damage a bad professional can do.
Doctors, lawyers, accountants, architects, and engineers can easily destroy or end lives in the course of their work and the certification process tends to weed out people who are in it for the money but not actually capable.
I really don’t think your average CS grad can be said to be filtered in the same way.
Do you believe that computer engineers/scientists/developers could have just as much impact on someone's life?
I personally feel like the field is too broad to say yes to that above question but in some domains of our field, it is definitely a yes. We might need a more regimented continuing education requirement similar to the legal field's CLE requirements to remain part of the state bar. As we see more profound effects from software we as an industry will eventually become a target.
"But in general, I would encourage folks in computer tech industries to be hesitant to assume such a binary approach to evaluating prospects. "Did you code for fun in high school?" might be a useful question now, because software development as a field is so young that high school students can try out significant work easily.
"
Just to be clear: That's not what I meant with "caring".
Higher end professional fields have more clear educational paths and job roles. Talk to 100 lawyers/doctors and you'll hear 4-5 similar job roles. Technology is totally different, 100 tech people will describe 20 roles.
My professional career has been mostly engaged in implementation, customization, solution design and administration. I'm not a practitioner of Computer Science, I'm more like a hybrid of an engineer and a tradesman. I define an engineer as someone who applies known knowledge/methods and a scientist as someone seeking novel knowledge/methods. There's a spectrum between scientist, engineer, tradesman, technician, etc.
Technology is different because you can enter as a tech or even a finance person and move into some engineering roles without formal education. Only a few corners of tech are off limits without formal knowledge.
Good programmers (esp. the ones OP referring to) are usually curious, like to tinker. So it's a valid check whether they like hacking since young age (I'm not saying those who don't are not good, but those who do most likely are).
Maybe a better analogy is an inventor (is this even a job?).
And one of the best hackers that I've ever met didn't even care or know anything about computers until his second year of university. And he's only two years out of school...
With all the caveats about dividing people into types, I think you need the curious / tinkerer types, and also the solid / bureaucrat types. At least, this is true if your business has reached a size where scaling is an issue.
I'm of the curious / tinkerer type, but putting a bunch of people like me on a project where the customer expects a 20 year service life, and operations expects to maintain their sanity, is not recommended.
In my view, starting from scratch in college and learning programming in a classroom may be harder than learning it by trial and error in your spare time.
Say what you will, but who would you rather have take out your appendix? The doctor who worked nights and weekends to put him/herself through medical school because it was the love of their life and their dream to help people?... or the guy/gal who only chose the same career path for the money?
Both are probably just as qualified because of standards.
Also, those in it for the money have to do extremely well to earn that money. They can't just hand waive stuff regarding surgery.
Exactly. For someone to call themself a doctor, they had to at least go to medical school and pass the board exam. Even the worst lawyer passed the bar. Anyone who is a pilot has passed their FAA examination and check ride. Yet, anyone can call themself a “Software Engineer” with zero formal qualification and zero evidence of passing even a basic competence hurdle.
It seems pretty weird to have to argue the point that just like anything else in this life, doctors, lawyers, mechanics, cheese, wine, and toilet paper, there are good quality and bad quality... you get what you pay for, etc... why would this be any different?
I want the person who is going to do the best job. Hiring is hard because there are few reliable proxies for knowing that in advance. It's not as simple as "who worked the hardest to get here?"
How can you tell the difference between products/services made by someone who makes said things out of the sheer love of making them vs. someone who only makes said things when compensated properly?
I assure you that there are many things myself and others do well, some of which we like doing more than others, that we're absolutely not going to do if someone isn't paying me for it. Frankly it's one of the things that defines a professional--getting tasks done even when it becomes a slog or you're just not that into it.
The medical resident analogy can't be used as an umbrella example proving that it's absurd to look for passion on a personal level. There are other professions where passion is almost always expected. Car mechanics are all about cars; plane pilots are all about planes; academics are all about whatever their subject is; architects are all about buildings and houses; anyone on the artistry side is all about their art. I believe that most engineers also have quite passion about their craft. Don't get a civil engineer started on how bridges stand unless your afternoon is free.
In a sense I feel that this current trend of promoting software development as "just a job" is yet another step in the ditch that is forming between the ideal of "software engineering" and the reality of "software development". It's the way things are going and I have no strong feeling about it one way or another, but it seems obvious to me that employers would be more attracted to someone with passion for the craft, as well as fellow passionate wanting to work among a crowd like them.
> "Did you code for fun in high school?" might be a useful question now, because software development as a field is so young that high school students can try out significant work easily.
This just makes the same kind of mistakes that the article is saying to avoid.
Asking if they programmed in high school doesn’t necessarily gage their current passion anyway, just their one time passion. Perhaps it’s better to just ask directly: “can you give examples of how you’re passionate about programming?”
> "Did you code for fun in high school?" might be a useful question now, because software development as a field is so young that high school students can try out significant work easily.
In a way it might be a way to weed out people who are reluctant to try something new. someone who only coded in highschool, a somewhat antisocial hobby, went through college and still only wants to code maybe didn't try anything new.
I had a feeling this would be misinterpreted. I wasn't sure how to word it but no. It's possible to find your passion at a young age. I'm skeptical though. I think it would be a question to branch off of if your discussing it with someone. At 13 how much do you really know, or even really experienced.
Lately I have been thinking that passion is something learned.
Building simple,solid, maintainable software that does what it is supposed to?
Or cares about chasing every new fad, has ten frameworks listed on their resume and is currently midway through the machine learning / blockchain hype?
I care about the former, but plenty of people would see that as having little "passion". For example, I don't have any experience using NoSQL databases on my CV, because I haven't had a use case for them and I could tell that they weren't all that they were hyped up to be 5 years ago when those were peak hype cycle. (I can design a relational database properly and know how to index it and optimize queries).
Ten years is plenty of time for this industry to kill any passion you started with. I still care about producing good work.
After programming professionally for several years now I'm always shocked to hear that people program for fun in their free time. Once I get home from work, the last thing I want to think about is writing software.
For many, it completely depends on time spent at work and effort spent at work. I've been on both sides. If you spend a lot of time and effort at work (not a bad thing), your desire is diminished outside of work. However if you don't have to spend a bunch of time/effort at work, there is time/effort available. Granted, even that relies on whether you enjoy it over other things, but you shouldn't be shocked.
I find the programming that I do for work to be fun. I consider this one of the blessings of the career for me. Solving/reproducing bugs and deciphering other people’s code is intellectually stimulating similar to sudoku or crossword puzzles.
If I weren’t working such long hours currently, I could see myself creating a webpage or writing an app, or playing with arduino for fun. But as it is, I’m pretty much tapped at the end of the day. I don’t really have the mental energy (or solid blocks of time) to accomplish much of anything.
I could definitely see myself doing it if I were in a situation where I didn’t have to work. (If I won the lottery or I had a rich wife/parents or whatever).
True, but am able to get excited about something that "scratches an itch," or will improve longterm productivity. Your commute might also be killing some enthusiasm, I know it did when I went in to the office.
I find it much easier to deal with someone who has no relevant experience but cares vs someone who had 10 years experience but doesn't care
Why?
This is a legitimate, but deeply opinionated "why". You employing me and me working for you is a business transaction. Why should I care about your mission beyond giving enough 'care' to produce great work that helps you run your business, run it well, so much that you'll want to keep the relationship going, but maybe provides me with some learning opportunities and skills that if we part ways, I don't starve looking for the next opportunity.
That's it.
I don't care about whatever your mission was when you started the company, I don't care how you think you're saving the world by creating another conference call platform. In my 22 year career I have deeply truly cared about one company that employed me. One. And even then, it was still a transaction: we need your skills, I have those skills, let's trade and do good work together. That's all I need to 'care' about, IMO it's all the employer needs to 'care' about.
Caveat Lector:
---
Maybe I'm jaded looking at a tech industry that doesn't seem to have a damn clue what it's doing when it comes to hiring, disaffected by all of these bullshit job requirements that are as far removed from reality as Earth is from one of Jupiter's moons, and offended by these job interviews that feel less like conversations and more like I'm trying to outwit a power hungry DM during a game of Dungeons and Dragons.
I don't care if you care about the mission of the company. It probably helps but I don't care that much either as long as the company doesn't do anything illegal or something I find ethically objectionable. I care whether you care about your craft and want to improve. I care if we can have interesting discussions about work and tech or if you just want to be told what to do next and never contribute anything interesting.
I spend around 40 hours a week at work so I want to make this as enjoyable as possible. To me that means mental stimulation and enjoying working with my team. From my experience people who respect each other and enjoy each other are vastly more productive than people who don't.
I get why you're jaded, and I certainly agree there is a lot of bullshit out there. Especially people who say they want passion, etc, but what they really want is cult-like devotion that can be exploited.
However, I think there are three big reasons that I don't want to hire people who are just clock-punchers.
One is the users. When I start in a new domain, I work hard to understand the people the product is meant to serve. And when I'm running teams, I work hard to make it so that everybody can develop empathy for the users. I don't believe it's possible to make great products without it.
Number two is the team. Google's research on good teams [1] matches my experience: you don't get good teams without people who care about their colleagues and what they're doing. I get the desire to think like a plumber, who just comes in to fix this one sink and then goes away again: that's easier and less risky. But software is a team sport. So I want people who care about their team members.
Number three is the bigger scale: infrastructure, process, culture. Anybody who just wants to focus on their contribution does that at the expense of paying attention to broader impact. I want to work with people who notice and care about that, who are interested in making tomorrow better than today. For themselves, for their colleagues, for the users. Because that shit doesn't happen on its own.
So yes, bullshit job requirements are bullshit. And any requirement can be bullshit given the context. But there are contexts which really caring is vital, and those are the places I want to work.
That's legitimate, and I would take you any day over someone who cared a lot but had no relevant skills. However caring about the business is absolutely a value-add. Don't get me wrong, you should be careful to avoid being taken advantage of, but generally you will have better career progression if you can inhabit the space between emotional disengagement and being a kool-aid drinking doormat—it's actually a pretty wide space.
>> Now someone who has 10 years AND cares is rare but pure gold.
As someone who started programming from a young age and has almost 10 years of commercial experience, I have to say that being in this industry is horrible.
If they promoted people using a random number generator, it would be a step up from what we have now.
The most horrible thing is that in spite of your passion and experience, your ideas are constantly undermined by money-oriented snake oil salesmen who make extraordinary optimistic claims to become liked by management and get promoted quickly within the company; then, just before everything falls apart, they jump ship for a higher position in a different company and let other people deal with the consequences of their past actions. That's why it's really hard to find people with 10 over years who still care. Caring is a weakness.
I was at a Big-4 consulting company at my first job. I once got passed up for promotion because they said "i didnt handle critical production situations with clients, analyzing them and planning to bring them to a close."
I explained...that is because I had such perfectly tested work that I didnt have any major Production issues requiring critical client meetings or mitigation plans. The success criteria there was almost encouraging poor delivery!
I was at a defense contractor early in my career, and the government had this idea that our CMMI-certified process was supposed to demonstrate that defects were being found and corrected at various stages of the review and testing process.
Implicit in this was an assumption that a certain number of defects were there to be found in the first place. As a result, if you were too thorough and conscientious before your reviews it actually reflected badly on your reviewers, because they weren't finding anything. As a result, we started pushing out intermediate WIP that we knew had problems so the defects could be "found" and "fixed".
"money-oriented snake oil salesmen" aren't the problem though. They're just selling stuff to earn your salary. The real problem are the bean counters and the managerial trends from 1980s onward.
For every manager who grew from the rank and file, understands what their teams are going through, and shields their teams from the BS, there will be another who went through business school and was indoctrinated that you should ask for more than what you want, to hell with the consequences and the corner cutting, and the rank and file will figure it out somehow to deliver what you want.
The bias for promoting people who build massive card houses is frustrating. I've found myself cleaning up the mess my manager left behind pushing through whatever feature he used to get promoted countless times. And then getting pressure by that same manager when there is too much tech debt in the code base they left behind.
Most companies promote based on the surface level “what you did” rather than “how you did it”. It’s not going to change. Be glad you don’t work for one of those companies that promote based on who you’re friends with.
And what about when companies these days exploit the term "caring"?
I like programming as much as the next person here but i'm not going to code 80 hours a day. I also like going to gym and working out, riding my bike, playing soccer and hanging out with friends.
Companies these days expect you to have side projects or contribution to popular open source libraries while having a job. Oh and did i mention asking you questions about algorithms and data-structures that you most likely haven't used in years and won't be using for foreseeable future?
Related point, some companies don't intentionally exploit this but end up hiring someone who works and commits code cowboy style 14 hours a day. The company thinks that person is amazing while the person's coworkers hate working with them.
I’ve worked crazy hours for weeks at a time learning a new to me technology or trying to figure out something. I purposefully, don’t tell anyone that I’m working late or on weekends and I don’t send or respond to emails outside of office hours. When I was Dev lead, I recommended no one send or respond to emails outside of normal office hours. If they were really having an issue or wanted to work late to figure out something and they had a quick question, I would sometimes answer over Skype but I would never communicate outside of the team or with management outside of office hours unless something was blowing up. Even then, my manager would have to call me or Skype me. I told them that I don’t have work email on my personal phone.
On the other hand imagine how much you would learn if you could spend all you gym and bike time learning computer science and other things (not saying you should but the more time you out into something usually you know more about that thing).
Also I think knowing data structures is essential cos you are using them ALL the time you just don’t know it cos you never bothered to learn them. But they are corner stone of every program.
>On the other hand imagine how much you would learn if you could spend all you gym and bike time learning computer science and other things (not saying you should but the more time you out into something usually you know more about that thing).
On the other hand imagine how much could you get done if you worked 16 hours a day. Why even take vacation? Imagine how much time you are wasting when you are off on vacation. Oh wait, studies have shown that amount of hours sat in the chair doesn't translate directly into quality work. It might work when you are doing it occasionally as a one-off but won't work everyday.
>Also I think knowing data structures is essential cos you are using them ALL the time you just don’t know it cos you never bothered to learn them. But they are corner stone of every program.
Did i say that? I know what a graph, BST, Tree, Linked List, Stack and Queue is. Do i know fancy algo's off the top of my head? No. But i also know how and what to google and how to convert that pseudo-code into actual working code.
Thing is i have completely different experiences in my. life with this sort of thing, i am not saying you should do it but that each person have different driver in life.
> Also I think knowing data structures is essential cos you are using them ALL the time you just don’t know it cos you never bothered to learn them. But they are corner stone of every program.
Disagree.
Most data structures fall into four categories:
1. Basically a list/array/set
2. An association (map/hash table/dictionary)
3. A struct/record
4. A union/enum/choice amongst finite options
It is only in specialised algorithms and when strictly necessary that one must deviate from these (and the second two aren’t even really data structures). In such situations it can be useful to have other things known but even then I think a lot can be done with some combination of:
1. Binary tree
2. Trie
3. Hashing and Bitvector magic
4. Canny
I don’t think much is lost by getting stuck and needing to research in such cases.
Looking from the outside, you might assume that I have a “passion” for development. I check all of the boxes.
- started programming in 1986 in AppleSoft Basic and 65C02 assembly language.
- graduated with a degree in CS
- I can bit twiddle pretty well and spent the first 12 years of my career doing C.
- I read blogs, post in technical discussion, listen to podcast, etc.
- I have up to date AWS certifications.
Etc.
But I don’t think I have a “passion” for development. I do it to pay my bills and remain competitive. I don’t do side projects but I will work late to learn a new to me technology or framework. I definitely don’t spend time learning frameworks or technologies that aren’t marketable.
Just the fact that you read blogs and post in technical discussions shows that you care to improve your craft and don't just wait for somebody to tell you what to. There are no hard criteria to define "caring" but I like people to do something. Read stuff, know at least a little about the latest trends, think about ways to do things differently, try out things and so on.
The passion/craftsman culture changed when we started selling our souls for the next ad-click or personal information collection system.
While it might have seemed good back then, we now have a massively cobbled-together web ecosystem. I know it's a cheap shot, but those same passionate people built the crap we have today. I don't think it speaks very highly of that time or the merits of passion.
(many individuals had passion back then and would be strongly against today's web practices -- I do get that)
When you start peeling away the layers of the career, the actual craft is only a portion of today's work. If I could code 8 hours a day, I would. But it's hard to spend a day in the workshop with that passionate, quiet, productive focus.
> The passion/craftsman culture changed when we started selling our souls for the next ad-click or personal information collection system.
I am really passionate about the information collection system I work on. I do my best to ensure data isn't leaked, everything is secure and encrypted. If you would like to offer a solution to the fact that the vast majority of people in this country now expect software to be free (save, some AAA video game titles), I am all ears. Until then, I am going to be passionate about what I do, but realistic as well as I have a family to provide for.
> If you would like to offer a solution to the fact that the vast majority of people in this country expect software to be free
This is critical. I think it even goes beyond this: most developers expect software they use to be open source. People have gotten used to the software from Google/Facebook/etc that they can develop and release as open source due to their essentially infinite revenue stream.
>If you would like to offer a solution to the fact that the vast majority of people in this country now expect software to be free (save, some AAA video game titles), I am all ears.
Subscriptions? I pay for Netflix, Amazon Prime, Github, MS Office, a VPN, and probably a few others.
If you're B2B, use price per user/customer/developer? e.g. Highcharts was worth the money vs. free options.
The problem is there's no guarantee you don't also collect info or decide to play ads even if I pay for a subscription.
I trust that we all have a general vested interest in avoiding data breaches for sake of profits and public image. I do believe that we need a tad bit of regulation around data collection not because we are all shitheads that throw your data around, but for those couple of bad actors that ruin it for everyone to bring their businesses up to par with what the rest of us are doing -- but nothing as extreme as GDPR. This is America after all, and liberty is hard, but I still believe it's the most important principle. At the end of the day you are still entering an agreement to exchange your information for the use of the services, and you are at liberty to not enter into that agreement. It's obvious to me that people are not concerned with that enough that they are willing to shell out money for their email, content, recipes, craft ideas, photo storage, social platforms, payment platforms, and until the people change the business incentives will be focused on data collection. To not sound like I am on that high horse, I too utilize many of these services. The problem however for me is not unwillingness to pay, but as it stands right now there isn't a paid product that can compete with some of the services I get for free.
It’s an unpopular viewpoint on HN, but I truly don’t believe that using personal information to deliver targeted advertisements is immoral, provided that 1) a best effort is made to make people fully aware of what information is being collected and how it is being used, and 2) a best effort is made at keeping that data safe from being leaked.
I just genuinely don’t understand how if someone gives personal consent to use their provided data in a specific way, then the company is still acting immorally.
Society has moved forward over the last few decades in favor of people using their body however they like as long as consent is given and no one is hurt, so why is it not the same with information? Why is personal consent to use my information not enough, to the point where we want to force companies into a payment/subscription/no targeted ads model that may not actually work for their business?
Consent in the digital world is fraught with difficulty:
1) Do you have to repeat consent every time the ToS or another policy changes?
2) What about repeating consent every time there is a feature change?
3) Should your consent remain after controversial events involving security (FB using 2FA phone #'s for ads; data breaches like Equifax)?
4) What about internal company changes like leadership changes at the executive level?
Unlike consent involving intimacy, there is no big red line where it clearly becomes non-consensual. You can technically delete all of the data, but no one has built something that does that and is trusted. There isn't a right-to-be-forgotten law in every country, so archiving sites can still retain this information anyway.
Plus, it could always be on some flash drive that a malicious employee passed to other companies. Large companies like Facebook have pockets where people can essentially operate with impunity or oversight for periods of time. The core issue here is that consent to one site proxies affirmative consent to share your information out to other sites.
As a hypothetical, would you give consent to Facebook knowing that they will then share all of that information with anyone who asks (every site, every 3-letter agency, every stranger from anywhere in the world who likes your bikini pictures)?
What if they say they won't share that information, but they do anyway? Tech companies move too fast for law to keep up, and once the information is duplicated to multiple parties, it's almost impossible to track down every copy with certainty.
I could agree in theory, it's just that 1 & 2 don't happen in the real world. (Outside of EU?) There are no incentives, responsibility, or consequences for folks once data has been acquired.
It's like the friend that swears they will pay you back if you would just lend them a substantial amount of money. Said enthusiasm drops 95% once the transaction has completed.
My team has had this issue in hiring. Much of it is due to bootcamps telling students they will make massive salaries after a 6-month course. That has attracted a different crowd of applicants.
We are always open to junior engineers, but lately it has been rough interviewing them. It's common to see applicants with no real world experience asking for $100/hour. About half didn't have a portfolio anywhere, but said they could get a recommendation from their bootcamp instructor.
One of our last ten junior applicants had a passion for software. 9/10 of the last applicants were motivated by money and asked for ~$100/hour rates. We've stopped actively interviewing juniors because of it.
Same in our company, where I am tasked with phone screening and it's been horrible to interview junior candidates because most of them are looking for good salary rather than passion for computer science or solving the problems not seen before. Ironically, most of them have completed Master's in computer science as well.
You ever read any of Michael Lewis' work? He's written several books now that are thematically similar but he's famous for writing an expose of Wall Street's Solomon Brothers called "Liar's Poker". It was fairly critical of Wall Street and its practices but was also filled with lurid descriptions of what the traders got up to with their new found wealth.
He was regularly contacted for years afterwards by people wondering how they too could get a high paying job on Wall Street.
They pretty much have to because the majority of environments they have to work in aren't hospitable to people who actually care. Hence many of us eventually get to the point of "just make it work" that we once used to scoff at on HN. As with most things in life, software engineers eventually beat the game only to find that there was nothing to win the whole time playing by a set of ideals.
I carried this torch a lot longer than most. I never really gave it up because I was fortunate enough as a young man to be in some environments that proved to be that for certain values of “right”, doing the right thing now makes you faster a year from now. And it’s painful to watch a project grind to a halt as bad code accretes.
Since I took up gardening I’ve developed a more nuanced view on this. For perennials, there’s a way a plant “should” be but the plant is organic. It has a life of its own. Trying to force it will kill the plant. There is a tempo to bending it to your design and for some plants you need a five year plan to get there, and the plan changes several times.
For software I don’t have that much patience. I change jobs more often than houses, and I expect a team to listen to reason, so the more like a 2 year plan.
To get A you often have to give up on B or C for a while. Pick priorities that are constructive and try not to grind your teeth while the wheels of progress grind into motion.
Bingo. As an "old timer", it's not that we don't care; we still love the craft as much as ever. It's just that we are at a point in our careers where we can afford to have a much lower tolerance for bullshit.
Manager says "let's have a weekend pizza party hackathon!!!" and the old-timers are the first to recognize and decline the opportunity for unpaid overtime fixing bugs.
As I said in another comment caring about producing good work is completely different about caring about every hyped up new trend that our industry comes up with (usually a rehash of something from 20 years ago).
As a manager I never do nor support hackatons except when the team themselves suggest it's the only way... but when I myself have to code or fix or debug something that needs grind time I still enjoy them. If I'm not getting payed enough to put that hours is another issue to discuss with my manager besides the pizza hackatons themselves.
In my younger days (I'm only 35 lol) I used to want to apply for jobs that said junk like "fast paced environment". Now I'm like screw that...
I mean every company wants you to work as hard as possible and turn things around...but now I feel the ones publish it want to put you through the ringer.
That's a great way of putting it. "Choose your battles" in other words. I look back and I can remember getting very wound up about some things that just didn't matter. And, today, I shake my head a little bit at people for whom every single little thing is something to man the barricades over.
I remember a job as a junior programmer: typical 90’s era C++ Windows application. Compiling it with compiler defaults would spew out a continuous stream of thousands of warnings. This was before unit tests and static analysis were in vogue, so random crashes and errors everywhere. Major performance problems. I argued for code hygiene, fix all these crashes, figure out what’s behind the compiler warnings, etc. The response was predictable to anyone who’s been in software for a while: No, we actually need moar features! Keep spooning features into the software and we will succeed! One of my tasks was actually to write a separate process, a watchdog, that would detect every time the app crashed and re-start it quickly hoping the user didn’t notice. Totally demotivating if you were passionate about software craftsmanship. I started fantasizing that the company would crash and burn, and I would be standing there among the rubble saying, “See, I told you to fix those COMPILER WARNINGS!!”
Never happened. The company simply limped along in this now-familiar “zombie mode” neither succeeding or failing until it was gobbled up by a bigger mediocre company.
We've learned live is a marathon, not a dash. I'll churn out stable code; I'll deliver on reasonable deadlines; I'll do my darnedest to make the product the very best I can. But I'll do it at the pace of 8 hours a day, 5 days a week. I have a family and a life outside of your corporation that I truly value more than this, or any, job. I'm no rockstar. I build stuff that gets stuff done.
I have about 12 years of experience, occasionally I'll find myself really interested in some tech. But generally speaking, the technical problems don't interest me anymore. I find myself more fascinated with the business problems. But generally speaking, businesses have been structured to exclude the developer from these problems until it is dev time, in which case the problem is presented as "here's an issue, here's what we want you to build to fix it". So in general my passion has been lost. Finding a company where I can be present during the solution finding phase has been difficult with my pay level.
As a dev you usually stumble upon it for the architecture / coding part. But those are just details. The Domain part is all about the business: where do you add value, what things you can outsource because they're not at the heart of your strategy, which projects should get your better people etc.
So I think it can be a good bridge for people who come from tech and want to dabble in the business part of their company.
I worked for a small web-consulting agency for 3 years that allowed me to be a part of everything from the sit-down consultation with the client, to the estimation of engineering effort, to the design/build, and to the demo and support of the production version. Its not a given to have this access and you generally have to ask for it, but it is available to you if you ask.
Pros: I learned how to listen to customers, create proposals that tend to close, and upsell... all while being able to build the end product. This has helped me to close a good number of side projects after I moved back to working for larger companies.
Cons: The challenge working as an engineer in these small firms is that your resources are limited to the budget of the customer, which can be too small to do top-notch engineering work. You can generally find the balance without sacrificing too much quality, but you will never be completely satisfied with your work-product.
It's hard to truly care in any soulless corporation that cares only about profits and IT is seen generally as a pure cost centre (banking is worst in this, but others are not stellar either).
Another aspect is meaning of life - if your response is work, then you either have that 0.01% type of work which really matters (and is hardly IT, maybe in Red Cross/MSF style), or much more probably you are just lying to yourself.
Life has so much more meaning outside of work, outside of sitting in front of computers. The older you get the more clear this should be, even if you started as a hardcore IT geek. I know I did, but boy am I glad I moved on.
I used to be that stupid guy who would actually bring work home and do it for free after hours, because I loved programming so much and didn’t have any hobbies. Then I slowly realized it was not getting me ahead at all so switched over to just doing my own little hobby/learning projects at home, that all went nowhere, but hey I was programming and programming is fun! These days I don’t even want to get near a computer when I’m done with work. I’ve got a kid and non-technology hobbies that are more fulfilling.
I still enjoy programming, but it must be purposeful, there must be a goal and a plan. I won’t just habitually open a terminal and start programming something “because programming.”
Funny story (now), caring too much once got me "separated" from a high paying job, when an impulsive lead walked in and took over our project shortly before what would have been a successful delivery.
I want to add: I don't think "caring" means that somebody coded from early youth on or works another 40 hours per week on side projects. All I mean is that somebody is curious about the systems he/she is working with, explores things, stays at least a little informed about latest trends, maybe reads some blogs, thinks about ways to do things better, is able to criticize himself/herself (it's a good sign to be embarrassed about something you did years ago), learns more about the tools he/she is using than strictly necessary, tries to understand the bigger picture.
All this can be done in a 40 hours week. No need for overtime or starting at age of 3.
During a one year project I see a lot of people who barely grow during that time. Others grow a lot because they put in a little extra mental effort. That's the people I like to work with.
> someone who has 10 years AND cares is rare but pure gold.
One way to attract those people: choose to build your product using a rather exotic language (e.g. Clojure or Elixir). You take a substantial risk because the language is rather unproven and you will have a hard time finding experienced developers. BUT if someone with 10+ years experience makes the effort to learn a language that does not have an immediate payoff that is a good sign you found someone who cares.
Not meant as a joke at all. I have spoken to a few companies that chose Clojure as their development language. They had problems finding people because it's a new language. When I asked them why didn't they just chose something more established like Java with a seemingly unlimited supply of developers they said that they want to attract a certain type of developer that they are willing to train.
And that goes both ways. I want to work for a company that chooses language X instead of ruby-python-java-and-the-like because they care.
Mind you, this is not meant as a language bashing, not at all
Edit: obviously, those companies chose Clojure first of all because of technical reasons, but the hiring part is another perk
Not sure if you're familiar with the mentioned languages.
I've been working on my first Clojure/ClojureScript project for a couple of months now. Alone, with no previous real-world experience on any lisp. I dare say I'm more productive now than I would be with React+Redux and a Spring/ASP.NET/Rails backend (all of which I have experience with in more than one project).
I agree with the article on not hiring with the big tech companies' processes.
I wanted to add the book 'unlocking the clubhouse' on hiring by finding candidates who make programming/CS their life. There is nothing wrong imo on those who are passionate about computer science, but when you hire based on uber-interested in CS candidates, then you end up with a non-diverse team (not hiring people who didnt come into CS through the same route and didn't have the 'fortune' of being introduced to CS when they were kids). I'm not doing the book justice.
Having started in 2008, I was able to observe this as well actually. As a programmer who does the job because it's somehow in the DNA one needs to change according to that I think. People should probably care less about getting a fancy job or making one success after another at work.
Instead it becomes more useful to be comfortable with the work and maybe not care too much. Eventually people will see how people who breath this stuff are far more comfortable with the work and teams that include them produce far more pleasurable results.
As Programming has become mainstream in some way, far more companies look for coders, even outside of the startup space which creates much more opportunities also for people who know their stuff.
One popular idea is that programmers should be passionate and spend their spare time working on open source. Another career with a reputation as a stable well-paid job is law.
In law, pro-bono work is at least somewhat similar to open source work for programmers: It doesn’t directly make money, is considered morally good, and possibly a way to widen one’s experience. However in law, lawyers in a firm are typically required to spend a certain amount of time doing pro-bono work (during working hours) whereas the same does not happen with programming.
This has been on the tip of my tongue but not formalized. I don't think it even matters if you're talented or particularly brilliant. If you've felt the delight of bending the machine to your modest intentions of blinking a light then you tend to be a person I wouldn't be able to stop from tackling tricky problems if I wanted to.
The art, I think, in hiring and managing is how to build useful things even when you can't rely on everyone intrinsically caring and being self-driven. If you wait to find a dozen, fifty, a hundred people who care, you might miss out on a lot of opportunities.
That's how most big companies work. Their processes are designed for average people who do average work. It works well for them but personally I find such an environment depressing.
Anecdote: I had been programming for ~12 years consistently by the time I got my first job. Almost entirely for fun. I'd managed to get jaded with software (especially commercial software) by this time.
I'm considering going back to school for tropical paleoclimatology, largely because I never cared much about the career prospects.
Maybe there's nothing wrong with doing it if you want a good career? Hobbyist programming is substantially more rewarding, in my opinion.
It just seems like false dichotomy to me. The idea that you must project passion the right way else you don't care. I think it did not worked that way on 90ties either.
Also, people who stayed in this industry long do care generally.
There is also something good to he said about people who understand importance of boring tasks and negotiation and planning and process and do those boring tasks.
I think the term "passion" has been abused a lot to mean being excited and loudly proclaiming "I am so passionate. I love it.". I am not likely that and I dont expect to be like that. With passion I mean the desire to learn and do a good job just because it makes life more interesting. I work around 40 hours a week and I try to make this time as interesting and enjoyable as possible. To me that means to do a good job and improve as much as possible. Once I am on my way home I don't think about work anymore.
Yes, one maybe two pass/fail questions at random, $200k in a suitcase, clock ticking, pride/family/livelihood on the line, (unintentionally) smug host watching your every move. Any problem is trivial easy once you've solved it ten times.
The otherwise ridiculous film Swordfish has a similar scene with higher stakes.
I'd go so far as to ask: "can this candidate learn to do the job?". In our recent job postings, I've started adding a specific paragraph after the desired qualifications stating more or less "if you don't tick all the boxes above but are motivated to learn and grow, please apply. We'll teach you what you need to do the job"
> 2. Will this candidate be motivated?
This. Even more than question 1. I've had a lot of good surprises with motivated candidates who didn't have all the expected qualifications. Some of my best hires were people whose CV didn't line up with what I was looking for but who demonstrated impressive motivation to get the job. On the other hand, I've often been disappointed with "perfect" candidates who didn't have the right mind-frame for the job. (Note: I'm not saying I'm expecting slavish devotion and "giving it 200%" every day of the week. But if your personal, intrinsic motivations don't align with the job's responsibilities, it won't work).
> 3. Will this candidate get along with coworkers?
Duh. But also, how do you actually test objectively for this without introducing bias? And how do you insure you're not creating a monoculture that will eventually harden into navel-gazing and dogma? I'm really of two minds on this topic.
> 4. What this candidate will be in three, six, twelve months from now?
Related to the rephrasing of 1. Can the candidate learn and grow? And will we provide the right environment for them to grow?
One of my favorite quotes is from an ex-manager who hired me when I was far from ticking all the boxes on the job description. "If you hire someone who has all the necessary qualifications for the job, they'll be bored in 6 months."
>> 3. Will this candidate get along with coworkers?
> Duh. But also, how do you actually test objectively for this without introducing bias?
You can't because it's a bs metric like "culture fit". After about a dozen people, you can no longer ensure people will get along or like each other. I only have five brothers but I don't even like all of them.
People have quirks, and it's easy to find reasons to pass on candidates because of them (reminds me of Seinfeld and how the characters ended relationships because of man hands or toes). I see this a lot in non-technical hiring where marketing folk exclaim "I like the candidate, we have great rapport" only to discover the candidate was subpar.
> I'm really of two minds on this topic.
I used to be, but after suffering through a bout of mental illness that rendered me an anxious mess when I was once the life of the party really changed how I evaluate this dimension. Be kind and assume the best, which we can all agree would be amazing if the tables were turned.
When I look for personality, I'm looking three things:
* How they ask questions for things they don't understand
The problems I give are directly applicable but I leave a few slightly vague. Someone really experienced could fill in the missing pieces easily, but usually this doesn't happen. I then ask them if the problem makes sense or if I missed anything. If they can't tell me that the problem isn't clear, or they need more information, then they'll have trouble working with a team trying to solve and communicate problems.
A mediocre candidate will say that the problem isn't clear with "I don't understand". A good candidate will explain what they don't understand. A great candidate will ask for clarification on the vague piece without much fuss.
* Reaction to not knowing something.
I have a hard problem that I give at the end. I clearly tell them it's not expected to be solved and that I just want to talk about how it might be approached. If they get angry, say "oh I know how, just give me 5 more minutes" then stand there blank, etc, then they're not going to fit in a team that is trying to solve hard problems together.
A good candidate will stay calm and provide any sort of input, ask any sort of questions, or show any sort of interest. Sometimes people get nervous here, so I keep this very very lighthearted.
* Are they full of themselves/assholes
This is pretty evident within the first few minutes, and really rare (and almost always accompanied with a stream of buzzwords after every sentence).
Everything you've mentioned are shallow assumptions based on brief exchanges with people. These are not qualities you can effectively suss out in a few hours through an interview process. You can at best get hints, but just like how GPA is not an indicator of a students on-job success neither is an interview - or our conclusion - any better indicators to the candidates success.
> Are they full of themselves/assholes / This is pretty evident within the first few minutes
Not it's not. People can act awkward during interviews, it's a stressful situation. Some people need to peacock to feel self-confident - I may not like it, but I'm not going to fuck with their future because of an emotional reaction I had to how they present themselves. I've hired plenty of "assholes" that just needed the benefit of the doubt and a chance to grow.
We're not psychologists or therapists, so we should we stop trying to "figure people out" and decipher complex human interactions & behavior by trying to bucket them into checkboxes for whether or not someone is good.
Be kind, give the benefit of the doubt. This is someones career on the line, not a first date. Treat it with the respect and gravity you'd like someone to give you.
Hey, if a candiate is ready to be an asshole in an interview, what are the chances that he will be an asshole to his team members to just get that raise or a promotion?
He's not being an asshole. He's probably stressed out and doesn't know how to cope well. This is behavior that can be addressed and improved. After 20 years and hiring 100+ developers through three exits and an IPO, I've only met 1 actual "asshole" that couldn't integrate and needed to be let go.
The problem is that we're too quick to be offended and we look for excuses. I'm in the middle of hiring a business analyst, and my COO didn't want to hire him because he didn't send her a thank you note after an interview (but he did send one to me). She thought he was an asshole. See the problem with that train of thinking?
He's not being an asshole. He's probably stressed out and doesn't know how to cope well.
Life is stressful, work is stressful. My manager and his manager are reasonable people but after my second assignment, they said I missed a requirement and that it was a “big f’ up”. Guess what? I found that refreshing after dealing with managers that beat around the bush and you had to constantly try to figure out what they were thinking - or even worse, they didn’t tell you anything until your review.
I’ve had to whiteboard architecture in front of CxOs, be interviewed by potential investors, etc. It’s when things get stressful that you really need people who can keep their wits about themselves.
> they said I missed a requirement and that it was a “big f’ up”
It's free to say things, doesn't make it true. Too often we assume because someone is in a position of power - or is wealthy - that whatever they say must be true. It's not. Sure, we have to nod our heads and pretend it is to keep the job but that still doesn't change the reality.
Shit rolls down hill with exponential momentum. I've seen many instances where a CEO says something innocuous like "I'm a bit disappointed in X" but by the time it gets to someone that can fix it the management in between transformed it from a simple comment into a condemnation. People like to exaggerate things to make something seem more important or impactful than it really is.
There's also a big difference between an interview and dealing with work everyday. I know plenty of people that shine under the pressure of interviews but not under the job itself (and visa versa). You cannot determine these things about a person from an interview. Period. Performance in an interview has very little correlation to job performance (if any).
> you really need people who can keep their wits about themselves.
I need a diverse group of people that I can collaborate with to get things done. If they can't keep their wits about, it's my job to deal with that issue and get them back on track and protect them from organizational crap. Might as well expect every girl or guy you date to be a model with a PhD.
Well, when the requirement was in big bold writing as one of the key features on a PowerPoint slide...
I need a diverse group of people that I can collaborate with to get things done. If they can't keep their wits about, it's my job to deal with that issue and get them back on
That’s not a luxury you have as you move up the ladder - even if moving up the ladder is just being a real senior developer/architect (by knowledge if not by title).
My first job at 22 was as a computer operator trying to get my foot in the door was within 6 months build a custom, networked data entry system used to support a completely new department and a new line of business. Working at small companies, you don’t get the luxury of hiding within the bureaucracy. The one time that I did work at a large company, it was suffocating.
> You can't because it's a bs metric like "culture fit".
I'd disagree. An indirect metric is "Can I as the technical lead [1] communicate effectively with the candidate?" If the leadership is stable, then a "yes" to this question is likely to imply "yes" to the "getting along" question. If all "subordinates" can effectively communicate with the "hub" (lead), it's not unreasonable to expect that they'd be able to get along with each other using the same mode of communication they use with the lead. That's what my intuition tells me. May be wrong though.
[1] Presumably, the technical lead takes part in the interview process.
I translate this as wanting a candidate that is compliant and can remove his ego to work in a hierarchal management structure. This is fine, of course, but let's not confuse that as "getting along" or "culture fit" when it's really "following orders".
We have taken out any mention of "culture fit" which to me means more of the same. Instead, we measure culture addition. How will this person add to our culture?
1) Can this person DO things? This doesn't even have to be the kind of things we need done. A diversity of experience or interests is mostly what I look for.
2) Can this person LEARN things? Again, some diversity of experience goes a long way.
3) Is there enough interest in learning to DO what we need them to, and enough education/experience to get started reasonably well.
I start by looking for verbs on the resume. It's amazing how many people say "I was on the team that XXX for system YYY which was a type of ZZZ with technologies ABCD" and never say what they actually did. I say "I understand there's this push for being a team player, but I don't care about that, I want to know what you did." Sometimes this shifts them into useful discussion while other times it reveals that they didn't really do much if anything. One of my co-interviewers once started crossing out whole lines of a guys resume right there in front of him which was a little cruel, but made the point to the candidate.
Again, a diversity of things done and an interest in learning to do what we need is almost everything. I leave the personality evaluation to other people in the process but will vote "no" if something about them really bothers me.
This doesn't just apply to technical jobs. There are things managers need to DO. Letting your people handle the tech does not absolve someone from adding value to the organization through what they do.
We took out all mentions of prior knowledge and experience in our entry level job postings. In our more experienced posting, we only ask for prior work experience building software for X years. We list only our stack and even caveat that by saying that it can change. I can wager that most software engineer positions fall in this category.
Another relevant point here is that women are less likely to apply for positions with a predefined list of requirements even if they are only missing 1 of them as opposed to men. So why are we shooting ourselves in the foot with all of these requirements?
>> 3. Will this candidate get along with coworkers?
> Duh. But also, how do you actually test objectively for this without introducing bias?
Dev team cohesion and harmony is hugely important for us. We'll pass on a highly skilled engineer any day if we believe they'll sow division and conflict on our dev team.
In the sense of hard metrics, you can't really test for a toxic personality, but here's what we do:
- We have engineering candidates come on-site for a couple hours before formal interviews and chat informally with several of our engineers. Our engineers show them what they're working on, what technologies we're using, etc. You can learn a fair bit about someone just based upon less formal interactions with a variety of different people. Are they showing interest in what we're doing? Are they eager to tell us about something similar they've done? Are they a respectful attentive listener while a junior is showing the candidate something? Can they communicate and express themselves easily? Obviously candidates are on their best behavior when they come in for a visit, but you can still pick up on certain behaviors that might indicate a problem.
- During formal interviews, we ask candidates the following questions: Tell me about a team project when you had to work with someone difficult. How did you work through that? Could you tell me about a time that you disagreed with a rule or approach? Tell me about a time you made mistake that you learned from and what you’d do differently the next time? The answers to these questions can be very telling. We've had candidates who have been unable to think of a mistake they've made as well as candidates who thought of a mistake they made, but then spent the next 5 minutes explaining how it really wasn't their fault. We've seen some people describe some truly awful approaches to dealing with difficult teammates.
> And will we provide the right environment for them to grow?
This.
I'm so tired of investing in my work and my workplace to have obscure management "advice" on fixing my character flaws (e.g. being too soft / too emotional) to have any chance of growth by trying to transform in to something they want.
Part of that is on me- the picking and choosing of battles is a real problem for me- I care a lot about maintaining high standards for code quality with automated linting and formating, for instance.
I like having soft skills and as I tell anyone I'm interested in working with- I want to work with nice, intelligent people; in that order.
> I'd go so far as to ask: "can this candidate learn to do the job?". In our recent job postings, I've started adding a specific paragraph after the desired qualifications stating more or less "if you don't tick all the boxes above but are motivated to learn and grow, please apply. We'll teach you what you need to do the job"
Totally agree. I was involved in the hiring process (new for me) in the last two hires and this was my main motivation. I primarily looked for passion in the field[1]. I didn't care if they explicitly knew what we were programming in, or what frameworks we were using, or w/e. I wanted to know if they were interested in the area, if they wanted to learn (if needed), and if the workload areas (backend, frontend, etc) were areas they wanted to work in.
I wanted to hire a bright person, passionate in what they do, and interested in the problems we'd give them[2]. I felt like if those three were true it didn't matter what they knew.. within reason, of course.
[1]: I'm not saying what I did is right or wrong, just explaining what I did.
[2]: By interested, I mean they want to work in X language with Y workload. Not explicitly that they were personally invested/interested in the product domain as a company. I wouldn't expect that of anyone.. rarely, imo, do companies inherently do such interesting work that people should be personally invested. Ie, solving cancer or feeding homeless. A job can be a means to a paycheck. I just want it to be enjoyable for all involved, as much as possible at least.
I agree for most scenarios. However, when building out a team, you can't hire a bunch of people you're going to have to train. Sometimes, like I had to recently, you have to hire an individual that has the skills you need at the moment who can help mentor and help others learn the tools and frameworks needed.
Yea that's definitely fair. It's also a movable "bar", as even in my example I mentioned within reason, because I wanted to hire by passion, but they needed some pre-existing skills. So it's all relative
Duh. But also, how do you actually test objectively for this without introducing bias? And how do you insure you're not creating a monoculture that will eventually harden into navel-gazing and dogma? I'm really of two minds on this topic.
Give them a simplified version of a class that represents what you do everyday with failing unit tests. Have them pair program with another developer to make the unit tests pass.
Then once they do that...
Give them another set of unit tests for the same set of problems and add more requirements. They have to make the second set pass without breaking the first set.
It’s realistic, you can see how they think through a problem, and you can see how well they work with others.
Would you mind sending me a link to one of your job postings? I'm a mechanical engineering graduate looking to pivot into a CS career. My temp email: stadumajoc@memeil.top
Hello, as I replied in the thread above I'm based in France, so the job postings are in French. However if I have a bit of time I'll put up an English translation as well.
My co-founder and I believe so strongly in this that we started a company around it.
So many companies are willing to let perfect be the enemy of good. It's why this concept of an MVP has to be hammered in over and over again. And yet, we still let this mentality pervade hiring. We hire people on the slim chance that they'll need to re-implement a consensus algorithm and not on the 99.99% chance that all of their work will be writing CRUD-like code.
We (as in, Headlight) deal with a lot of bootcamp grads and people who are entering tech later in life (which for tech, means 25+). It's shocking the number of them who are insanely adept at software development for the amount of experience they have and are completely overlooked because of any of the following:
* Their pedigree
* Their experience given their age
* Their program's focus on practical software development and not on more academic topics
It's really mind-boggling. It's great for us, because it's a totally unappreciated and under-served market. Still, I can't imagine how frustrating it is for those candidates. We're still new, but so far our clients' satisfaction with our candidates has been nothing short of enthusiastically positive.
All that to say, you should really consider adjusting your hiring expectations drastically. You're building a house. Why are you trying to hire a civil engineer, and not a contractor?
Yes but it's mind-boggling how complex you can get quite a straightforward system by just piling new requirement changes on top of old without maintaining proper data-model in application, even if database is fine-ish, this results in a monster that slows down the system and the development speed.
So in principle, a lot of people can do it but only some do it while not making things more difficult for the next person.
We recently hired an outstanding engineer who graduated from a bootcamp and previously did not apply because we had an archaic requirement around "BS Computer Science or equivalent" in our job description.
It's definitely possible to write your resume so that it just shows off relevant experience. I started programming professionally at age 26 - reading my resume, you basically just see my professional experience in programming since then. It helps having a baby face, too.
The problem that has happened at my company is that we take a "chance" on bootcampers or other people who aren't proven, we spend the time and effort to mentor and train them, pay them well, and then they turn around in 9-12 months and leave us for another company with their enhanced experience. It has happened 3 times so far, so we have stopped hiring bootcampers, and fresh grads and instead have started hiring people with a couple of years under their belts or more, since they appear to at least want to stick around enough to contribute positively to our teams.
How much does their pay increase after their first year?
I was a bootcamp grad and I stayed at my first company for 3 years because the pay was adjusted to roughly market value (actually a little bit lower, but not too much) every year. I worked with a lot of other bootcamp grads, that have stayed there for 2-5 years. Our turnover rate for grads was very low.
Right now there are bootcamp grads that got hired before me that are still working at that company.
It's true that most bootcamps tell their grads that they should look for a new job every 1-2 years, but if you want to hold on to them, you have to pay them at roughly the same level they would get elsewhere. That's how you get them to stay.
You can't expect them to just leave money sitting on the table.
Conversely, I found it really hard to establish myself as a solid contributor and even a technical leader when I joined a team as a (relatively) newly minted developer.
No matter how far I progressed, or how competent (even excellent) I became, I was still perceived as the "kid", even though my colleagues are only a few years older. I think I've mostly overcome this, but TBH I'm still not certain and I've been here for ~3.5 years in this role, and have been promoted to senior developer. None of that matters to my coworkers.
Moving teams is a much easier way to shed that "newbie" reputation (a path I decided not to take). Is it possible someone is creating this culture at your work that locks people into their role when they join the team?
> Two managers are talking about training their employees. The first asks, "Yeah, but what if we train them, and they just leave?" The second responds, "What if we don't train them, and they stay?"
This is me. I graduated last year and work at a small consulting shop doing web apps. I'm currently interviewing and getting offers from more established companies. This is the first time I've felt bad about leaving a company after one year. My coworkers are awesome. But the benefits suck, the clients are a nightmare, pay isn't great. I feel like I would be a fool to stay.
Look out for yourself. If they can't bump your pay now, even without knowing the situation, I doubt they can in 6 months either. They also probably wouldn't hesitate to lay you off if they couldn't pay you what you make now.
Big companies deal with this too. The solution is golden handcuffs - create a vesting or well-defined bonus schedule that incentivizes them to stick around. At the very least, offer them a signing bonus that they have to return if they leave of their own volition in less than a year
It sounds like they don't have enough incentive to stay? I know some others have mentioned financial incentive, but really enjoying the work you're doing and the people you work with may be even more important.
This is my experience exactly, and I am starting to get a sense of this mentality after my girlfriend went through a bootcamp. As a CS graduate myself I had several years to get a sense of what the industry looks like and what part of the industry I would be most satisfied working in (startups). Bootcamp graduates have less time to define their personal goals and industry view, so they are more prepared to give up equity and learning experiences for the opportunity to say "I work at [insert big tech company here]".
Haha, that’s true. Those first few years are really valuable. I’ll happily hire from twenty companies’ just-no-longer-junior hires than from fresh grads. Those guys will bring twenty new perspectives whereas the new grads will be riffs off their mentors here.
It’s really the best group to hire. And you can always pick them up after their first couple of vests and they’ve grown so much. Way better than training your own and take no lead time.
That is your fault for not making the right contract. If it is really important that they stick around for more than a year, it has to be in the contract, with penalties if they quit earlier.
Lately what I have been trying out is telling people: if you want to come for an interview can you prepare a small presentation of one of the data structures that you know
about or like, or ideally hash tables (as they cover wide range of topics).
If a person than comes in for the interview in about a week from when he is told this and can’t present that DS to some depth I don’t bother to go on with much longer interview.
I got lot of criticism for this ranging from who needs data structures, we are not building libraries to this is too complex to ask a person.
But in my opinion if someone tells you what you are going to be asked on the interview and you don’t even bother to prepare at least a little bit i can assume me you will act like that at work too.
Why a data structure? Why not, you don’t necessarily need to like or know anything about the domain you will be working in, same way you might not care or like data structures.
This doesn’t apply to someone writing HTML maybe but for a senior programer it should be easy to figure out how a simple linked list works, if you don’t care about learning it I don’t care about wasting my time interviewing you.
I would like if some of you might give me thoughts on this approach.
As someone who hates most interview processes as a candidate, I like this one quite a bit.
- it doesn't waste the candidate's time. If the candidate knows all about it: great! If they don't---it's never a bad time to learn/re-learn the fundamentals.
- it avoids the "gotcha" approach that tests for whether you know a specific thing, right now.
- it tests the candidate over time. Speaking as someone who used to rock interviews but did not perform as well over the long haul, I think this is an important distinction.
I will read the other comments with interest, but initially I say: bravo.
I like your approach. To be honest, after many years of work without touching low level algorithms I partially forgot many stuff I learned at Uni, especially data structures and sorting algorithms (I remember how they work, but I cannot tell you the complexity or write the code on the fly).
But if you tell me "look I'm going to ask you this and that at the interview" I can pick up 2 wikipedia articles and refresh my memory about that topic so I will be prepared.
Well to take a step back and evaluate the question of "who needs ds" - most answers to typical problems come down to using a hash table or an array... or some trickery of both. So... I can see this question as being useful.
I am afraid that I am missing the point of why YOU chose this approach if you can't answer this question. No offense to you. It seems like you came from the approach that if people want this job they will do this thing. Seems noble and with good intentions.
But DS is much more than that. It is the basics. The definition. The building blocks. Lots of reasons why you would want to ask about it.
I've actually been asked something similar prior to working at IBM. My caveat was that this question was asked in the interview without any preparation.
However, I can see how some people would find this challenging. It may seem like a lot of work for some people. Especially if you worked with some engineers that freak out when such a task is presented. If they don't have an outline, a set criteria, the protocols, previous samples, and the such. then you will have a bad time. Such people approach problems very systematically. As long as your task is clearly defined and has such things, then it should be easier in theory.
The people who aren't phased then won't be phased. The people that may see this as challenging shouldn't also be phased. Finally, considering monetary incentives for such additional work could smooth out some issues. You could pose such things as an investment and a risk mitigation strategy to your elders.
I interviewed one who had a lot of trouble finding the largest integer in an array... I mean, it really was a bozo-filter level problem, and it amazed me how many people couldn't do it.
Personally, I hate white-board interviews, but I'd be relieved (and yet annoyed at the same time) if you asked me to find the largest integer in an array.
Some of my friends work as devs at some bloated $BIG_CORPS for a few years and reached senior level. However, as they grew in seniority, their coding tasks more and more got replaced with management tasks where the coding was outsourced to developing countries or consultants to the point they almost forgot how to code.
Nearly happened to me as well, thank God I left that shit show in time.
Well, I'd assume you wouldn't want a presentation on something as trivial as a linked list, and try to study up on R-trees or some such thing. And with my luck, you'd end up being the world's foremost expert on R-trees...
I think it's fantastic. Good programmers take a data-centric approach, preparing a slide on a data structure of your choice is trivial. For HTML the equivalent might be CSS-oriented.
Why would any company have do hire people and train them? Companies these days don't really come to a hault if they're in need of a few developers, and as the market is saturated, they can hold out indefinitely until they believe they have a "rockstar."
According to my experience, a lot fewer companies than even a few years ago are in a hurry to talk to you despite them having a job posting and you having more experience. Most of them will take their sweet ass time, and it will take even longer if they've replaced their HR or their own recruiting process with a recruiting firm, and usually they'll engage in the same process of finding a "rockstar" while taking their time because then they can fit in time for another client and make more money.
Besides, the incentive for hiring the unproven developers is quickly dying off with services like Triplebyte that can test and interview developers for you for a nominal fee. Those who would normally be in charge of hiring at a company never gets to the point where they've interviewed a bunch of people and decides that they're tired of interviewing people and hires the candidate who seems the most intelligent.
> Companies these days don't really come to a hault if they're in need of a few developers
My small company has had to put our biggest contract on hold since July after having 2 senior developers leave in quick succession. We're burning through cash and have only just this week managed to find a replacement for one of them. I've almost gone down the agency route (again) but the fees are pretty hefty for a team our size (3 at the moment).
I'm not looking for rockstars, just someone with some familiarity with .NET MVC.
You can hire a consulting firm. There are some great ones and some not so great ones. If you are willing to work with remote developers, you can find some good ones.
Disclaimer: I work at one of what I would consider the "great" ones. No idea about UK work, though.
I feel your pain. Trying to hire perm in London at the moment is a real challenge, even with a recruiter. Contractor rates are obscene (5-8x perm). Recruiting and retaining is what keeps me awake at night over and above any tech issues that I'm working on.
YMMV but numbers of them! we offer good salary/benefits etc, but on the whole senior and mid-level devs seem to be contracting for our tech stack (React/Node) and that's a path I'm not particularly keen on going down.
edit: if anyone reads this and wants a job, I've put my email in my profile.
Hint: most of them are not contracting because they particularly like the contractor's life. They're contracting because they can be paid more. I think in London the reality is that, if your company is using a new and hot tech stack (say Spark or Kubernetes), then the contractor's rate IS the market salary, as most people how know this stuff are doing contracts. You can find them as full-timers with regular FT salary (60-90k GBP ?) too, but that's more of an exception and a lucky catch I guess. Also, once they figure out how easy it is for them to make more doing the same work, they might leave anyway.
Salaries not skyrocketing. Some companies in some areas are seeing modest compensation growth for software engineers, but if there was a true shortage of supply combined with steady demand, then salaries would be rising.
I'd be interested in hard data too, mostly because it seems absolutely true across multiple stacks. In my own experience, junior development salaries have dropped in the last decade and the number of people that apply for roles has increased significantly, to the point where at my last employer we had hundreds of people apply for a .NET role, and not just local people either - people were willing to move for what was a fairly bog-standard role at a bog-standard agency.
This might indeed be true in your slice of the market, but in top firms in USA I think new grad compensation has never been higher. Top students with good summer internship experience can easily bag 150k in their first year, even more for those who manage to time competing offers.
The situation of top students in top firms isn't necessarily representative of the market. You'd want to look at the compensation of the median student, or if you're including the top students, then look at the weak students, say, 20th percentile as well.
The interview process is getting longer than ever. For instance, getting a homework step before the in-person interview never used to be a thing. Now, it seems to have become commonplace.
Personally I really like Triplebyte. I'm 18 and have no professional experience other than a 3 month internship, but I was able to pass their quiz + interview and I got 3 interviews that I'm going to in a few weeks. If there wasn't some way to prove that I wasn't just a rando, then getting my foot in the door would be 10x harder.
I think tons of experienced people that love programming moved on because of the "Google Interview".
You got all this experience and love making stuff for users, but you don't know the "insert trick of the week" to solve the latest "elite" programming question. Bye Bye. No more jobs for you.
Asking people questions that only come up in college and not in the field is ageism plain and simple. They’re selecting for recent graduates.
Could be lots of reasons for that. They’re hungry, they don’t know what’s impossible (occasionally an asset, often a source of aggravation), or that they don’t know when to say no.
Google loved asking questions relating to the square-cube law. Like "you're shrunken down to the size of a dime and placed in a blender that's going to start in thirty seconds, what do you do?"
From what I gather, this is covered in required curriculum in schools like Berkeley, Stanford, MIT, etc. I've never heard of it in my life, and I was one of the top two in my CS graduating class.
IMO, this boils down to cultural bias, plain and simple. "We hire people just like us."
Those questions are no longer asked. Most questions these days come from sites like leetcode, hackerrank and other online judge sites.
These companies now specialize in creating online tests. Where in you will have to enter a working program, which takes input through stdin, and has to print output to stdout. There are typically a huge range of tests your program has to pass. Several of those tests are to check if your program completes in time. And yeah, you write the program in a stipulated period of time.
Most questions go along the lines of dynamic programming. Mostly because for other questions, there is often a solution you can come up with. But for DP ones there is often a 'unique trick' involved with nested loops. And other ones are often bit manipulation types, where you get strange and interesting results by doing some tricks.
So you have to learn all possible algorithms. Which means you have to spend hours everyday learning every new problem/solution posted on those forums. Apart from this you also need to good C++ skills. I often see solution submitters in Java and Python laugh in the comments, commenting how their solution is just a Java equivalent of the C++ code, but just won't complete in time for a test case to pass. That also means learning a lot of C++ important to go through these tests.
These days getting good at interviews is a full time job.
I often have this thought. If you are really good at interviews you should waste no time in a company, building stuff and writing software. Your whole life must be dedicated to finding the next best paying job.
Before this people (like Microsoft) used to ask riddles. Now, I'm pretty okay at and enjoy riddles, and ridiculously good at multiple choice tests. Bits of this come out in how I approach troubleshooting and debugging.
The last place I interviewed at that did riddles ended up offering me the job, but I teased them even before they asked their riddles about how it wasn't a good interview technique. I could kind of tell they were thinking "oh boy, another guy full of excuses for why he's not gonna pass the interview process". Second riddle, I started talking and had the answer within a single sentence. No pauses, no sentence fragments. Now I had their attention.
Since it was a rapidly growing company I was in the interview pool within three or four months and it took me maybe six months after that to convince all but one person to stop using riddles for interview questions.
Point is, if you disagree with an interview technique but can manage to get through that filter anyway, you owe it to the rest of us to say something. Apply some peer pressure whenever you can.
Pretty much! After repeatedly failing interviews for the past year, I've lost hope of having a "normal" dev job again. Studying for interviews took too much time away from things I'd rather be focusing on if I wasn't going to be employed.
I'm now trying to get a business off the ground in a field I've dabbled in for years (game dev), but there's no expectation it'll get me past minimum wage :/
Right. More and more experienced people are moving into indie / contracting on the side because you simply won't pass these interviews unless you spend ton's of time learning all the tricks.
Depends on the company I guess. Less known companies may either not use algorithmic puzzles at all, or have a lower bar (either the puzzles are easier or you don't need to ace them), just because they don't get to be as selective as Google. I once aced the puzzle coding interview in a well known late stage startup without doing much preparation (I was 10 years out of CS school at that time, so none of the algo stuff was too fresh in my head). The problems just were not that hard - you could simply figure them out with common sense and some basic algorithmic techniques.
Turns out that Google isn't the only outfit hiring coders. I could never have passed their interview but I've had a long career making a good living working for companies that never asked me to write a self-balancing binary search tree off the cuff.
I can speak about my last 5 jobs over 10 years. Before that, I stayed at one company way too long.
Job 1 - I had already been working at one company way too long. But I wasn’t asked any tough technical questions. I explained both my professional experience, and that I got my start as a hobbyist in 86 in 6th grade.
To be honest, with my programming experience I was overqualified for the job, but I wanted to get into .Net and away from C so I took a high level entry job as a .Net developer and it was basically a vertical salary move (wage compression is real).
2. I remember having a real simple written test that made sure I could write FizzBuzz, knew the basics of .Net and knew how to design and use databases. After that, I sat down and did pair programming with an IDE where I had to make failing unit tests pass. Again I was still punching below my weight class, but I was more concerned with learning than maximizing salary. It was a 10K bump and with a well known at the time Fortune 10 company.
3. Basic technical interview making sure I knew .Net, JavaScript and relational database theory. They asked a lot of questions about architecture and my “whiteboard interview” was drawing out a relatively complex, scalable system.
4. Slightly technical but the main question I remember is “tell me what steps are you going to take to create this software development department we need”. I was interviewing for a Dev lead position without knowing it.
5. “Here are some real world issues we are having with our architecture. We are on AWS. How are you going to solve them?”
Companies that consider themselves special generally "Google Interviews". That include bulk of the FAANG class companies, or any body who pays in the same ball park.
There are also a huge alumni of the FAANG club, who have a vested interested in doing "Google Interviews". Basically these people have spent so much time(thousands of hours) that the only way they can justify it is by making that interview process that way. Anybody who hasn't spent that kind of effort is obviously beneath their station.
But I hope you see where this is going.
>>Here are some real world issues we are having with our architecture. We are on AWS. How are you going to solve them
The "Google Interview" club likely won't ask you these questions. Their job isn't to build software. It is to get good at interviews, if you are good at interviews, interviewing is your day job, as practicing questions brings you a raise/promotion/title-change every year.
And that’s why I’ve never had any interest in the Silicon Valley/Startup culture.
I’m very happy in a major metropolitan area with a relatively low cost of living anf a good relative salary working as an “Enterprise developer/architect”.
I've had a long career making a good living working for companies that never asked me to write a self-balancing binary search tree off the cuff.
No one should be asking you to write a self balancing binary search tree off the cuff. One of the simplest would be a Splay tree, and even that's way too much.
More relevant would be to ask for 3 or so things each of which are 1/10th the complexity, but then see if you can specify how to integrate those things together into a system in a way that shows you have experience with the pitfalls of actual coding and debugging.
I think some of the fellows at Google are still some of the best people to look up to but not new grad CS majors they know as much as you do about engineering
I have run into some of these issues in the past when trying to get into software.
I'm a chemical engineer / scientist with some programming experience/skill* but I would suck at modern coding interviews because I don't program regularly in my past 3-4 roles. I would have to get up to speed on the job, with pre-prep before the job started, and I could develop into an awesome programmer. Most job posting are written such that I am 99% certain my resume would just be a 'fast pass' in the 10 seconds a recruiter might look at it. Oh well, engineering is pretty interesting too... so I really can't complain much.
*My programming experience and background:
-- wrote Python/PyQt apps for parsing/analyzing/visualizing semiconductor device data, wrote sensor simulators/analysis tools in MATLAB and Python. Wrote image analysis routines in Java/ImageJ. I taught myself the languages and libraries and wrote correct and performant code.
I dabble in Python, JS, Julia, Rust, C++, various LISP's at home but I don't have a lot of time or energy after 8-10 hours a day of engineering work.
I have done a fair amount of PLC programming and control system design in the past. I also have 10+ years of post PhD engineering and physical science in several different fields and all of the capability and skill sets required to be successful in those fields.
Software gigs I have applied for in past generally have not even given me the time of day... oh well.
I think this is good advice... for larger companies with well established patterns. One of the issues of a startup is that the founders are breathing down your neck and often don't care a whole lot about "well designed software" (or want to overbuild mvp products). Standing up to management, building best practices, and being agile while still pushing back when needed against founders/sales isn't easy but it's something engineers in a startup environment have to deal with directly constantly.
A larger company has more layers of management to, hopefully, help filter that out. Larger companies have best practices written down and figured out, CI/CD pipelines in place, etc. It gives newer engineers more opportunity to succeed in areas where they are strong, while letting them have mentorship in areas they are new to them.
> It gives newer engineers more opportunity to succeed in areas where they are strong
or just gives people who can fit a mould succeed, but doesn't allow someone who is creative and can think outside the box to shine as existing beaurocracy bogs down the smallest of change.
One of the hardest challenges of being an engineer, especially at senior levels, is protecting your peers from bureaucracy - but it is a doable challenge. A corporate structure is like any other social structure and it can be navigated and changed over time with persistent work and buy in from the bottom up.
That being said, larger corporations do have more structure because they don't want you to repeat the mistakes of the past. That can obviously go too far, but if any constraint becomes "You're limiting my creative expression!" then you've missed the goal.
I find most corporate structures, levels of management and reporting requirements (that aren't legislation based) all stem from the fact that the "boss" can't trust the lower level guy to do their job and make decisions without consulting someone higher on the hierarchy.
In a small startup, this isn't a problem, because decision making happens immediately. In a large corp, you end up with bureaucracy this way.
How does other organizations that are large solve this problem? In the millitary (at least, in the US, and other western doctrine millitaries), the sqad or captain or ground level troop has a lot of freedom to make tactical decisions, as long as that decision is to move towards the goal (or what's normally called the commander's intent). Why doesn't this method work in a corp. environment?
It works where there is a shared mission. But when team A wants help with project 1 and team B’s priority is project 2, and they need approval from team C because it touches their code, well, you get the bureaucracy and constant escalation that you see in big software companies.
>Don't hire like FAANG companies, don't use their best practices, don't use their super oiled processes, don't play their same games with the same rules.
I'm back on the job market for the first time in 4 years and it seems like things have changed a lot. I'm now stuck in this weird twilight zone where every single company I talk to has the exact same process that they run through the motions as if it were dictated from somewhere, and I've yet to even have a genuine conversation. It inevitably leads to a "live coding" session over the phone where I completely go blank and am unable to perform because programming under a time constraint with someone staring at your screen is absurd. Problems on the level of fizzbuzz become impossible because my mind simply goes blank in those situations and I freeze up. It'd be nice if someone would just give me a take home project where I can actually code something properly and show off my skills, rather than conclude that I'm an idiot who can't even code after 20 minutes of struggling with some toy problem through my intense anxiety.
I understand the blank mind feeling. I was on a phone interview with Oculus 2 weeks ago and had a simple circular buffer question. I was expecting something a lot harder, frankly, and hadn't practiced writing a circular buffer in a while. I was doing fine until I got half-way through and wanted to refactor my code. Since we're under time constraints I tried to push through and use my existing design choice but it started the anxiety train rolling. In a couple minutes my mind fogged over and I literally couldn't comprehend the code I had written a few minutes ago. The interview ended poorly and I didn't get the job. I finished the code after the interview, along with some test cases, and the whole thing worked great. It wasn't that I didn't understand the problem, I just couldn't implement it with someone breathing down my neck.
I interviewed with Nvidia a week later and almost had a similar issue but in that case the interviewer sensed my reaction and managed to talk me through things. I managed to recover and now I'm scheduled for an on-site.
Passion can't be measured with credentials so why do companies keep screening for them?
I spent the last three years studying as a hobby and as a full time student learning multiple frameworks, front-end and backend, and additional technologies that made me curious like Vim and I can't even land a single technical interview.
After coming to the Bay Area, I was thinking my github portfolio and communication and networking skills would at least get me in the door to prove myself.
Once coming I found out I would need to learn CS topics to get past the technical interview and that React would be a good entry point for a first job. So I left and studied another 6 months before returning. The second time I got a part time job as a coding instructor at a bootcamp because I have a history in teaching, but still struggle to get in the door for engineering interviews.
Nobody takes me seriously without credentials, I always thought that in a technical interview people would be able to figure out where you stand and not need credentials. The problem is companies get flooded with resumes so they build automated software to screen the best candidates but passion can't be screened.
At Origin, we've hired multiple people without computer science degrees and whose resumes you would never pick out of a stack. One of our key players, for example, was a commercial real estate broker who taught himself how to code. The reason we hired him is that we're a 100% open-source project and he just started contributing. And he turned out to be really great. By the time we gave him a fulltime offer, he'd had several months to demonstrate what he could do. For anyone who is struggling with not having the right background or degree, find an open-source project and start contributing. It's a great way to prove yourself and you'll learn new skills and make awesome new connections along the way.
That makes sense. It's also how I look at hiring. People who have made good contributions to our codebase (arvados.org) are first in line.
Being able to look past the resume and pick up good people who don't fit a traditional pattern is definitely a skill. Business people tend to not understand this because they are stuck on matching patterns. In other words, don't let non-technical people be in charge of hiring developers :)
I get the sentiment but I have two problems with this.
1) Different stages of companies require different hires. When you're starting out, find the hungry ones. They'll get better at programming if they care, and they'll build a lot of stuff. Once you have real customers and are growing like crazy, hire experienced people to help you scale.
2) There is a difference between the "interview process" and the screening process. I agree that thinking about "Can this candidate do the job?" and "Will this candidate be motivated?" is the best way to go. But I don't have time to sit down with the ~200 junior engineers who sent me their resume on Indeed in order to figure that out. Hence, I filter by 5+ years of experience, and track record of working in multiple programming languages (don't screen specific languages though). Are the metrics perfect? No. But in my experience they weed out the people who are too junior to be successful on my team.
Interestingly, I think that if my company were bigger we might go back the other direction. Once we're on a stable path, and we have a few senior engineers who want to go into management and/or do some mentorship, we can afford to bring on more junior people and help them grow into great engineers.
There are many stages of companies, startups especially, and in some situations it makes perfect sense to use some plain old metrics.
"Years of experience" is a very misleading metric. Someone could have 2 years of experience but be more motivated and/or have worked in a more demanding environment than someone with 5 years of experience.
Of course not. But finding talent is far more subtle than "how many years has this person been in industry?" That doesn't account for passion, motivation, how much they learned and accomplished on the job, etc.
I don't see how 'hire people who aren't proven' can be compatible with 'can this candidate do the job'. You want to know if they can do the job, but you aren't interested in any proof for that?
> If they have a proven track record of figuring things out experience is minimally valuable.
I can't understand this point of view at all.
When Google wanted to build the world's best JS JIT they didn't hire anyone who was generally able to figure things out - they hired the person with the most experience in building dynamic language JITs in the world. Experience is everything! Experience is knowing which rabbit holes to not go down, knowing who to speak to when you need help, what ideas haven't been tried yet, etc.
I think it's totally unrealistic to compare the average coding gig with writing a custom JIT from scratch for Google. In most businesses the difference between 'very good' and 'world class' won't have a large enough impact to spend the extra resources getting that rockstar.
And then there is the issue of actually retaining top talent...
That is only true if you see the list of things a person can learn how to do as a closed set. For instance, I really disliked maths in school. I've avoided every software job posting that involved any maths (3D, statistics, etc). However, if I was given a job offer to work on a math-related product I deeply connected with, and that I felt I wanted to contribute, I'd probably be more interested in learning the math stuff I dumped from my brain years ago. I'm convinced this applies to most people in this industry.
I think the issue we have nowadays is that most software companies are creating mediocre to shitty software that solves no real problem, but selling themselves as the next Google or Apple. Most engineers can see through the bullshit and thus don't feel connected to the product. Then it just becomes a contest for who can realistically write the code for the shitty product for the least pay.
You're suggesting companies build teams of amateurs with the hope that they can all pick up the skills amongst themselves as they go.
If you have to for example build a new operating system kernel, or a new compiler, or implement a machine learning system, hiring a bunch of well-intentioned smart people with the vague idea that they can probably figure it out as they go is a bad idea. You sometimes need someone with a track record of being able to do the work you need done.
That someone didn't come fully formed and ready for OS development out of the womb. It's a good argument for looking at track record when hiring for senior positions though.
I've been interested in many fields, but can't afford to take time to establish myself in them unless there is also significant interest from a company looking to hire me.
You could, instead of relying on a resume to determine if someone can do X, ask them to do some X instead of an interview, and then use an objective rubric to decide if they did X to some level of satisfaction.
This is called work sample testing and it works great.
I think that only works for the most trivial things.
You can do a work sample test for 'can this person add a view to a Rails app', but not for example for 'can this person build a team and develop a solution to a complex technical problem in a specific domain'.
Matasano used to bet the farm on it, I did it at my last job, and Latacora's doing it again. I don't think what those companies do is trivial. (Disclaimer: I'm a Principal at Latacora.)
In my experience, when you think you can't measure a thing in a work-sample setting, it means you haven't analyzed it. And, if you have no idea what that thing means, how could you possibly hope to interview for it?
For example: "can this person build a team and develop a solution to a complex technical solution" (that's several things, but OK, let's take a stab at it):
- Someone who can build a solution in a specific domain has to be able to analyze the problem into bite-size pieces. Given a complex problem description, write out tickets that need to get done. Can they identify sensible milestones, objectives and key results? Are the tickets roughly equally sized? Are the tickets self-contained? Do they come with an objective measure of "done"?
- Someone who can build a team to deliver a solution has to be able to estimate appropriate resourcing for a project. Given a complex problem description and a current set of resources, come up with a plan forward. Measurements include: a) Did they identify missing roles? b) Did they write clear job reqs with evaluation and hiring plans? A gazillion hiring managers couldn't write a clear job req to save their lives. c) Did they consider which positions may be effectively contracted out? d) Can they estimate what the P&L impact of this hiring plan is? Knowing how to read P&Ls and cost of development is a skill. e) Can they identify within their own plan which roles are really critical and which ones are nice-to-have? Being able to negotiate in the face of limited resources is a skill.
- Someone who can lead a team to deliver a solution to a complex problem has to be able to analyze when things go awry on a low-level. Put them in front of a PR where someone has subtly misunderstood a poorly-written ticket. Give them the context they need to understand why the PR is wrong. See how they tell people the PR is wrong, and how they react when people persist?
- Put them in a position where they have to talk to an employee who isn't doing well. Can they figure out how to be empathic while remaining professional? Did they say something that will get you sued? Opposite situation: put them in a room with a rockstar developer who's been harassing or badgering one of your employees. Can they speak to that person professional? Can they write an HR file note with a follow-up plan?
On the contrary, it works for substantial jobs. I used it for hiring security engineers with great success. I then used it for project manager and manager of compliance, and it worked with astonishing success. In particular, the compliance manager job is _mostly_ about getting results from people across the organization that do not report to them.
Folks have built highly specialized company teams with this and little or no interviews.
There's a critical kernel of truth here that I want to point out: work-sample tests. The longer I spend building teams, the more I am convinced: there are people who do WSTs as a way to qualify applicants, and there are people who just aren't serious about hiring.
It's easy to write a WST for simple things, like "can you literally write a computer program that does this trivial straightforward thing". It's hard to write WSTs for things that feel fluffy, like "can you manage a team". But here's the thing: as long as that fluffy thing feels fluffy, what that really means is you haven't bothered to figure out what success looks like for that role, and you couldn't even evaluate that person let alone hire for them.
There's a company in Indy called Woven (http://www.woventeams.com/) that'll do it for you, too. I have no relationship with them other than that they're nice people who are trying to unfuck hiring.
It would be great if you could convince large tech companies to use work sample tests, but I just don't see that happening. So in that sense maybe work sample tests can be a differentiator attracting candidates that don't want to spend a few weeks doing Leetcode prep every time they look for a new job.
On the other hand work sample tests also have drawbacks. I don't know if they're actually that much better than regular interviewing methods; I think they just contribute an orthogonal signal instead of a stronger one. I don't feel I can cheerlead them as much as you do in your first paragraph.
I think in an ideal world companies would allow candidates the option of choosing either their work sample or their resume-blind, standardized interview gauntlet. People with a lot of interviewing anxiety could self-elect a work sample option. But if you impose a work sample on every candidate I think you'll reduce your pool of available hires.
I was offered a work sample test recently and was told to spend about a week on it. I started working on it a little bit the first day and really enjoyed the exercise. But I was also interviewing with at least five other companies at the same time; I simply didn't have the time between work and traveling for onsites to really commit to the work sample.
genuine and continuous interest in the particular
field
+ all the other soft-skills (team work, work ethics, respect for others, etc).
But I think to enable long term, mutual benefit between the business and employees, the business must be able to place itself, virtually, in the position of employee.
And ask: in addition to salary, why would the employee continue with me?
I feel that aspect is rarely discussed, written about.
I made some mistakes in my personal career development.
And the most significant ones where due to me believing that the companies (senior managers) I work for, actually cared about my aspirations.
So, for myself, I had adapted this career management strategy, that I picked from lawyers:
Basically, I would not stay in one company for more than 3 (max 5 years), if I do not make meaningful incremental career growth (that also includes compensation growth).
Following that, even though late in my career, helped me to get recognition, better relations in the industry, as well as better monetary compensation.
I'd add the caution that you should have clear criteria for what represents success in the job, and the timeline. If the candidate doesn't meet those criteria in that timeline, you both should agree that it isn't working.
My previous job was running a small Sys Admin consulting company. We hired 4 people over the years who definitely fit into the "not proven" category, with very mixed results.
Two really struggled: One of them was "ok" but needed a ton of management, the other never really got a basic level of proficiency despite spending most of a year "studying" and working at the elbow of various masters. One worked out really well and was a great worker. I feel like there was another one, but I can't dredge up the specifics.
The proven people on the other hand were mostly rockstars. The one that wasn't was largely due to my mismanagement of them.
So: Yes, absolutely hire the unproven. But have a plan.
At a startup, we interviewed purely for being able to d x task in Angular, Entity Framework, MongoDB, C#, and other components of our tech stack.
It worked out well for us - we just needed a website built.
The company I work for now interviews only on the fundamentals and problem solving in language of choice - I am starting to come around and see the benefit of this, but it seems it only makes sense with senior candidates who context-switch a lot and need to intrinsically understand GraphQL the moment they hear about it because they know it's a graph.
Agreed. We gave up on technical interviews and now offer a paid project. Something in the 5-15 hour range that provides an opportunity for the candidate to show their skill in the areas that we'll actually have them working - usually something from the 'features' list. We pay a reasonable hourly rate for the work because they're worth it. And if we decide their pull request is good enough to merge, we'll send them a job offer.
It's good that you're willing to pay I don't think 5+ hours is necessary. It's perfectly possible to squeeze a realistic set of tasks in to one hour I think (it just takes a bit of work).
completely agree. It's been done to me (at Google), and I'm guilty of this myself. I tend to ask a bunch of obscure questions about topics that ultimately have nothing to do with the daily job. I gloss over the banality of what they'll actually do (push data in and out of databases.. ), in favor of javascript scope, map/reduce esoterica, C pointer arithmetic, blah blah.. shit that I know. It's kinda stupid.
As someone who is currently looking for a job I can definitely relate to the troubling HR in software field. What I started doing is working on my own content to help recruiters decide if I am what they are looking for. I added more information about ME, what I am passionate about, what I was passionate about previously, and what I am looking for to my about page (https://getaclue.me/about).
This way, recruiters can decide if they like me or not. Another thing I started doing while reaching out to companies is saying that I am open to 3-6 months "tryouts" if you wish.
I feel like we should have more of those. I also realized that social media is very powerful for finding your way in 2018. Gone are the days of wanting to work at a Fortune N company because they are doing great work. Most of those unicorns turn into corp machines that they were trying to stay away from.
Another thing I started doing is looking for people that share my passion. Anecdotally, Forums, IRCs, Telegam and the such communities are definitely booming once again thanks to the dissolution of privacy.
One challenge - esp if you are someone who cares about software and software engineering field - you have to do A LOT more work on your own. I work full-time and I work when I get home. I don't see this changing.
I find this is incompatible with the list of 4 questions:
> Cut luck out of your system.
You can't decide to do that. If you're a small company, you are only sampling a little bit and luck will either help you or hurt you. If you are large, the law of large numbers will give you something like the average. You can't decide if you're small or large.
As for finding people who are proven, it's up to you what level you are after. If you want anyone who'd played division 3 football, you have a reasonably large number of candidates. If you have a left back who's played Champions League and is under 25, you have a small number of candidates.
Try to go with larger sets, because then the LLN will help you. Don't ask for anyone who's played any sport for your football team, just anyone who has played football to the level you need.
Another important thing to think about is how to work with the great mass of ordinary people. At some stage if things go well, you may have to engage with people who are not wanting to spend 80 hours at your office, or who don't spend their weekends contributing to exactly the projects your firm is interested in, and who maybe aren't even all that interested in what you do. Motivating such teams has been a major value-add for a large number of household names.
My initial interest in programming started before 1990. Due to an insane number and variety of mostly personal factors, the farthest I ever got was a couple ancient javascript/HTML experiments, a few small-to-medium side projects in MS Access and some intermediate router configuration. I've primarily just done tech support. I've performed well in the jobs I've chosen, though, because I get along well with others and tend to be loyal to the organization, even if I know this is sometimes foolish. It's simply how I'm wired.
Despite all the time that's passed and all the things I've dipped my toes into, I feel no closer to choosing a language, framework or tooling. I have no friends who are serious developers. I'm good at learning new things, but it happens slowly. It would probably take me 6 months to a year of dedicated daily time & effort just to ramp up on any one particular sub-technology (which, considering that I'm a rideshare driver to make ends meet, is a challenge)-- and there is no guarantee it would help me find work, since I have no idea who's hiring for what, or what those jobs are actually like.
All that being said, other than 'professional entertainer' (haha), a software developer is all I've really ever wanted to be, and I think with enough time invested the right way, I'd be really, really good at some aspect of it. I built myself a custom checking account database to better predict its future balance, and I'm happy every time I interact with it (except when it crashes for reasons unrelated to my code). The biggest question of all remains, though: Is it even worth the trouble to try, because would anybody even consider hiring someone like me?
The best place to learn is when you're hired as a software developer at a company. It doesn't matter if the company is good or not, you'll be forced to learn to make the product work. Change a few jobs and some years of tinkering and you'll likely get the fads, buzz, experience, etc.. Best place to start is as junior dev and quickly move up. Learning at home will never give you work experience since the 'real world' environment is not replicable at home.
This advice seems kind of crazy to me. I think you want someone who is proven in some skill-set, just not necessarily the exact one you are hiring for [1]. In software engineering, many skills are easily picked up. If you know C++, Java probably won't be too hard to learn. Angular and React aren't all that different. Even backend and frontend development have a lot of overlap.
Many companies want experienced and proven hires and I think this is completely reasonable. If you can afford it, would you rather have Lebron James on your team or a rookie who shows some promise? However, I take issue when companies get too specific in their requirements and exclude candidates for not possessing skills that are easily learned by someone who is proven in other areas.
[1] The exception might be junior developers who you are taking more of a risk on, but also get paid less as a result. However, there are costs to training a junior developer including paying a salary while they get up to speed and using up experienced devs' time to train them.
As an unproven, but extremely passionate and motivated person (who is literally 2 hours away from going into his first Software Developer interview), I found this calming. If I don't get this position I really hope I find a company with the same ideals portrayed in this article.
As a dev straight out of university this blog resonates with me. I know I don't even come close in knowledge to a senior dev so in interviews I try to emphasis that I have a hard working personality, positive attitude, strong desire to learn, etc. Traits I think a company would really want if a dev was lacking in the specific skills. Sadly it feels like it always falls flat and I end up coming across as naive.
I think mainly the problem is rooted in employers cynical approach to hiring employees. It's hard to evaluate people on less measurable data points when you don't trust them. It's easier to trust tests with easily quantifiable results rather than those with grey areas.
The problem is that those things can be faked during an classic interview by a good actor (or "salesperson"). It's much harder to fake problem solving skills on a whiteboard.
The pair programming approach is not terrible, but might be problematic if skill fields (technologies, environment) of interviewer and candidate are not perfectly aligned. So either the candidate will have to work in the company's setup they're not familiar with, or the interviewer will try to follow something they don't easily understand.
One of my filters when phone screening is to ask simple questions that the candidate should know given the stated experience. I try to use topics that will separate out someone who's "faking it" versus someone who has the deep (or shallow) knowledge that someone with XX years experience should know.
For example, (back when ARC was new,) I'd ask someone with 5-8 years objective C to explain how autorelease works. (If you programmed in Objective C without ARC and didn't know about Autorelease...)
Or, for Java and C# I ask some questions about exception handling. It's a very simple concept that a lot of novices screw up. (If someone with a nontrivial amount of C# or Java can't explain some exception handling basics...)
(Basically, my pattern is to get the candidate to discuss some well-known details about memory management or error handling in a language that the candidate states experience in. Any competent programmer should be able to do this.)
I then ask some more theoretical questions that are relevant for the kind of programming needed for the product. These are the kinds of things that someone who has the experience needed should know without thinking too hard about the question. If someone can answer with a lot of hemming and hawwing, that's okay too. Someone who just can't discuss this kind of theory really isn't capable of the job... Or learning the job.
Sometimes it feels that even being "proven" isn't enough for a lot of companies that expect you to happen to know the six programming languages they put in their job ad, because if the ones you do know don't match up the recruiters will assume you're not a good fit regardless of your years of experience.
I do agree though that YMMV, and some companies are better than this and accept that you might be capable of picking up new languages and technologies.
For what it's worth, I work at one of the large tech companies mentioned. I would disagree with some of the characterization. For example "Don't do whiteboard coding on riddles or puzzles" - I think this is great advice, because questions like that are frowned on where I work too! Generally, the coding questions we ask come from real world applications.
I've also worked at a startup, and I think this article misses something that really could be helpful: there are different skills needed to work at most large companies and most start-ups. At most early-stage start-ups, scaling is not a problem. There are examples of companies that had to scale quickly, but for the most part life at a startup is about finding where your market is. I think that start-up hires also need to be more flexible: there's more room for specialization in larger companies, whereas in smaller companies, engineers that focus on one or two things can be pretty disruptive as the needed work shifts.
I feel like I tend to value theory more than most people, and when I interview, I tend to ask extremely theory-heavy questions that I think are typically pretty difficult.
However, I don't usually care if they can actually work out the answer in a short amount of time, as anyone can probably find an answer to a question in about fifteen seconds on pretty much any search engine. What I measure is how well the person asks questions.
The way I figure it, it's far more important that the worker is good about unblocking themselves; you can't expect someone to have memorized every algorithm ever, but it's not unreasonable to expect them to bother someone who knows a bit more about the subject when they don't.
Just as an FYI, I don't have any fancy credentials, or really any qualifications at all, so it's not like I'm pushing some kind of MIT/Harvard/Berkley ridiculous agenda onto people.
I am very skilled, highly educated, and interview poorly. When companies hire me, I get big promotions, leadership pulls me in, etc. This is because I'm not "an engineer" or "a programmer." The departments I work in obviously know/recognize me but the business doesn't know the job function really, its starting to be a more recognized area. The fact that I got as far as I did is hilarious, and I know how to find a lot more people like me at any time, and they'd never have gotten any of that value without hiring people like me. I also don't know how you would discern a "fake" me from me, without some of us on the interview. My interview was conducted by some highly qualified people and a few not qualified people, so I knew I had room to grow because there was a lot of dead weight.
It’s a great sentiment and I would love to hear this blog poster’s success with his system that he described. Does he have actual metrics as to how effective his description is, or is this just another example of someone on the Internet making an edict with no data backing it?
I recommend "Why Employees Are Always a Bad Idea" by Chuck Blakeman. It describes how to build a company where everyone is a stakeholder and not a child that needs constanct watching and stupid rules in order to function. No titles, no working hours, unlimited vacation time, you hire the whole person (not just the BS smile at work part). You work together because you want to find and make meaning. No CVs and skills are far less important than personality and fit (skills can always be learned).
The book is the reason I'm building my own company because this is how I want to work and live (I used to work for a company like that, but unfortunately, due to personal circumstances the founder had to split and the company disappeared).
Having hired folks who weren't proven, most didn't work out. However, the ones who did work out were great.
One difference that stood out beyond courage and attitude is how engaged in actualizing one's potential the candidate is.
Everyone has potential. The person doing the hiring may see it. The candidate may, or may not.
The only thing that mattered in the end was the candidates ability to actualize their own potential beyond what they may see in themselves, given an opportunity.
The questions "What do you build/work on when no one is looking" is one interesting question to elicit a sense of their attitude towards their potential, and if they have the courage to undertake building/learning something for the sake of learning.
You have to kiss a lot of frogs to find the prince this way. It can be very time consuming. If your company has more time than money - it's a reasonable strategy.
Agreed on kissing a lot of frogs. I wasn't recommending it, or not, just what one experience was. Over time, it's less useful, but it's important to still remain as open as possible.
>We’re looking for a person with more than 100 years of experience in software development, coding everything from BIOSes to cloud applications, knowledge of all past, present and future operating systems and setting up secure networks. The applicant must also be able to juggle up to twenty balls and read hieroglyphs, be fluent in Swahili and dance like Michael Jackson (especially moonwalking – nice to have at corporate Christmas parties).
Applicants in general I feel are always to be on a disadvantage because most companies leave the hiring to the HR Department, who have very little clue on what they need to actually be looking. Most of the time, they would have a checklist, where if the person does not meet enough of their threshold, that person is immediately passed off for the next applicant.
Add the process that some folks do to screen candidates - lots of times, these are not objective in nature and tend to skew towards most applicants who seem to have a very impressive profile made up of fancy words and half truths.
I dunno, I tried to hire based on potential, and I just let them go after six months of him failing to grasp even the basics of the job. He did fine in the interviews but ultimately you cannot fake experience.
We've hired multiple people based on potential. A few of them have worked out astoundingly well. More than that have quit or been let go for not being able to handle the job.
It's pretty demoralizing to let someone go. It's pretty annoying to have them quit in the first week. (Or even the first day!)
But it's pretty awesome when they work out and you get to watch their skill grow over time.
I worked for a company that did some layoffs of some good people. They're capable, but their bullet points don't match many jobs .... so they're looking for and endlessly long time.
These are great people more than capable of learning. At their previous jobs as a team they did more work than teams 3x their size.
I know a few places that turned them down in favor of folks who matched the bullet points... but not the job.
It's difficult to watch as I see news of places "desperate to find workers"... but refusing to hire good people.
Just like NoSQL 6 or 7 years ago. Some of us could see that relational databases were a far better fit for the vast majority of problems out there. A couple of years later we got all the Mongo horror stories and "why we switched back to Postgres" articles.
There is way too much tech to learn these days. I'll wait until I have a specific use case, benchmark techs then choose something.
It doesn't, obviously. My point was about how companies advertise jobs. A company advertising a job with a requirement of 10 years experience in a technology wants someone who's able to tackle pretty much any problem from the outset. They're not open to people learning.
A major GPS navigation company hired me for a job I wasn't ready for in 2006 when I was 24 years old. It was my first job at a big company.
I'm pretty sure I got through because they were growing way too fast and I slipped through the process somehow.
Being dropped into the deep end and surrounded by smart and experienced people was incredible for me. It took me a while to get up-to-speed but when I did I'm sure I more than repaid their investment.
More than anything have learned that education and training are hugely important and hiring to train leads to mediocre staff who think their two years of development work stack up to your 4 years of college and 6 years of professional experience.
They take forever to start writing productive code, if they ever bother leaning at all.
I will never hire someone without a degree or equivalent experience again. Even for Jr. roles
This strategy may weed out duds, but it will also occasionally overlook great people. One of the brightest engineers I know dropped out of high school and got a GED, but was obsessed with tech and practiced building things daily. He's 30 and a VP now.
This feels a bit like a strawman. I've interviewed with FAANG companies and I run interviews and I don't see these puzzle questions. I see people looking for basics and looking into problem solving and hints that candidates have done good work before. Granted, I've seen that urge to ask puzzle questions in some quarters, but I've regularly seen that ignored. Maybe though I've been blessed..
So, with this in mind, can any more experienced professionals say how you can stand out as an 'unproven' new grad/dev?
I've got work experience that isn't a tech internship (network support at a major uni), and code projects, but without that internship (I did research instead), it seems I and people like me are constantly at a disadvantage.
I work for a FAANG, and we don't hire like that either. The motto is often "hire for potential, not track record".
The dark pattern lurking in that is age discrimination: A motto like this can easily be taken as an excuse to completely dismiss track record, or even consider it detrimental.
Nice post, I think it can be more difficult for less-experienced (but talented) people to find jobs than it should be. However in some ways the FAANG companies are better in this regard since they hire many people out of college and strive to have an objective hiring process that can be passed by less experienced people.
There are good tidbits in that post, but the way you measure "smart" is awful and almost entirely subjective. The conversation "just flows"? Really? Gee, I wonder if that's likely to make you hire people who have the same background as you.
I agree that the "gets things done" part is important! But I think you should measure if they can, in a controlled environment, instead of just going off the resume and seeing if it has worked out in the past. Lots of total dipshits manage to ride on the coattails of successful teams.
Seems to me that at some point hiring moved away from hiring based on potential to hiring based on pure skill and how many boxes the candidate has checked. Companies seem to just want people who can turn the crank, which doesn't sound all that appealing.
The author hits on a lot of great points here, that I believe speak to a larger theme: there's a ton of undervalued programming talent out there and finding that talent can give your company a huge leg-up on the market.
I think the manhole covers are round because they're really heavy and it'd probably be tedious to orient a square or any shape with multiple sides to match up perfectly every time you put them back on.
Don't forget, FAANG are looking for minions that fit the assembly line in 99% of cases. Not original thinkers or people who are multi-talented, wearing many hats.
What amuses me more than anything else is that this dystopia was created by software developers. Oh everyone is going to a bootcamp and saturating the dev job market? Maybe you shouldn't have "disintermediated" every possible job from accountant to truck driver. What's good for the goose is good for the gander.
I find it much easier to deal with someone who has no relevant experience but cares vs someone who had 10 years experience but doesn't care. Now someone who has 10 years AND cares is rare but pure gold.