Hire people who aren’t proven
leonardofed.io
leonardofed.io
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.
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.
Have you had a part in writing Office Space [0] screenplay? It's Milton's wish.
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.
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.
yes. and, if I were to pursue a job with such a description, I'd have only myself to blame when the insane conditions started.
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.
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 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.”
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.
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.
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.
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.
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.
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.
Good to hear. The next dev, manager, owner on the team is not likely to be as conscientious however.
Once information is collected it is rarely deleted, so trust in random third parties is still not wise.
I don't think most older ecosystems were any better. For example Unix is a cobbled together mess. Autotools is a terrible mess of a build system, etc.
Big "professional" ecosystems aren't much better either. Just look at all the jokes like "fizzbuzz enterprise edition".
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?
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.
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.
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.
(In STEM. Obviously you presumably don't apply to Juilliard because you decided you might want to give this music thing a try.)
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.
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.
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.
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?).
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.
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.
I think it is a shortsighted strategy, but not one without basis. The supply problem is real.
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.
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.
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.
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.
Come on, you can't leave us hanging like this... What happened there? :)
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".
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.
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, ...).
Wants to stay competitive and be able to earn near the top of local market => interest => knowledge.
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 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.
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.
* 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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?
Nobody is telling their kids to become a doctor by reading aimlessly about medicine.
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.
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.
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.
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.
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.)
Eventually became a GP (family doctor) in Georgia
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.
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.
You can't even become good at flipping burgers without being interested in doing it.
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
But, hey, if you want to buy the hype, go for it.
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.
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.
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.
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.
> The NTSB...
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.
* 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.
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.
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.
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.
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 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.
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.
Finally, the topic of burnout and physician abuse (lack of sleep, working overtime and being on call), is truly disgusting. This was a tough read, previously posted on HN: https://ericlevi.com/2017/05/13/the-dark-side-of-doctoring/
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.
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?
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.
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.
And then you go home while they stay behind on call...
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.
Sorry that was kind of a rant.
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.
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.
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.
Those people certainly exist, so this just sounds like a bias on your part.
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.
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.
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.
Lately I have been thinking that passion is something learned.
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.
-- one word: QUALITY
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.
"
Just to be clear: That's not what I meant with "caring".
Passion is nice, but as author above I'd prefer to have a person who cares about what they're doing over just a passionate person.
Unfortunately to find a "caring" person is even harder than to find a passionate person.
This just makes the same kind of mistakes that the article is saying to avoid.
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.
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.
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?
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 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.
Probably a lot less. Exercise is associated with better mental acuity and reduced risk of mental deterioration with age[1].
Edit: Oh, and if you instead trade sleep for learning you're shooting yourself in the foot as well[2].
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3951958/
[2] http://healthysleep.med.harvard.edu/healthy/matters/benefits...
You'd reach burnout extremely quickly. You'd literally go insane. Your body would break down rapidly. None of these are good for anyone involved.
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.
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.
That has happened once in the last 15 years that I can actually remember.
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).
I’ve been doing this for about 10 years.
I guess that's the question which most commenters actually missed :-)
If I had to define things I'd say that the former is actually "care" and the latter is a bit closer to "passion".
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.
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 can dig this, it absolutely is. It's definitely supplemental (emphasis critical).
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.
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.
[1] https://rework.withgoogle.com/blog/five-keys-to-a-successful...
- 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.
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.
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
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).
Pertinent to the article, most of those folks are unhireable today because they can't code with a gun to their head (ala swordfish).
The otherwise ridiculous film Swordfish has a similar scene with higher stakes.
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.
We live in a very affordable city, too.
He was regularly contacted for years afterwards by people wondering how they too could get a high paying job on Wall Street.
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 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!
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".
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.
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.
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.
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.
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.
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.
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."
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.
> 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.
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.
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).
A good candidate won't be an asshole.
> 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.
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?
Everyone is an asshole to someone.
Amazing, I'm stealing this, thanks.
Also, by the by, great to read someone writing openly and candidly about mental illness.
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.
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.
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.
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.
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.
Thanks!
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?
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
Anywho, these are some thoughts.
- 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.
The first situation I can control, the second is losing the lottery.
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.
Unrelated to your point and this thread, but can someone share some data/evidence on this? (not that I am denying it)
In the UK, salaries seem to have gone down across the board from what they were a decade ago - even for top jobs.
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.
Edit: We're in the UK, FWIW.
edit: if anyone reads this and wants a job, I've put my email in my profile.
Even the cheapest dev I have ever met in London wasn't as low as 1/5th of the most expensive contractor I have met.
Disclaimer: I work at one of what I would consider the "great" ones. No idea about UK work, though.
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.
Anecdotally, I am finding more of these people in indie development. Making their own thing or working with like minded people.
I used to look to Google/Facebook for experts and people to follow. Now, I look elsewhere.
Indie = recently unemployed, experienced dev making dream project.
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?”
Yes I’m still supposedly a hands on developer.
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.
Why waste time building software?
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”.
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'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 :/
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.
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."
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.
After all that's what you trained for.
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.
Having gone through one of the mentioned schools, this material also never came up even once.
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.
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.
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.
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.
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?
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 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.
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.
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 :)
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.
seniority !== skill
This is called work sample testing and it works great.
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'.
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?
Folks have built highly specialized company teams with this and little or no interviews.
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.
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.
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.
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.
And then there is the issue of actually retaining top talent...
and CISO of LinkedIn, Cory Scott: https://www.linkedin.com/pulse/evaluating-technical-talent-t...
...because if you are trying to hire people that are proven, you will have to pay them a fair market rate.
Or is it that people that have not been proven before have a lower market rate, justified (so "fair") by this lack of pre-validation ?
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.
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.
The traits to look, suggest:
'lack of' of prestigious education background,
living in non-metropolitan area,
perhaps somewhat muted self-promotion skills
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:
'Up-or-out' https://en.wikipedia.org/wiki/Up_or_out
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.
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.
They mostly don't help because they bear no resemblance to what 99% of developers actually do, even at Google.
Realism in dev job interviews is criminally underrated.
[0] I'm sure there are exceptions.
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.
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.
EDITed to add some \n
> 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.
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?
That said, you've actually built something that you weren't assigned in a class. That's more than most of our junior programmer applicants have.
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.
I think this 'getting along' is often misinterpreted as become best friends. I think a better way to state this question is
'Will this candidate be able to have successful working relationships?'
There is no reason you can't have a wide variety of people -- that would never choose to hang out with another-- working successfully together.
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 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.
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.
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.
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.
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.
* Can I do the job and can I communicate my weaknesses and strengths?
* Will I be motivated?
* Will I get along with the people?
* What will I be 3, 6, 12 months from now? What do I want to achieve?
* What's my motivation and attitude?
* How do I learn?
* How do I work through blocks?
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).
The author blogs here http://chuckblakeman.com/blog you may find examples there
Not sure we'll be able to implement that fully but at least in the spirit, because it clearly fits my worldview.
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.
https://tudorbarbu.ninja/message-to-recruiters/
>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).
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.
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.
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.
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
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.
It makes for great copy. Really.
But then, when push comes to shove, the old search for a lego piece that fits with all the other lego pieces continues, so that there's the alibi.
It reminds me of IBM's "nobody ever got fired for buying IBM".
Life continues.
You just need to hire people that match your company culture, matching the skill set you need for a given salary range.
Hiring someone who blends well in the company culture is half way there.
Now, if there's someone that matches this line of thinking in the pool of talents, is another story.
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.
Hiring is broken.
https://medium.com/@simonhamp/a-new-way-to-hire-tech-talent-...
1. Smart.
2. Gets things done.
Read this. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
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.
any time passion is involved, you are being paid less than market. cash is a more liquid currency and can in fact buy passion.