Last night on Twitter, someone said "Nearly every entrepreneur I talk so says hiring is their biggest challenge. The world is starving for competent people with a strong work-ethic."
This is of course false. The world is not starving for competent people. It's starving for high-status resumes. If those resumes are attached to people who are competent or hard workers, that's a bonus.
The high-status resumes without that affiliation will be no less effective; their associated human will no doubt wash out of a series of roles when it becomes clear that they're neither "smart" or "gets things done", but in most of the industry it takes so long for that process to run to completion that resume status accrues to those failed roles, and those people have an easier time finding their next role, failing upwards until one assumes they reach management somewhere and perpetuate the cycle.
Erin, Patrick, and I tried to do a company to exploit this phenomenon and it was not a success; even the smartest, most engaged teams we worked with were a brick fucking wall when it came to resume status filters. So much so that I was happy just to walk away from it and work with some friends to boot up another company that hires in a more effective way and exploit the phenomenon directly, rather than trying to end it.
I guess I'm saying I agree strongly with Dan Luu when he quotes me as saying that smaller companies that hire like this are playing to lose.
I conclude with the immortal words of Herman Blume: "Take dead aim on the rich boys. Get them in the crosshairs and take them down. Just remember, they can buy anything but they can't buy backbone. Don't let them forget it."
The thing about talks of taking down the elite... based on previous attempts to do just that in various places, it seems like it's human nature that people really want there to be an elite. Previous attempts to take down the elite, when successful, tend to lead to a new elite forming and taking power, which may or may not be any better than the last.
For the last couple years Erin & I have been partners at Latacora, which is like a version of Matasano that instead of just doing application vulnerability assessment, joins startup engineering teams for 9-18 months to run their whole security team and then recruits full-timers in to replace us once it's up and running (there are 4 other partners, including one of my Matasano cofounders). In addition to appsec, we do cloud security, secops, and corpsec/vendorsec. It's been pretty great!
We hire almost the same way we did at Matasano, but more so: we're almost completely resume-blind, don't do phone screens, and have only an hour or so of face-to-face interviews that don't include any tech-out at all.
Even here, where part of the premise of retaining us is that we're going to do recruiting work for you, we still have to actively sell our approach for qualifying candidates, and many of our clients still do some technical interviews.
(Patrick, of course, has been at Stripe since we wound down Starfighter).
I miss the technical work we did at Starfighter but if I had it to do over again, I wouldn't make it a business through contingency recruiting; fee-for-placement contingency recruiting is an experiment I expect never to repeat again.
I'll be honest, it's pretty hilarious to read someone talking about taking down the rich when their company was acquired for $13 million in cash, give or take.
Personal attacks will get you banned here, regardless of whom you're attacking. We've had to warn you about this before. Please read the rules and stick to them: https://news.ycombinator.com/newsguidelines.html.
I'm a beneficiary of the "startup lottery". I am living the dream, and I state that in this anonymous forum to provide perspective to my own feelings about The Rich.
In your early thirties twenties, managed effectively, one million dollars is enough to retire on, and live care-free. Two million dollars is enough to live well. Six million dollars is enough to retire on extremely well. Ten million dollars is disgusting. Twenty is obscene. A hundred should be criminal.
Thirteen million dollars is excessive, for sure, but that's not the kind of awful, powerful wealth that is the root of problems in our society.
> When I've compared notes with folks who attended schools like Utah and Boise State, their education is basically the same as mine.
I work at one of the well-known tech companies, and what I’ve noticed among most software engineers and data scientists is that they don’t really care about your background as long as you can do the work. Which is really nice; whenever I interview candidates, I don’t notice much correlation between the school they attended and their interview performance.
However, the pure research division at this company is totally different. There appears to be a very heavy emphasis placed on the school attended. I was a bit miffed one day because I overheard one of the AI researchers saying “everyone knows there is a huge difference in caliber between the students that attended Stanford and Berkeley for CS and those that attended Georgia Tech”. As someone who attended GT and has a research background, this rubbed me the wrong way. There were also a few disparaging comments about the South in general. Even if there is a difference between the schools (at the graduate level), I would imagine the Bell curves can’t be that far apart from each other. It’s not like 90% of the students that attended Stanford are brighter than 90% that attended CMU.
A professor in my social circle has taught at various schools across North America including Harvard, University of Toronto and a few prominent USA state schools. He says in his experience there's no difference between the intellect and quality of work he sees at the schools he's taught at but the Harvard students are more ambitious and more entitled.
In my own personal experience Harvard, Princeton, Stanford types often carry an elitism that they need to justify the work they put in to get to that school and the amount the school prestige means to their own self worth.
There's also a classic OpEd from I believe the Harvard Crimson from a Harvard admin officer saying Harvard could admit sufficiently qualified students from it's applicants several times over the actual count of its freshman class. So basically you have to have rich parents or be lucky not just be qualified. The elitism exists nonetheless and it's a fraud.
Something I did as I did when younger that annoyed more ambitious friends: go to Wikipedia and find the incoming freshman class size for the top schools (say Harvard, Yale, Princeton, Stanford, MIT). Add them together. Now look up the number of high schools in the US and assume there’s 1 valedictorian per school. There just aren’t enough spots to even fit them.
Now complicate things more: all the elite high schools like Groton or something are gonna be sending way more than their top 1 student to these programs.
My conclusion was that it frankly doesn’t matter how much you compete with your personal classmates unless you have some other angle.
However outcompeting your classmates might get you a full scholarship to the state flagship, which is actually massive if you don’t use it completely imprudently.
> Harvard could admit sufficiently qualified students from it's applicants several times over the actual count of its freshman class
The key word there being "sufficiently". The academics at Harvard are not unusually difficult (relatively easy in some majors), and I would argue that the content in the coursework is distinctly not what makes Harvard what it is.
If Harvard only accepted their third-tier of admits (i.e., ~4000th to 6000th ranked applicants) for a decade, I imagine that you would find that it will have lost quite a bit of its shine. Not that they still wouldn't produce great people who do great things, just that they would produce much fewer of them. The ambition and capability of the top 30ish percent of each of Harvard's entering classes is a game changer, imho.
As opposed to the current 1/3 legacy, unclear percentage propped up by wealthy parents, elite prep school system that consistently and efficiently finds the best students.
There are still plenty of directionless Harvard kids that end up back in their parents's basements after graduation.
Also have you ever stopped to ask yourself who reads and evaluates these admission packets? How often do we complain about hiring here on HN? That it's hard, that you can't tell enough from the slice of information you have about a person. Do you really think the admission people at Harvard have such a gift to accurately tier these teens futures?
And if they had such a gift, why are they admission officers at a university and not in a position where their impeccable qualitative assessment skills can be better leveraged to make tons of money or truly great careers? The same people assessing these applications are the same, reasonably intelligent but flawed people that are doing recruiting and hiring and screening in every other prestigious institution that struggles to choose the best candidates.
Anyway I'm not trying to argue most people are undeserving (except for the legacy and wealthy parents kids, who are again, a very sizable percentage). But the idea that we actually have a finely enough tuned comb and good enough data to actually pick the children with the most elite futures is on its face absurd. And culturally both the benefactors and the people in awe of the halo of achievement around our elite universities are taking it too far.
> As opposed to the current 1/3 legacy, unclear percentage propped up by wealthy parents, elite prep school system that consistently and efficiently finds the best students.
This is a (despicable) feature. Harvard isn't trying to find the most capable students, they're trying to find the students that will most succeed. And they deny that they know there's a difference.
If you are talking about the most capable of success, there is no difference. The fact that the rules of the game which determine success isn't what you'd prefer (or what I'd prefer!) is, well, not principally Harvard's doing.
I think the problem is that you want Harvard to favor those who would be most capable of success, if the rest of society other than the individual and Harvard were (your version of) ideal.
I don't believe Harvard is choosing the wealthy kids and the legacies because they are most likely to succeed, I believe Harvard is choosing those people because they are most likely to have the highest ROI for the Harvard endowment & future donations. Someone from a low socio-economic status or otherwise marginalized background that has worked hard enough and smart enough by 17 or 18 to be a good candidate for admission at Harvard is an outstanding bet to have the determination to succeed later on in life.
> I don’t notice much correlation between the school they attended and their interview performance.
I've noticed one: About half the best engineers I've hired over the years have no degree at all. For the other half, there's no correlation between school and performance.
Oddly enough some of the brightest engineers I've worked with were actually self-taught. No formal CS background or education, but they were incredibly driven and outperformed from Stanford.
James Hetfield talked about that as a reason he left.
"I kind of got sick of the Bay Area, the attitudes of the people there, a little bit. They talk about how diverse they are, and things like that, and it's fine if you're diverse like them. But showing up with a deer on the bumper doesn't fly in Marin County. My form of eating organic doesn't vibe with theirs."
> My form of eating organic doesn't vibe with theirs
I've never heard this before but I love this quote. In my opinion, hunting responsibly brings one a great appreciation for conservation efforts and increases connection to nature. Especially hunting fowl, where you are walking the whole time and working with a dog that you trained yourself from a pup for this purpose. It gives great appreciation for nature and responsibly sourced food.
And the fact is no matter how hard a farmer or rancher works to ensure their product is "organic" it is still being exposed to human meddling. It will never be as "organic" as an animal that grew up in the middle of the woods with little to no human exposure.
There are plenty of places in the Bay Area where hunting and fishing (and the associated lifestyle/political leanings) are part of the cultural fabric. I live in one of those towns, lifted trucks and fishing boats in front of every other house. Obviously, you won't find that in the super wealthy enclaves of Marin, which is probably on the extreme end of the liberal scale, but one does not have to move to Colorado to escape that.
And another relevant tidbit in the article: "It's something I felt. I probably made it up in my head a little bit."
I don't understand why that's a form of bigotry. If someone legitimately thinks that hunting is unethical, it seems reasonable to look down upon someone who hunts.
Replace hunting with some act you find unethical, and you'll see why this doesn't make sense.
1) I really wouldn't quote James Hetfield as a bastion of "tolerance", thanks.
2) Lots of old Metallica metal fans will regale you at length about how Metallica sold out to Redneck America(tm) in return for lots and lots of cash. So, lots of this kind of stuff is suspect as to whether it is genuine vs planned marketing.
3) "But showing up with a deer on the bumper doesn't fly in Marin County."
Erm, actually James I know quite a few people in Marin that are totally fine with a deer on the hood. Somehow I never saw you hanging out with any of us.
But, then, none of us are multimillionaires who are worthy of running around in Mr. Hetfield's social circles.
Just passing along a quote that I heard, nothing more.
As for your first point, he's put up with Lars Ulrich for almost 40 years now. If that's not tolerance I don't know what is.
For point 2, decrying a large portion of the country as "Redneck America(tm)" sounds like the exact type of thing Hetfield is talking about, the same as your dismissive "thanks" at the end of point 1. They sold out with the black album in 91 anyway, there was nothing "redneck" about that album.
> For point 2, decrying a large portion of the country as "Redneck America(tm)" sounds like the exact type of thing Hetfield is talking about
This comes from the fan reaction directly to "Load", specifically. A GREAT deal of Metallica's then-current fanbase was incredibly pissed off.
Metallica, I am sure, cried all the way to the bank. I am reminded of Neal Schon from Journey (paraphrased): "Everybody says we sold out. We played prog rock for how long and where did it get us? We write a couple pop ballads and suddenly we're drowning in money and swimming in women. Did we sell out? Damn straight we did and I have nothing to apologize for."
And maybe James Hetfield really believes what he is saying, and maybe he doesn't. For the amount of money he gets paid, you could get me to say quite lot--some of which I might even believe after a while.
Maybe I'm overly cynical, but the successful people in the music business all understand that they are in the business, first, of making music, second. So, I'm going to regard any "public persona" through the lens of being a carefully crafted marketing construct.
Regarding #2, I don't know who the 'Lots' are you are referring to, but I do know people who were OG Friends of Metallica, as in they were at the Metallica Mansion when Cliff Burton auditioned and full circle, invited to join the band when they were inducted into the RRHoF. Your poor mouthing is at odds with the experiences of people who actually know the members of Metallica (well, except for Lars) have always been super down to earth and remain committed to making great metal music for their fans. Personally, I prefer the old stuff, but I don't condescend to the 'Redneck America' sellout bs. You should try not to as well.
A large-ish, very pro-underdog company I worked for was absolutely fine with "toothless" jokes because I was from Tennessee and fat jokes. I was pretty incensed about the fat joke because that's one level under orientation, skin color, etc IMO.
Everybody wants to pat themselves on the back about how non-bigoted they are because they stopped hating the last outgroup. In reality, there's just as much hatred and bigotry as ever, they just transferred it to a new outgroup.
> It’s not like 90% of the students that attended Stanford are brighter than 90% that attended CMU.
But they probably are brighter than 99% of people that attended NC State.
As a sidenote, I've noticed these sorts of microaggressions against the South as well, but it's dampened by the fact that I don't appear stereotypically "southern" because I don't have an accent and am also South-Asian by ethnicity.
(Disclaimer - I went to NC State, so I can say this)
One frustration I've had recently is the number of companies encouraging or requiring code in the public sphere. They want to see open-source contributions or an active and impressive personal github page. If your employer is protective of their IP ( mine is ) and/or you are not willing to spend evenings and and weekends on pet projects, you are out of the running.
Also
>But if you think programmers aren't elitist, try wearing a suit and tie to an interview sometime.
If I had my way this would be considered employment discrimination and grounds for a lawsuit. At minimum it blatantly discriminates against national origin, expecting an engineer fresh from Nigeria to understand these secret 'culture' norms. Age? Race? Religion? Is a Muslim woman wearing a hijab going have any chance of making it past the first phone interview? I have my doubts.
> I was at a party tonight and someone asked me what my favorite book was. Couldn't answer. They relaxed the constraint and asked about "a good book". Couldn't answer. They relaxed the constraint again and asked me about "any book, good or bad". Couldn't answer.
From his blog, Dan is obviously a great engineer. I'd love to say as an interviewer I'd recognize this and say "strong hire". But I have no idea how to interview someone who gets this nervous. I've written "don't hire" in such cases before.
The attempts at making the problem easier completely miss the point of what makes it hard (for some people) to answer this kind of question. I do not associate books I read with the concept of a book, so there are no associations to follow so this kind of open question has a high chance of causing my mind to go completely blank.
As somebody in that twitter thread said:
> Yep, these are terrible questions, because they imply you are supposed to instantly trawl through your entire memory of years of work, and rank all the bugs (or whatever) and then pick the ONE TRUE EXAMPLE that will make you look good...
I find it much easier to talk about a reasonably scoped a topic where I have strong links between the facts I know about it.
The broader principle I'm seeing is, when it comes to competence, a small company is probably best off looking for reasons to accept, not reasons to reject. Small companies aren't subject to the same corruption-control constraints that large companies are, so they have more flexibility in onboarding someone who doesn't fit in one of the usual boxes but nevertheless can probably provide more than enough value to the business.
(Incidentally, the main reasons I'd reject an engineer candidate who did seem individually competent and motivated enough relate to trust and team collaboration.)
That's a good point. I work for a large, famous company, though. I'm expected to do a standard 45-minute interview with a prescribed focus area (most commonly system design or algorithms/coding) and to evaluate candidates in relatively standard ways.
If anyone has tips for putting a nervous candidate at ease in this situation, I'm all ears.
One thing that I think helps is that I ask markedly simpler questions than other interviewers often do. (We can see each other's notes.) This takes away some of the time pressure and lets the candidate and me go through requirements gathering, verbal/whiteboard descriptions of the problem/algorithm, and a few revisions of the code and debugging and such together if necessary. It also avoids the "candidates need to bring their own finer-tipped whiteboard markers to write the solution on the board" sorts of ridiculousness. It might mean I can't reliably tell the difference between "hire" and "omg best I've ever seen hire hire hire" based on the few lines of simple code a good candidate might ultimately write but I don't care about that.
If you have such crippling social anxiety that you cannot name literally any book, whether you've read it or not, and you can't even make one up, the odds of you performing well at an interview are extremely small.
I'm reasonably confident in at least half the interviews I do, and I might blank if I was asked about books, because somewhere in my 30s, I essentially stopped reading them. If you reminded me of something I'd read, I could talk about it, but nothing comes to mind any more because I'm no longer buying or reading books on a day-to-day basis.
Also, assuming one or more came to mind, maybe I'm paralyzed in an interview because I'm thinking about what the ones I can think of imply, whether they give away my age, or whatever.
It would be easy to talk about a book if I was warned ahead of time.
I'm not sure I even know where my copy is, but if I chose one book that I've read that more people should know about, it would be:
"You Don't Always Get What You Pay For: The Economics of Privatization" (Elliott D. Sclar)
But in an interview on the spot, I absolutely wouldn't have come up with that.
I managed to fail 11 or 12 onsites in a row over a 5 month period before landing my current job.
What I’d like to know is who these people they talk about later in that same thread who interview somewhere every month. Do people really do that? I’m wondering if _I_ should start doing that.
As someone who uses Github and OSS contribution as a strong hiring signal, I'd like to offer an alternative perspective. People who do a lot of personal projects tend to be very good developers, especially when you can see a demonstrated ability to ship.
This is also helpful for people who haven't worked at big name companies or don't have degrees from elite universities. I'd happily hire someone with no experience and no degree if I can see multiple impressive projects they've built for themselves (I've done this, and it's worked out very well).
Yes, it works against people who don't like to code in their personal time, but it also removes a bunch of filters and in my experience works better than anything else for finding good candidates.
This is a stupid signal. Many/most developers are prohibited from working on open source projects by their employers.
In any state besides California and Illinois you will be forced to sign an IP assignment agreement to work for any medium/large companies. Open source projects will not let you contribute under such an agreement, and anything you do on your own is owned by your employer.
Anecdotally, I've worked in Colorado my entire career (17 years now, over half a dozen jobs) and have never signed an agreement like that, and have never been asked to sign one. I go out of my way to bring it up (in writing, even), because it's a deal breaker for me. Never been a problem.
And logically it doesn't make any sense. GitHub profiles can't be used as resumes if employment contracts prevent everybody from contributing to projects on GitHub.
Anecdotally, I've worked for various companies in NY and VA and had IP agreements. I even was given a compulsory IP agreement when I tried to volunteer for the Red Cross, which conflicted with the compulsory agreement with my employer.
For me, it's a significant attraction to working for the government - if I'm not in the office what I write is presumptively mine; while I believe at the state level anything I create at work is not public domain, I don't remember any IP agreement beyond the ordinary work-for-hire relationship.
> Many/most developers are prohibited from working on open source projects by their employers.
This is 100% untrue. IP assignment is not enforceable if you do work on your own time and use your own equipment (including connectivity).
If you don't own a personal computer and your GitHub page is loaded with commits during your working hours, yeah you're going to have a hard time arguing it's not company IP. But for the vast majority of developers this is a complete non-issue, and insinuating the contrary is just FUD.
"Many/most" is ambiguous. "Many" is 100% true, and having a different experience isn't any kind of a challenge to that.
Even if there's some question as to the theoretical legal enforceability of an agreement, if you have to sign it to have a job, then it's not practical to challenge it. You'd have to have the resources for litigation as well as to make a living after being blacklisted.
It is true that people ignore their agreements (about IP, not to run a side business, etc) when they think the company will never notice. That's still a meaningful risk that exists that some day they will.
I paid an attorney to review my contract and NDA...
“ anything you do on your own is owned by your employer.”
If you use their equipment or their office or their phones. But doing a software project at home on the weekend on your own computer is not going to be owned by the employer in the states I’ve lived and worked in (VA, GA, TN, NC).
Do you have a source for a state where this has happened?
I wouldn't expect that working on your own time is automatically considered to be your employer's property anywhere. But some (Fortune 500) companies absolutely do require everyone to sign an agreement that everything you create 24 hrs a day until you leave the job, belongs to them.
I would be willing to sign that for $250,000 or more a year outside the California markets.
I had an offer from a game company that went through my list of disclosures and said I would have to report my potential book royalties to them (why? Dunno) and that I could not continue to work for the local university. I was dumbfounded. I explained upfront in the interview I worked 5-10 hours for the school and the recruiter said that was great and that my new manager loves giving back. Unfortunately legal did not. I ended up backing out of the offer. I still kinda regret it because it was a stellar team working on neat problems.
All that to say I can see companies asking you to sign something that wouldn’t hold up if you had the means to challenge it. I suspect most people done have the privilege of paying $300-1000 to have their contracts reviewed / red lined.
"I suspect most people done have the privilege of paying $300-1000 to have their contracts reviewed / red lined"
I mean, I've never had a six-figure job, but I could pay that much to have a contract reviewed, if there was a point. But I don't think there is a point, because unless I literally had a bidding war going on for my services, I'd have zero leverage.
A few years back, I thought I'd figured out how to negotiate, because I tried a method when buying a car that worked very well. But it completely failed when negotiating a salary, because tying someone in knots and exposing their BS, no matter how politely, has no value whatsoever when you don't have an immediate alternative. If you're trying to buy a new car and there are several dealers in town with the same one, that's completely different from having a single job offer outstanding.
I've learned in my personal life too, it doesn't matter how inescapable your logic is, if you don't have any leverage and the other person is willing to jettison logic, it's irrelevant.
Can you afford an attorney to defend yourself in court if a company decided to push the issue?
As I will keep saying it does not matter if companies follow up on their threat or not. It still has a chilling effect on people doing side projects which is the intended behavior. And a lot of people can't afford a legal battle even if they had a high chance of winning.
Have you considered doing it anonymously or not informing anyone of the projects you're working on?
Just like you can't necessarily afford to engage in the legal system, the legal system can't be engaged if they don't have a signal that there's anything there to engage with.
And in interviews you can still use the experience and talk about your contributions without releasing the product/ identity to your current employer, and your current company is incredibly unlikely to come chasing after you years later on things with no obvious connection to your real name.
> not informing anyone of the projects you're working on?
This is the exact opposite of what you should do. As soon as you start working on a side project that doesn't overlap with your day job, you need to tell your company to get it added to your contract's list of excluded projects (meaning they've verified it has nothing to do with them, and you're free to do whatever you want with it).
Issues happen when you leave your job and launch a side project not long after, creating a bit of a surprise. But if you had disclosed it previously, your previous employer is shit-out-of-luck.
What he's telling you is that he'd rather accept false negatives than false positives. That's the hiring mindset, because getting rid of someone bad is difficult and costly.
Ok, but surely the problem there is that companies are (legally?illegally?) taking part in deliberately overreaching and anti- competitive work contracts.
And I mean hey, it's working isn't it? Can't show external evidence of your work and skills, now you're a bit more trapped here.
And I am sympathetic: those are completely unreasonable and anti-competitive employment terms, and I've had a past supervisor subtly imply they 'might own the intellectual property of all my thoughts', to which I can only offer the potentially useless advice of don't work there, or do work there but ignore/fight them.
People who do a lot of personal projects also tend to be young with minimal outside responsibilities. It is no secret that they are appealing hires - someone who's willing to spend long hours on personal projects is probably also willing to spend long hours on work projects.
That's what makes it discrimination.
Life is about trade-offs. If you want to spend more time outside of work on things like friends and family, that's great. In fact, it's probably optimal. But to then say it's discrimination when someone who has made the choice to instead only focus on their technical skill, at the exclusion of friends and family, is better than you, is a little silly.
To be more charitable to the commenter's point, that's not what's being asserted as discriminatory. They're making the claim that it's implicitly discriminatory to penalize people who don't spend time on programming outside of work, because that reasonably penalizes people who are older (i.e. more likely to have a family).
They are not making the claim that choosing to hire someone better than someone else is discriminatory.
Why is it discriminatory? All else equal, isn't it clearly better to hire someone with no responsibilities outside of work, than someone who has to be out of the office at 5pm every day to deal with their kids?
> All else equal, isn't it clearly better to hire someone with no responsibilities outside of work, than someone who has to be out of the office at 5pm every day to deal with their kids?
No it isn't clearly better. Note, I'm single but proposing that someone that lives code as being better than someone that stops to smell the roses of life is a bit too much.
You're also discriminating for people that may be horrible for the team. I bet that person with kids is likely better at conflict resolution than the programmer that never goes out to socialize.
That is what you're discriminating for/against. I'm learning a hobby on how to build some rather completely different things. Not only is it refreshing to think of computers as "just another goddamn tool" but to not need the things at all.
It is letting me escape getting into a rut in software only. But guess what, it means I'm not contributing to open source because I'd rather be doing something, anything else.
Working outside of work is mostly free training for your company. Nice for them, bad for you later on in life. I'd rather meet and make friends as I am growing older. Relationships are the thing I regret most for not paying better attention in life. I don't think as a society we should keep encouraging people to act like mindless drones.
I never said that someone has to live and breathe work, only that they don't have anything _higher priority_ than work.
If I have social plans with my friends I'll likely cancel them if there's a bona fide work emergency. If I have family obligations I cannot and will not.
> I'd rather meet and make friends
OK, and I'd rather ski for an hour or two every weekday morning, then come home and shower and finally start working at noon.
I just don't see why I would expect the work opportunities available to me, and the compensation, to be no less than someone who doesn't have that requirement.
Having kids is a lifestyle choice that is at odds with other choices. If my preferred lifestyle is to be a starving artist/musician, or a ski bum, but I also want to have kids and so might have to suck it up and take a soul-sucking corporate job, no one is going to shed a tear for me.
But if instead of rocking out I just want to get the same jobs and paid the same salaries as people who are actually much more productive than myself, that's somehow not only reasonable but unimpeachable.
All it really is is another in a long line of examples of people with kids expecting special privileges and support for their personal lifestyle choices, not only from society at large (maybe reasonable) but from everyone, individually (not).
If you want society to subsidize having children, then the government should do it, not individual software teams.
> I never said that someone has to live and breathe work, only that they don't have anything _higher priority_ than work.
What exactly does this mean? I prioritize A LOT over work. My back hurts, work can suck it. I get into an accident, again, work takes a hell of a back seat. If a family member is having issues, guess what, work may not be my highest priority. I'm a human, not a robot.
> Having kids is a lifestyle choice that is at odds with other choices.
That is self evident, what is your underlying non analogy point?
> If you want society to subsidize having children, then the government should do it, not individual software teams.
Software teams are a part of society are they not?
I'll be blunt, I'd rather generally have the people with kids on my team than the humans that think Arbeit macht Frei (had to be done, far too apropos in this specific instance). Having time off from work tends to mean you focus more on work when you're there. I love programming, but I have other things in life I want to pursue. It also means I can compartmentalize work for work, not "oh i was thinking of doing xyz at work, i should spin up a bunch of cloud instances at home tonight and test this shiny new thing out to make my job hopefully a bit easier in the week". That mindset is just doing training for work outside of work. Which is simply, more work, and the end result of that kind of stuff from what I have seen, is guys end up snapping and go insane or worse.
> I get into an accident, again, work takes a hell of a back seat.
Sure, but those are unexpected and hopefully rare events. We're talking about things that take priority over work every single day.
> > Having kids is a lifestyle choice that is at odds with other choices.
> That is self evident, what is your underlying non analogy point?
What I mean to put it bluntly is that having kids means less time for other things, including work. Make that tradeoff if you want, but don't to make the negative consequences of your choice my problem.
> > If you want society to subsidize having children, then the government should do it, not individual software teams.
> Software teams are a part of society are they not?
Sure they are, what's your point?
Society should probably help out homeless people, but that means collecting taxes and providing services, not expecting individual families to invite them into their homes and feed and clothe them, etc.
> I love programming, but I have other things in life I want to pursue
Same here, but I'm not the one complaining that a team of people who don't share that requirement isn't hiring me, bending over backwards to accommodate me, and paying me the same as their top performers.
I don't think that's a fair depiction of why people code on their own time. Some people just love making things, it makes them happy. I'm not young but still find the time to build projects in my spare time because I want to, not because it's training. I'd even go so far as to say I "have" to do that as I get pretty unhappy if I don't have some personal projects going where I can explore ideas and be creative. It's a side effect that I've learned a ton of valuable skills building personal projects and those skill directly translate into market value.
Coding on their own time is perfectly fine, if it's your choice, I also do it sometimes. This is not equal to "they don't have anything _higher priority_ than work".
You just compared a nazi slogan from the slave work camps to a cushy software engineering job. I won't attack you but you should really step back and reevaluate your thinking on the matter.
I used to be a maximalist like you.
Maybe, later in your life, you will also recognise that the world is so much bigger than work, that the years of your only life are seeping through your fingers, and you will not have another one, and you want to experience more of it: close relations, fatherhood, art, crafting, enjoying the flexibility and strength of your healthy body, digging into science, greeting morning somewhere in Iceland...
I also believe it can make you better at work, in ways you currently may not appreciate. Coding more at home can make you a better coder, but it's a diminishing return. At some point you will get more from being good at communications, making better choices, finding compromises, reflecting, seeing the whole picture, avoiding errors caused by constant typing with tired brains.
It's a great pleasure (for me) to work with people in 30s-40s, with children and hobbies: healthier environment, less stress, usually less ego and drama, focus on working smart and thinking twice before typing, less chance to see and clean shitty code, also, very interesting conversations at lunch.
This is well-written, really. But wholly irrelevant. I already gave up most of my career to focus on what I really want. The point is, I'm not demanding to be paid $400k despite that fact, or demanding that a team full of 9-5ers hire me even though I start work *no earlier than noon and take days off with no notice regularly.
My first point is that you cannot measure the output of a person only by the code, working hours, and coding at home. With experience, you can grow different skills that scale much more than coding - they impact many engineers, many teams. Building right things, building things right have more impact than building things fast. And many of those skills are built by being exposed to real life, connections, taking additional responsibilities.
"they don't have anything _higher priority_ than work" it's too much, man. It is not in the same league with coding at home, it's sacrificing your life for an organisation, shareholders that will never sacrifice their lives for you in return. In fact, they will not even sacrifice potential profit for you, and make you redundant despite your commitment.
I never said that someone has to live and breathe work, only that they don't have anything _higher priority_ than work.
Why wouldn’t I put many things as a high priority than work? I don’t have any equity in the company and even if I did, it’s statistically likely to be worthless if it isn’t a publicly held company. If it is a publicly held company, my contribution isn’t going to make or break it.
The company definitely doesn’t put me as a high priority.
Because if it isn’t, you can make more by going to a company that pays more - not by killing your self working 60 hour weeks and giving up everything else.
But all else is not equal, and this is what I find incredibly silly. You have a very strong prior on time when that is probably just one of many factors. Experience, efficiency, the ability to work well with others, organizational ability, and perspicacity are just a few of the several other things that goes into being an effective engineer.
Moreover you don't seem to balance your time prior out with others. Sure, time may have an effect, but what if this effect is marginal? This also gets down to something that bothers me about this line of thinking, which is the desire to create overly simplistic models of talent. Talent is incredibly multi-faceted, and hiring based on pithy narratives without actually looking at data is how we ended up in this situation where class signalling or age has become a substitute for talent.
The main reason that employers seem to think it would be "better" (for them) is so they can pressure said employees for free labor and overly-aggressive timelines.
Yes, exactly? Why wouldn't I rather hire someone who is usually available at anytime vs. someone who needs to leave at 5pm every day, constantly taking days off to deal with issues with their kids or their school, constantly bringing germs into the office and so on?
Personal attacks will get you banned here, regardless of how wrong or annoying another commenter is being. Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here.
So we have a personal attack, an unsubstantiated assumption, and zero substantive argument. And I'm the toxic individual? Perhaps you should find a different message board to pollute.
I should not have made a personal attack. But I really would encourage you to consider what others have written and think about why your take on hiring is not healthy and may even be actively discriminatory against a protected class.
You'll be happy to know I have nothing to do with hiring of any kind, but just as an individual contributor it seems quite unhealthy to me to work on a team where work is my #1 priority, but everyone else's distant second.
I suspect you'd find it quite ridiculous to have to pick up my slack as I have to run at 5pm to practice with my bandmates, at least if you weren't paid correspondingly more for the extra effort. Change that to a PTA meeting or soccer practice, though, and suddenly it's how dare you suggest that I get paid less for not only doing less work than you, but doing some of the work I was expected to in the first place!
Well, I would say that if you make work your number one priority for a company that you don’t own, it’s very naive. If you got hit by a bus tomorrow, the company would send flowers to your funeral and have an open req out for your position before you’re buried.
>I suspect you'd find it quite ridiculous to have to pick up my slack as I have to run at 5pm to practice with my bandmates
I suppose it depends what the context of "pick up the slack" means but, in general, I'd find it perfectly normal for a co-worker to take off at 5pm for an evening activity, family-related or otherwise.
I do tons of work-related travel and the like. I also don't do nights and weekends work day-to-day. Work emergencies happen (as do odd-hour conference calls) but it's rare I'll schedule evening activities around work when I'm not traveling.
That's a legitimate tradeoff, which may or may not be worth it to everyone.
But that's not even close to the situation most developers are in. Most are getting paid somewhere around an average salary, maybe with a few probably-worthless stock options, and they're getting asked to sacrifice their personal time working for free to make founders rich. Working extra hard isn't likely to advance their career at all; it just gives them a reputation as somebody who is willing to take abuse.
If you're in a situation to make a crazy good salary by working hard, by all means, do that if you want. But understand that situation is very rare. And even if you're getting that deal, the person sitting next to you might not be in the same boat.
Working hard to make other people rich is a sucker's bet, akin to playing a slot machine. For a rare few, it pays off big. For a somewhat larger cohort, there's a modest payoff. For the large majority, it's just wasting their career and their time.
First, your A-B situation is not a reality for most of engineers.
Second, if you want to dedicate 10 years of your life to work, make money and retire early - it's a reasonable choice for many. But if it goes into 40s - why do you need money, if you would not be able to enjoy it constantly working? Your money may go straight to doctors and psychotherapists eventually.
It may be clearly better if all you need a bunch of young and fast code typists. What about ability to make balanced pragmatic decisions, not based on fun or hype? What about mature communications, understanding of business? Understanding of technical dept, complexity?
Obviously not everyone. But many people review their priorities at this age. At the same time, you body and your mind start suffering from such dedicated lifestyle: back pain, depression.
You also most likely reach your salary cap in 30s as a coder, so you'll get no ROI on coding more.
Suddenly, physical activities, rest, communications, hobbies make more impact on your work performance.
In the end, it's a matter of personal choice, and the choice is not black and white between work as a meaning of life and leisure skiing till lunch.
How do you know here that their job will be priority #1? Traditionally, men with families are considered more reliable because having a family demands stability. If I’m a dude who gets sucked into code, who’s to say I won’t get sucked into some other code than what I’m getting paid for.
You don't see external responsibilities as a forcing function for efficiency? Raw time spent is not always a strong indicator of ability to ship, in fact that often means that an engineer is very inefficient and uses a surplus of time to compensate for lack of efficiency.
But if the purpose of doing side projects is to be more competitive in the job market, are there that many high paying jobs that want Lisp?
Besides, in my experience, knowing a specific technology from doing side projects usually doesn’t count as much to potential employees as having on the job experience unless your open source project is really popular.
I would view any Lisp project as a major bonus in favor of a candidate. It's really encouraging when you see people who have an interest in different programming languages. When I look at people's open source, being a polyglot is a huge plus. Each language offers a unique perspective on programming and the desire to explore them is a strong signal of a self-learner and someone who is passionate about tech.
I've never asked my employees to work long hours. That's basic management. I also let them continue working on personal projects whenever possible (getting the rest of the company to agree...).
Few managers ask their employees to work long hours. That doesn't mean they don't expect them to work long hours.
"let them continue working on personal projects". How considerate of you to allow them to decide if they want to work long hours on their time or the company's.
It's just frustrating because not everyone wants to spend 24/7 working at a computer, some of us have other hobbies and prefer to keep a good work/life balance. I already get paid to code 8 hours a day, the last thing I want to do is go home and do it for free.
Would an architect get denied employment because they didn't have a "pet project" skyscraper in their backyard to show off?
I get the idea but I don't think people expect you to do this all the time. It's more to back up a resume that's weak in other areas. (no name companies, no name University, etc. And this is all relevant to the area you're applying, what is no name somewhere is a name known elsewhere)
I found having some open source contributions was a positive for my resume. People knew I could ship something then. They could literally go online and check to see what I did.
I've done most of mine when I didn't have a job or knew I needed something to get the next job. So, it was not much different than investing time in interview prep.
Couldn't tell ya if I prefer leetcode or open source contributions. As for the last five years, I've mainly had to do leetcode every year cause no one gave much care to my contributions after a point. (leetcode is #1 in sv)
Like I said before - I graduated from a no name college and a no name company and my average turn around time from looking to having at least two reasonable offers is less than three weeks - in 20 years.
You graduated - what - 30 years ago? You presumably have more than 20 years of experience. Do you really think you're the person who needs to pad their resume out with open source contributions to make a strong resume as an IC? I'm gonna guess no.
Hiring the trendiest is also a bit of an SV thing. I don't know if you're in SV or not but if your job searching doesn't involve any leetcode prep then I presume you're not in SV. (Less than 3 weeks on leetcode prep seems crazy to get a job in SV unless you practice regularly)
I graduated 22 years ago. I did my last non work related side project as a sophomore in high school.
I will do “side projects” at work - low or no priority projects using new to me technology or voluntary to work on feature that would take me extra time because the underlying technology is new for me.
That has the advantage of getting feedback from coworkers, being able to work with a large infrastructure, and of course its “real world experience”.
I’m nowhere near SV, the last time I did anything approaching a LeetCode interview was my second job out of college and they really were doing some low level C coding so it was relevant for them.
Lastly, if I do jump through hoops, it won’t be for a job that just pays the median market salary that I could get anywhere. Now that I am moving toward working for consulting companies, yeah I will have to do the leetCode equivalent.
I literally can't code in the evening if I've been doing it all day. I have to be creative in other ways (sketching, blacksmithing, leatherwork, bookbinding, even minecraft has worked for this).
All my side projects have been done between gigs when freelancing, or while working in management roles where I can code as a creative outlet in the evenings because I haven't been coding all day.
I'm always slightly suspicious of people who claim to work a regular job coding and then put in similar hours on hobby projects. It's almost like "but if you can code in the evenings, what were you doing all day?"
This isn't a popular sentiment on HN but a lot of software jobs (even at trendy fast-moving startups) are a form of busywork. Once you get to a certain number of devs, accountability slides and it's entirely possible you'll have nothing to work on. Meetings are dominated by more senior-level devs whose work is important, and so management quotas are the only reason you're even still around.
How you react to this depends on your personality I think -- some people I know love this and are happy to sit in a corner desk and watch youtube videos for a paycheck. That won't work for me so I'll usually scratch and claw for something to do (establishing my reputation as a whiny non-team-player in the process), be given some task which often is a weird platform-specific bug that nobody else wanted, and I'll spend my time hunting that down, become emotionally drained in the process of trying to get anyone else to care about it, and then I'll spend my free time coding in order to make sure I'm growing as an engineer.
I figure this is kinda what life is like until you're a little more advanced in your career and from asking around other people at my level feel the same across many different organizations.
I think you might be right. I've been in those positions, too. And yeah, I could code in the evenings then, because I'd basically done all my actual work by about midday (and then spent 5 hours twiddling my thumbs and looking busy while wondering why I was wasting my life on this shit). But I never lasted long in those positions, I was too obviously unhappy.
It's not about denying you employment. It's about hiring someone who can ship software. If someone has publicly shipped software and you can see that, they make for a good candidate. It seems reasonable to me that people who really love writing software and do it a lot would get jobs and be successful in the industry. I wouldn't judge them on their work/life balance, some people really do enjoy programming that much.
If you can't glean that devs with 15+ years of experience on their resume know how to ship software, then maybe the real problem is your ability to evaluate talent.
I've hired tons of developers with 15+ years of experience! A lot of them have amazing OSS contributions. Some don't but all can talk in depth about projects they've delivered.
Hiring based on open source contribution isn't the only signal one can look at, it's just a very strong one (the strongest in my experience).
I'll add that not all developers with 15+ years of experience can ship software. Many have let their skills deteriorate or never pushed themselves to learn new things. It's yet another reason a strong personal portfolio is a good signal.
I am one of those with 15+ years of experience and have shipped many different projects. I've also interviewed many people with impressive resumes only to realize that resumes don't translate to performance. The ability to ship quality software has more to do with personality than it does resumes. I see nothing wrong with counting open source contributions as a big plus. I wouldn't use the lack of it as a hard filter though.
I find it strange to associate OSS contributions with 'shipping software'. I've shipped plenty of software. I've dealt with drop dead release dates, 5 nines HA requirements, production war rooms, and a product paid for and used by millions of people.
Is 'shipping software' the same when there are no angry customers who can burn up the support line demanding refunds and threatening to leave 1 star reviews on amazon?
Being able to produce a solution to a problem where one didn't exist before is "shipping". I've never regretted hiring someone who has multiple projects they've created from scratch.
That's the beauty of it being published on Github. I can look at the project and see if it was just a `git push` of something meaningless or if it's actually well thought out and demonstrates ability.
Shipping is different than deploying server-side code. Going from concept to execution is shipping, and it's what I look for in a candidate. Again, this has worked out very well for me. An added bonus is if you hire OSS contributors, they tend to attract more OSS contributors.
That's a red herring. Continuing education requirements for professionals are a joke compared to what is expected of software engineers by some people in this industry. Had I actually pursued PE licensure after I graduated, I could have fulfilled my CE requirements with 4-5 weekend seminars a year, probably paid for by my employer. I don't think a couple small weekend projects are going to satisfy the people who are expecting open source code to look at.
Not the same thing at all. Any medical group or law/architecture/accounting firm will pay for your continuing education requirements. The OP is talking about requiring extra unpaid work in your own free time. Presumably they enjoy working with single 24-year-olds with no outside interests.
I really see both sides of this. It’s hard to get around the fact that OSS and GH activity really, truly, is a good hiring signal. It’s certainly one of many, and it’s not (nor should it be) the be-all, end-all hiring signal.
There are wizardly devs who stick to a strict 40 hour week. There are equally astounding devs who live, breath, and dream code all day every day. We’d all be lucky to work with both.
I don’t see a way around the fact that a public resume is just an enormously strong and quantifiable signal for hiring managers.
On the one hand, it's hard to deny that a requirement (or strong preference) like this will often discriminate against some fairly large groups. And it feels cringe-y for that reason. But it's also hard to deny the value of a portfolio that's directly relevant to the job being hired for.
And, if I'm being honest... I do a lot of writing as part of my job. If I'm hiring someone for a role like mine, you can be sure that I want to see some writing that they've done. If they don't have anything they can share? (Which seems a little off. But maybe it was all internal company communication stuff.) Well, they're going to have to write something because I'm not going to just take them at their word that they write well.
Also keep in mind that while X could be a good hiring signal, that doesn’t mean that “lack of X” is necessarily a bad hiring signal.
I’d be ok with using public projects / GitHub as a boost to get someone into the hiring funnel, but I’d never use “no GitHub profile” as a reason to filter a candidate out.
If it works for you then great, but you are really limiting the pipeline of candidates. I'll bet there are 100 great candidates out there who don't even have Github accounts for every one you are seeing.
For every one of them, there are 100 people in the pipeline who can tell you in great detail how brilliant the last project they worked on is but can't write a lick of code.
Honestly, he was brilliant. I was looking forward to working with him. Right up to the point where we handed him a laptop and asked him to write some code. "I know you're looking for language X, but I'm really more comfortable with Y."
Me (who has written my share of Y): "Sure, that'll be fine. Y should be installed."
He proceeded to take 30 minutes to not produce anything resembling X or Y. It was agonizing.
That’s acceptable. Sit me down to an IDE to write some code and/or stand me in front of a whiteboard to draw out some architecture - like people do in the real world.
But don’t ask me to code on a whiteboard. That’s not a real world scenario.
I didn’t graduate from an elite college. I graduated from a no name college over 20 years ago. Software engineering jobs are a dime a dozen. I’ve also only worked for a company that anyone has ever heard of for a couple of years.
If someone hinted that they wouldn’t hire me because when I left work, I shut down my computer and didn’t think about software development until the next day, that would be a hard pass. I would move on to any of the dozen of companies that are looking for experienced software developers - and I’m not on the west coast.
You're right there are a bunch of software development jobs out there! Certainly enough that any skilled developer can find one.
That being said, for me as a manager, I like to hire people who demonstrate the ability to repeatedly ship products. It helps if they've owned that product from conception, through delivery all the way to support. That's a skill that is in great demand and I've never been disappointed when hiring someone with a great project portfolio on Github.
It doesn’t say anything about how well you can “ship” a product because you posted it to Github.
“shipping a product” involves knowing what trade offs to make, deadlines, working with QA, deployment strategies, documentation, not breaking preexisting code, etc., dealing with security and regulatory audits, etc.
Nothing about posting a pet project on Github gives a signal about shipping a product in the real world.
Sure it does. Are they solving a problem they were able to define? What does the shipping history for their project look like? Did they make interesting design choices and tradeoffs. Shipping any software is an accomplishment and does a lot more to demonstrate your skills than leetcode interviews.
I really enjoy hiring people that have been full-stack engineers, or the only engineer, at small businesses. They almost without exception know how to develop a reasonable application.
People that have only ever worked for a large corporation seems to know only how to deal with their own little bit of the stack.
Almost all of those procedures are perfectly ok as long as everybody is not doing the same ones. The problem appears if every well paying job requires your to have a public portfolio.
The good news is that all of those procedures are more effective the less companies are using them. So unless you the entire field has a very centralized hiring market (as in 80% of the good jobs are in FAANG), there are good odds it things don't ever get bad.
The comment I was responding to was "Almost all of those procedures are perfectly ok as long as everybody is not doing the same ones. The problem appears if every well paying job requires your to have a public portfolio."
IOW, a fair reading is that the parent acknowledges that the practice excludes people who aren't in a position to have a public portfolio. (For whatever reason: IP rules, family obligations, lack of interest in programming as a hobby.) And that would be a problem if everyone did it. But everyone doesn't so it's OK as long as just some of us do it.
Please please please P L E A S E keep in mind that a lot of developers literally cannot work on many projects in their free time because the company they work for owns everything they do on and off company time.
Even contributing to open source efforts can become an issue because you're expected to ask for permission first and it can become a sticky legal issue of ownership. Companies expect and want people to work on personal projects but then don't give ownership of said projects to the developer.
In 25 years of signing employment agreements, I've never seen one that said, "the company ... owns everything they do on and off company time." Yes, if you're working on a Foo and you write a Foo on your own time, you'll have an issue.
In California it is illegal. If you work in trendy software companies, startups, etc - it probably isn't common because so many people have Githubs.
As a embedded software engineer, I've had specific language claiming rights to everything (one even called out "songs or other copyrightable works") I do while employed at the company at 4/4 of my post-college jobs.
All tech company jobs I’ve had (in California) had IP assignment clauses. They are not illegal. CA companies can claim ownership of IP produced by employees on their own time and equipment if it “Relate[s] at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer”
This is a huge loophole for larger companies who can argue that everything you do may relate to their future business.
The challenge is that your Googles and Microsofts don't just make Foos. They make Foos, Bars, Widgets, Whatsits, and everything else. When you're building an all-encompassing tech ecosystem, nearly anything your employees do on their own time could be arguably construed as related to the business.
Not only do some companies require you to sign those agreements, I worked for one where they gave one to you after years of employment* and you had to sign if you wanted to continue to be employed. Lawsuits are spectacularly beside the point. You don't say to your spouse and kids "they fired me today, but I'm sure in ten years or so we'll win the lawsuit!"
*if this sounds implausible, it might have been at the time that a spinoff was happening and employees were being "technically" rehired by the new entity. I don't remember for sure.
It doesn't even have to be lawsuits - I've seen cease and desist letters be sent in the past. Not everyone has the financial resources to hire on lawyers to go through with a lawsuit.
Well, the thing is, you can get a cease and desist for just about anything, whether there's justification for it or not. Anyone can do anything to you, if you can't or won't call them on it. That's why I wanted to see legal precedents.
If the Nginx thing were happening in the US, I know which side I'd put my bets on. And I'd really like it, one way or another, because we wouldn't need to have this conversation.
My last job had that clause in the contract. I was actually discussing with a co-worker on doing a game jam thing together outside of work and that got shut down because we didn't want to get into legal issues.
The fact that they'd likely lose the lawsuit doesn't matter, it's the threat of legal action which we couldn't afford in the first place. Mind you, this was a company that had absolutely nothing to do with video games too.
That's illegal in California, but in Canada you will see things like that come up, even to the extent of saying the company owns anything you think of while employed there.
I turned down a job in Oregon this year because they wanted me to sign an IP assignment clause to that effect and refused to budge when I asked them to remove it.
A fair amount, I'm also not young and find time to make it happen. I love building things and I couldn't really imagine not working on my own projects.
I'll be honest: if you have one person who spends 8 hours a day practicing a talent, and another who spends 10 or 12 hours a day practicing their talent, which is going to be better at that skill? Having lots of open source code to read demonstrates in public the prospect's talent for writing code, has examples of their collaboration with others, etc, but also simply means they spend more time writing code and getting good at it, on a broader variety of projects, with a greater diversity of collaborators.
Yes, it's unfair, and if we're just arguing on a sense of lofty idealism, I agree that you shouldn't have to sacrifice your off-hours. But the truth of it is, people who don't code in their spare time aren't as good at it, and people who do are not only more skilled, but are easier to evaluate.
But writing code is only a small part of a software engineer's job (at least that's true everywhere I've worked), so selecting people who have opted to dedicate their lives to only that portion might be a worse idea than hiring better-rounded candidates, when it comes to building real software systems that need to be liked by users.
The law of diminishing returns applies just as much to programming skill as anything else. Most programming work is not that hard; for the vast majority of jobs, the point of diminishing returns occurs well before "works 12 hours a day writing code for fun on GitHub". After that point, other skills start to matter more than sheer amount of code churned out. This is true even for e.g. senior R&D roles, where for those with the necessary programming skill the ability to come up with new techniques is more important than a few more hours spent writing code.
Time invested isn't linear with improved talent. We all have our own thresholds, but we all get diminishing returns after working/practicing so many hours in a day.
It also depends on the quality of time as well as the quantity. I'm a musician, and it's a fairly common trope to talk about practice in terms of efficiency, such as identifying "directed practice" and similar terms. I've experienced it myself: if I'm mindlessly playing the same passage over and over again, I won't improve nearly as quickly as if I stop and analyze why I'm making the mistake rather than just trying to force myself past it.
Perhaps, but this is only important if you need the absolute best coder above all other skills. People do other things during their free time that can build valuable skills that contribute to them being a better programmer and teammate. For example, volunteer coaching makes you a better mentor, playing team sports can make you a better collaborator, etc.
Just being good at code isn’t the only important thing. Programming requires communication and understanding what people want. Sometimes you need to debug the human mind.
> One frustration I've had recently is the number of companies encouraging or requiring code in the public sphere.
As someone coming from the hiring side, I don't understand how these companies are finding enough candidates that they can afford to put up all these arbitrary requirements.
Right now in the US, software engineers are one of (if not the the most) in-demand position in one of (if not the most) tightest labor markets in economic history. To find engineers we've had to scrape the bottom of the barrel, throw piles of money at recruiters, and literally beg candidates just to come it to talk to us.
Are these companies requiring things like 1000 Github stars or a resume with experience exactly matching twelve different super-hot tech stacks actually finding people? Because if so, it boggles my mind?
One possibility would be you're not trendy enough to get the trendy candidates.
There might be an alternative approach that is more suited to non-trendy businesses.
What you can do is write an ad that is trawling for anyone who is at all useful as a problem solver without tech requirements. Then you look at the best of who that brings in, and maybe you find people that others are overlooking and will work for less, with a better attitude than someone who might be tricked into thinking you're trendy and then leave.
Edit:
Something I think is key whenever you're trying to select the best of something from a large population, is not to decide up front what the important criteria are. First, figure out how many you need in your pool to evaluate in more detail, and then construct your criteria to get that size pool. At that point, you select the top 10% or 1% or 5 or whatever, for the next level. And then, if you end up with something other than you expected, consider that may not be a flaw in the process, but a sign that you need to adapt to the output and utilize it opportunistically.
You can't just say "these 5 things seem like reasonable requirements" and commit to that because multiple filters can exponentially reduce the results.
> As someone coming from the hiring side, I don't understand how these companies are finding enough candidates that they can afford to put up all these arbitrary requirements.
Well, they're not; that's one reason why there are so many stories of "not enough qualified developers".
If I give in to my conspiratorial side, I'd say having these arbitrary requirements is entirely intentional, so a company can either:
a. not have to hire anyone at all
b. lobby for H1B
or c. resort to offshoring, outsourcing, etc.
How long is your list of requirements? Are they all absolutely necessary from day one or are some of them things a good developer could learn in a reasonable amount of time?
>One frustration I've had recently is the number of companies encouraging or requiring code in the public sphere.
This unfortunately isn't just a trend on programming. I've run into the worrying trend of marketing roles or contracts requiring live walk throughs of running ad accounts of current clients so people can vett you...uh what? As if NDAs don't exist or you just plain don't feel comfortable sharing client data and marketing secrets you're suddenly unhireable.
I could see a company trying this with a calibrated amount of effort, and congratulating you on not giving up client secrets, treating it as a positive thing. If you'd have given them client secrets, they'd boot you (potentially right then and there).
Re: public code, don't get me wrong, I'm sympathetic, but honestly there are very few ways to separate a good programmer from a good bullshitter. The alternative is interview coding tests; suggest that and see how much love you get. (And some don't even know they're bullshitting. They honestly think that being marginally associated with a project means they did the work.)
As for suits? Yeah, those are the same people who freak out at the idea of wearing a suit to an interview.
There are many more ways of organizing hiring, all working fine in other industries (with tradeoffs, of course). To name a few:
- Guilds with an an entry filter that guarantees competence, often associated with apprenticeship.
- Wide open hiring for short term engagements, retention of only those who fit best.
- Hiring directly based on referral from other known-competent professionals who can vouch, with no or minimal interview stage.
- Work sample tests.
There are good reasons why some of these don't fit tech so well. Software is impossible to estimate, so you can't plan short term engagements as effectively as in show business. Software is highly collaborative and context dependent, and the results are often secret, so independent work samples aren't as realistic or available as in film. Etc. But mainly we can't have these things because the community is pathologically incapable of trust. Even people who believe in each other's competence will not believe in each other's certifications of a 3rd party's competence. That particular dysfunction is not universal, and doesn't have to stay. But knowing us, it will.
"- Guilds with an an entry filter that guarantees competence, often associated with apprenticeship."
You mean the "union shop" approach? I could see it, but it is a significant structural change. Also, it probably wouldn't satisfy many.
"- Wide open hiring for short term engagements, retention of only those who fit best."
"But," I can hear them saying, "what happens when you move across country and are then told, 'sorry, it's not working out'?"
"- Hiring directly based on referral from other known-competent professionals who can vouch, with no or minimal interview stage."
I've gotten a significant number of my jobs this way. And I've had people ask for a referral and told them no, I wasn't comfortable doing it. That's not much fun.
"- Work sample tests."
On the whiteboard (Ick! Horrors!) or take-home (Ick! Horrors!)?
Ok, so I admit to being pathologically incapable of trust. But I'm that way because the universe keeps burning me. I'm sorry.
I do get that, and I'll be more sympathetic to hiring managers who want to see open-source code than I have been in other comments.
( Active job hunting tends to make one grumpy. Take home programming assignments are a current sore spot for me. )
It's a recent job posting that said "Requirement: OSS contributions" that seemed over the top. Maybe it's no less troubling than "Requirement: SQL expertise" - after all, we're all 'discriminated' against to some degree by not having experience in everything a future employer might want.
With the SQL requirement, however, there's an obvious drag on a project if they bring in a new hire who has no SQL knowledge. If a team working on OSS hires someone with no OSS experience - is that going to mean they can't contribute right away?
I suppose the argument could be that someone with experience making OSS contributions has experience in how open source projects operate, how contributions are made, just basically how things work.
But, TBH, projects vary so much anyway that I'm not sure how much that experience adds that couldn't be picked up fairly quickly with some mentoring.
I've all but given up considering finding a new job at this point because even with a solid github project in the target company's language of choice which goes above and beyond their "homework" and/or pair programming interview, they still ask you to do their ridiculous coding test.
I never understood the bias on work attire from both sides. It's silly to judge people's abilities based on what they like to wear period. The whole point of casual dressing in Tech was that it made some people perform better, because it took them less time to get dressed in the morning, and they were physically more comfortable at work. But people are different, some people might genuinely code better or perform better if they wear a suit. The point is to let people wear whatever they're comfortable with, so they can perform at their personal best, within reason of course. We wouldn't want crazy people to show up to work in underwear or naked haha.
On the topic of work attire, one interesting argument/explanation in favor of professional (read: suit) clothing is for the compartmentalization; like Peter Parker becoming spiderman, you only do work in that set of clothing. When the suit is on, you're in work mode. When the suit is removed, you're in non-work mode. This way you don't associate work with your casual clothes. I thought it was an interesting point in favor of a specific set of work clothing.
I like the look of ties, accumulate colorful ones, but I hate wearing them. So I prefer to wear a suit and tie to an interview, and then never again. It's a costume, for particular occasions.
And if you (as a man) don't wear a suit and tie to an interview, you have the problem women complain about - there's too large a spectrum of possibilities for clothing that someone might judge you for unfairly.
But I also like work clothing that isn't expressive; it just has to be comfortable.
This is a pretty interesting point of view. I had always thought that it's just something that was passed down as tradition since it seemed that back in the days, men always wore suits, even when they're not at work.
Absolutely - clothes send a social signal that you're a part of the right group. In London you can not get hired in the City for wearing brown shoes. Not because black is the right colour, but because everyone from the social class that they want to hire from knows about the unwritten rule to only wear black shoes. The same goes in SV for Patagonia vests and Allbirds.
A lot of public code not related to their job being produced by the employees of a company suggests that the work there is not interesting enough and challenging enough and deep enough to keep them occupied.
> If I had my way this would be considered employment discrimination and grounds for a lawsuit.
I took issue with the tie stuff, myself, in another comment. It's unlikely to be discriminatory, except in the case -- as you mentioned -- of things that fall into the practice of religion. It's funny, though, how different sectors view the "tie in an interview". I know of many jobs where failing to show up in a tie to an interview will end the interview before it starts. I think software development is leaning in the other direction. And it's all a bit silly to a lot of us from the sounds of it. Standards exist for a reason -- if the tie-less interviewer showed up in a swimsuit with no shirt, I'd imagine he'd do worse than the guy wearing a tie.
As I mentioned in a previous comment, the issue is that someone is passing judgement on you as a candidate based on information that is unreliable to draw a conclusion from. My answer is to provide that information "My dad was a business owner and beat into my head that 'you wear a tie to an interview', plus I have far too many Jerry Garcia ties for how infrequently I get opportunities for wearing it" (I've even jokingly thanked an interviewer for the opportunity to dust off one of my favorite ties). If that doesn't satisfy my interviewer, I don't want the job. I can't manage a situation where "the rules for success" are so arbitrary/subjective that my choice to wear a very loud tie to an interview was enough to eliminate me from the selection process.
Part of it is probably the Garcia ties, thinking about it. They're very stylish, but bold, so while I can wear one to a really formal event and get compliments, the mention of a tie with a loose relation to The Grateful Dead communicates that I'm not much of a tie-kind-of-guy.
Jerry Garcia ties usually are great and I like an excuse to wear a tie myself. But yes more and more interviewers seem to either expect business casual or dress-code is communicated in run-up correspondence to the interview.
I don't particularly like to wear a suit and would never want to wear one day-to-day.
But I feel vaguely threatened by people who penalize you for wearing one, because it seems like a Schelling point, which is a useful and comfortable thing. It's one less problem that you have to solve to get hired.
Requiring a software portfolio makes sense if you think of programming as an art form. Just about every professional artist has a portfolio of some sort and the current status quo for a portfolio in software is open source projects or code in a public repo (usually github).
I'm totally in agreement that that would be discriminatory. And no doubt hiring managers are sadly looking for quantity and crazy amounts of open source wizardry. But I have a slightly alternative take that might be helpful for folks struggling with this problem of "Job interviews want open source, and I just can't contribute."
I've been on both sides of this table quite a bit as an employee and as someone who hires a lot for like 20 years.
As an employer, what I like to look for when I ask for a GitHub profile is not that I'm seeing an insane prolific coder who will only spend time at work and on my business or "bleeds code". What I'm looking for is a signal that this person has the wherewithal to communicate code to a larger audience. Can they make their PR readable to someone else? Can they ship a project no matter how small that would make sense to an outsider? Can they teach other devs? Can they find things to abstract that someone else would find useful?
Neither are very popular or show off any code wizardry. These things aren't impressive in the least. You might even argue they are dumb and useless. Fine! But both projects have been great conversation pieces when I'm talking to folks trying to hire me.
I'm showing (at least trying to show) those same things I'm looking for as a boss: I look for things to abstract, I take the time to communicate with clarity, I teach other devs, etc.
And as for an organization who says: "Absolutely NO public code of yours on Github or you're fired." First, who are these orgs? There should be a shitlist of companies who wipe out their employees Github profiles. But... this seems to be a lot more rare of a case, and I've worked in a lot of places.
Yes, there's plenty worried about their IP being leaked, but there's plenty of code to write that teaches a concept that isn't near a company's IP. But if you're really worried about upsetting a boss, I would take a crack at talking to someone (a boss, hr person, etc.) who has the authority to take a peak at putting out a project or two like I describe. Since these aren't mind blowing things, but tiny little utilities or ways of showing off a non-proprietary concept, it's very likely you'll be met with yesses. Even that talk of convincing your boss to "YES" about publishing something sounds like a great story to share with a future employer ;)
So I agree, there are folks using open source poorly as a signal, but for those out there with the complaint that "My organization won't let me. Or I don't have time to contribute the amazing things I know I can contribute.", the hurdle isn't as big as you think. A lot of us employers aren't looking for amazing, gigantic, magic contributions to the world. Just a couple handfuls of code to show how you think and communicate with others.
"And as for an organization who says: "Absolutely NO public code of yours on Github or you're fired." First, who are these orgs?"
Well, Fortune 500 companies. But your caricature isn't a literal description. They force you to sign a long document in legalese that says they own everything you make from when you're hired to when you leave, and then people basically ignore it except in very unusual circumstances, because do you really think a company like that has employees that do anything interesting outside their job? Nor is HR going to go above and beyond if nothing makes them. But the agreements exist, and hang over you, and have a chilling effect.
> You see a lot of talk about moneyball, but for some reason people are less excited about… trainingball? Practiceball? Whatever you want to call taking people who aren't “the best” and teaching them how to be “the best”.
I think this is the biggest insight in the article, and the one that's gotten the least traction, both here in this thread and in SWE culture more broadly.
This industry doesn't have a clear way to transmit knowledge and practices, and it DEFINITELY doesn't have a way to do so at scale. HN will debate about interviews (no wait! take-home tests! no wait! ..) all day long, but when it comes to how to make someone a senior SWE, we don't have anything other than 1) set up your dev environment (ideally the same way as I did) 2) dive in for a couple years.
The sad reality is often startups are started by smart but inexperianced founders. They hire smart and hardworking but again inexperianced senior leaders or employees who get promoted into senior leaders.
If the company then is sucessfull enough to grow/scale they need to put in formal processes and hire departments.
This inexperianced managment team often tries to cut and paste processes and demands large companies have. "They are super successful so we should copy that!!!". However what they fail to see is that's a process of a giant unicorn... and theres no way for them to truly follow there process or pay the premiums needed to support it. Thoes unicorns grew on completely different processes/tech/people. This leads to the broken disjointed processes and expectations I see in most startups.
I worked on a big C# system with hundreds of windows servers, developed on Visual Studio etc. It was an awesome project and everything worked like clockwork. However there are very few projects using that technology so when I wanted to move I had trouble getting interviews.
I'm now working with a very fashionable tech stack, its horrible, infrastructure is regularly broken, people can't trace problems easily, our functionality is still not as good as what we had in the earlier project 10 years ago. Still because we're trendy we get paid 2x as much and I get asked to apply elsewhere all the time.
I've given up trying to pick what is the best software platform/language. Just find the highest profile tech company and stick with what they do. Not only are they hiring but all the companies who copy that tech stack want the same.
C# is also the language behind Unity, which beyond games now powers 70% of all AR applications. Since Unity is now expanding into Automotive, Architecture and other verticals, there is a ton of demand for non-game C# devs for Unity.
I interpreted "AR" as "Accounts Receivable" and I was like "that can't be right" but it took me several moments until I thought of "Augmented Reality"...?
Give it a couple years but making .NET Core cross-platform will eventually catch up with the industry at large and we'll start to see more early-stage companies embrace frameworks like ASP.NET Core and bridge the gap between old-school, big C# systems engineers and trendy startup ones.
I'm a C# developer at what I think is a really good dev environment. Tons of smart people here and we're highly productive. I like C# and I honestly feel boring software is better. I can't get behind chasing the latest trends.
Why should I learn Node instead? Does writing backend Javascript mean you're a better developer?
My problem with C# server development until recently has been the reliance on visual studio. A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS.
And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS, but you end up spending a lot of time and energy trying to figure out what might be wrong before going that route.
Fortunately, both of these issues have been resolved with the open source .Net Core, and while we continue to use .Net Framework, I’m looking forward to doing more .Net Core development going forward.
>My problem with C# server development until recently has been the reliance on visual studio.
TBH there are very few IDEs or environments that match Visual Studio. If you've never used it, of course you'll be less productive.
>A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS.
Project and solution files have been XML for a long while. I think the example here would be early UI work with WinForms and WPF? But everyone would think you're crazy to edit those text-only when you had a WYSIWYG editor.
>And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS
>Fortunately, both of these issues have been resolved with the open source .Net Core
If there's an issue with Kestrel, I think you'll still be spending a long amount of time debugging that. I don't think much has changed on that front.
I ran the tech team at a startup around 2014 and we had a C# stack with almost no visual studio. Most people were on mac or Linux and used MonoDevelop. We ran it on Mono in docker containers (which was brand new those days) on Linux VPSes.
Truth is, for a long time already, C# has been a decent boring cross-platform language. The only reason people refused to use it was hype and stigma. There was no deep rational reason.
Sure, mono was slower than .net-on-windows at the time (.net core fixed this), but it was still way faster than the then-default Rails setup.
Whenever I told people about our setup at eg tech events they got very confused. Some dismissed me as a moron but to be honest most people were just surprised you could run a cross platform C# devteam and deploy to Linux. People simply didn't seem to know this was possible. That's been some pretty bad marketing in Microsoft's part.
Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. You can write command-line scripts, run them with "node [scriptname]", and learn.
Having done that, I've found that Node is great for fast prototyping of servers, even if those are going to be written in C/C++ ultimately. In not-super-formal work environment, you can very quickly write something that runs with the correct behavior, and treat that as the spec for the final performant code.
> Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser.
Honestly, to me Node always sounded like the exact opposite of your description: a way for frontend development experience to leak into the backend at least in appearance so that people who were able to hack around DOM updates could argue that they could develop for the backend as well, thus paving the way to pad resumes with "full stack" experience.
To people who only know how to write backend javascript, yes.
I think companies underappreciate this.
If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience?
Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.
> If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience?
> Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.
Blub languages aside, a candidate focusing on how they do things in $LANGUAGE_WE_DONT_USE_HERE means they're going to have to get their feet under them to read our existing code fluently, to write code in our style, and to get all of the other language- and tooling-specific institutional knowledge existing programmers here have.
Your point is taken although I wouldn't say Node qualifies as the latest trend at this point. It feels like it has moved on to "just another tool to choose from" status to me. I suppose trendiness is relative but if you use a Google Trends search for "Isomorphic JavaScript" as a proxy for Node's trendiness[1], it was at its trendiest in 2016 and has fallen off quite a bit.
Javascript is a flexible and fluid language in my opinion. Using modern JITs gets you a scripting language that is many times faster than other languages, but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding.
Lua JIT however is sane, simple and even faster, but the infrastructure and tools surrounding it are bare in comparison.
"but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding".
Huh? Async code is so powerful. You can use promises instead of callbacks. And you can easily make a async call "synchronous" by adding the await keyword in front of it.
You may technically be coding in one language, but JS written for Node looks radically different from JS written to run in the browser. In my experience, there’s rarely more than some small chunks of code that you touch that will run in both environments.
If you get some better tooling for multi-language development, it will usually pay off a lot faster than choosing Node for your backend will.
JS in Node and JS in browser is not that different. It's the same language, using the same JavaScript engine (v8 for chrome). The difference is in the APIs provided by Node vs Browser, which is pretty minor. Many popular JS libraries will run in Node just as well as Browser. That being said, JS is a pretty shit language and I don't know why anyone would want to use it for backend work.
My experience is different. I write a decent amount of JS code each year and try to catch up with current best practices where I can, but every year it’s been a bit of a pain to write any code that’s shared between browser and client. Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async (shockingly, with backend support lagging).
These days my main strategy is to have three TypeScript projects—frontend, backend, and common. I then whitelist imports in the common libraries.
> It's the same language, using the same JavaScript engine (v8 for chrome).
I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
> Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async
New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code.
> I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
> New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code.
For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client.
My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place. Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc. There’s a whole pipeline between your source code and the JavaScript engine, and that pipeline has a different shape for backend and frontend, and typically uses completely different libraries to make it work.
> The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine. I haven’t figured out a way to leverage that fact to give me any additional productivity.
For the projects I’ve worked on, it can end up taking me quite a bit of time figuring out how to make one piece of code work in both frontend and backend, even though I can trivially make it work in either environment as I please.
Maybe other people have already solved this, but I recently went through and made a bunch of PRs to fix a common issue I saw in other people’s codebases and it was super rare to see any code shared between frontend and backend.
> For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client.
You still have to identify which polyfills you need, add them in, test them, etc. Polyfills are also quite buggy especially for new features from my experience. Also, the fact that you're typically running your build, packaging, linting, testing etc. on Node for your frontend code, says a lot.
> My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place.
When is that really even a consideration though? When do you actually need to deploy your frontend app to Node? If you have common model code, or say, input validation/sanitation, business logic, etc - that can easily be identical for both browser and Node.
> Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc.
That really depends on your setup. You can do imports at runtime or build time for both Node and browser. If you're transpiling the setup is pretty much identical.
> I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine.
How do you run your unit tests, your static code analysis, your packaging and traspiling? Do you run it in the browser or in Node? There is no fundamental difference between JS of the same version in Node vs Browser. Any browser specific or Node specific libraries/features you use are generally not part of any stable JS spec.
> it was super rare to see any code shared between frontend and backend.
Well I'm assuming these are different applications, so that's expected. I don't know why you wouldn't share your model definitions and/or validation/sanitation code though. People do this even for backends/frontends written in different languages.
Depends. It sure is nice to write helper functions that I can import on the serverside js and in the client side. Also if you use next or nuxt or something like that you get universal rendering, which is nice. Totally depends on your use case.
You just have to keep an eye on your client bundle size if these shares functions ref something like underscore, moment or something like that where you’re pulling in the entire thing for one function. I’m aware you can just pick pieces with {} and import, but not everyone is aware and often require the entire thing.
The purpose of next (and perhaps nuxt, I've never used it) is more in the direction of a front-backend. The API-implementing level is usually very different than the one consuming it, even when the consumer is on the server-side. If this wasn't the case, IMHO, projects like Meteor would be immensely more popular.
So coding in one language is a BIT of a red herring.
It only works if the paradigms your app uses are the same in the front and back. And I have nott seen a project where the KIND of problems that need solving (in the front vs back) were close enough for the same language to be a benefit.
I mean at the end of the day, I can build a house with JUST a screwdriver, but man, I'd rather use the right tool fot the specific job.
My company uses Node with Typescript on the front and backend; we’ve strongly typed our APIs and thanks to the excellent io-ts library we’ve also automated the marshaling and unmarshaling data as it crosses the network boundary so that we can continue to use the strongly typed data, and also are constrained by the types to only call our APIs in valid ways.
Some subset of that can be achieved with stuff like GraphQL or Swagger and what not though I haven’t given it a serious try since we’ve never run into hiccups yet with this system, reliant on a very simple library.
We also use the same package manager (NPM) on both ends and can therefore invoke scripts all over our codebase with the same syntax; and although react code and node code is quite different in structure, they all have the same idioms and async syntax and stuff, so the amount of retraining necessary to convert someone from backend to full stack isn’t very large due to the same environment, and keeping code style consistent across the project is also easy.
So I feel like there’s definitely stuff to profit off of with sharing a single language.
Reminds me of yesterday's hn frontpager, the paper about a "programble programming language". they were talking about how domain specific languages within a single language become super distinct and ungrokable to people who are otherwise fluent in the parent language. Think like, an angular dev reading nest.js node backend stuff. With javascript this is sorta everywhere. JS DSLs arent like explicitly uninterpretable to otherwise-experienced JS devs but there is a context shift cost for sure.
Ive not worked with c# much, but is that not as much of a problem with it? Like, is there more of a standardized way of doing things? Python is kinda like that i guess.
Node is a total nightmare even if you like javascript. The async everything nonsense makes basic tasks impossible without nesting callbacks within callbacks within callbacks.
> Does writing backend Javascript mean you're a better developer?
Absolutely not. But as someone who does write backend Javascript I don't tolerate Microsoft development tooling because I don't tolerate Microsoft. Period.
When their core product offering is literally adware/spyware (Windows 10) to the point I have to use special builds that are difficult/expensive to get a hold of (LTSB/LTSC) I get pretty turned off in regards to the whole ecosystem.
Microsoft tooling may be right for you, but it is not for me... and Node is an outstanding tool for rapid application development with solid async capability that's open source.
I can also find/hire way ECMA devs way easier vs C#.
Also before someone rips me saying "well Visual Studio is better than everything else" - Intellij offers the same general "nice-to-haves" and doesn't come with a dependency on a broken OS.
Confirming, and far less than two years. If you have good credit, you can get a decent house, 3+BR with 5k-10k sqft lot, within reasonable commuting distance for $250k-$350k with $20k-$40k down which is pretty easy to save up in 6-12 months with a 100k+ salary in Houston.
The downside is that Houston is topographically flat, there's not much to do outside, and summer months are oppressively hot/humid.
There's a lot of cutting edge AI work being done in O&G. It's early stages and a great time to jump on the ship before it sails. Plus O&G companies, even startups, tend to be a little more cushy than the stereotypical slavedriving you hear about in Silicon Valley.
I’ve had this recently, worked at a place that Microsoft uses for case studies and have had a couple of jobs because of where it is - people see Microsoft holding hands on stage and then ask recruiters to get people who worked there
My company manages a little over a hundred (and growing) microservices running on .NET Core a bit of Python and NodeJS in AWS. I don't think there is anything dated or boring about .NET in comparison to say Node. The tools are a pleasure to use. The code is a pleasure to write, test and deploy.
I think this is spot on. When I started in the 90s hiring was more like “you are smart so you will be able to learn”. Now it seems you really have to chase the latest cool stuff all the time or you quickly are marked as outdated. What they don’t seem to understand is that if you are the cool hotshot that’s working on an important project for a while you are almost by definition outdated after a while because you will not work on the latest hot tech. Realistically the best way to deal with is to do resume driven development and have constant churn by replacing frameworks and databases constantly just for the heck of it.
Even better is to either have a degree from a fancy school or having the name of a currently cool company on your resume but be aware that the currently cool company may fall out of favor any time.
A lot of this is pretty specific to web development, I know it exists elsewhere too but I think it's most pronounced on the web and in the javascript community. To the point where javascript has inserted itself into more or less every domain and people look at you confused, asking why you'd bother writing your software in anything else.
The problem is the recruiters - how much justice would it be for someone to start a recruiting agency and say to applicants, 'oh you have recruiting experience? yeah...well, we're looking people with a different skillset.'
I think part of it is also the interviewing process. In general I like the idea of being interviewed by future colleagues but I have been in interviews where the interviewer had a really narrow perspective and there was only one right answer and only one valid approach to problem solving. I think interviewing should be taken seriously as a skill and interviewers should be trained more.
I'm sorry I just thought it would be a nice ironic twist -- recruiters hiring other recruiters has to be like a matter meeting anti-matter. In all seriousness, it all comes back to the client. Having been a hiring manager, one of the things that frustrates me is that HR departments have so little bandwidth to do the one thing that's truly important (hiring) that they have no choice but to treat it like a retail shopping experience: hiring 3-5 recruiters, post it to the job boards and hope a qualified candidate shows up. And then by contrast you see the companies that work at it - they host meetups, they sponsor conferences and they go out of their way to create conversations between hiring managers and people who aren't even looking.
For the specific example given I have turned down many individuals who sound like they have a similar background because they could not figure out how to work outside of their toolchain. I see it all the time with .NET and Java developers, if they are not in Visual Studios or Eclipse they don't know how to even compile their software. Both those ecosystems are fantastic and developers can be very productive, especially in an enterprise setting, but it is rare you can take a .NET developer put them in front of Python or Go and have them actually be able to be productive without extensive training.
Which leads to the second problem. Fenerally I have found a lot of the Enterprise developers to be very resistant to training and change. They don't know how to deal with a world where they have to be responsible for the entire software project not just one small module, and they definitely don't know how to deal with any part of operations like deploying the software or troubleshooting problems. As soon as something goes wrong they blame the tech stack and pine for the days when they could just push a button on Visual Studios and have everything build and test for them without actually understanding what was going on.
So what? Everyone has a chain they are used to. Setup that make file and forget about it is very common, even if they aren’t using an IDE. Yes, I can figure out how to work my tools by hand going through a bit of the references, but no, not in the 45 seconds you give me to answer the question of how to do it.
> but it is rare you can take a .NET developer put them in front of Python or Go and have them actually be able to be productive without extensive training.
There is absolutely no evidence for this whatsoever. The ability to program or not, the ability to abstract, generalize, arrange your code right, solve problems, ask questions, and so on, changes little when the tooling ceremonies are different.
There are definitely a lot of hacks who find one niche or another and can fake it, but it doesn’t mean the real deals who somehow start out on .NET will have crippled career potential.
> There is absolutely no evidence for this whatsoever. The ability to program or not, the ability to abstract, generalize, arrange your code right, solve problems, ask questions, and so on, changes little when the tooling ceremonies are different.
There is overwhelming evidence for this, and its been known to anyone who has had to hire engineers for a very long time. Something like 95% of people with CS degrees can't do any of the things you listed there.
Overwhelming evidence? For such claims, citations are generally requires, or is the evidence all anecdata?
> Something like 95% of people with CS degrees can't do any of the things you listed there.
Again, I don’t think this is born out at all. Yes, a lot of people fail or answer that LeetCode question with that special trick solution in 45 minutes, but we don’t really have any quick tests to gauge actual ability in the hiring process.
I am only aware of one study that found it was actually 97% of full time engineers couldn't write code[1], but I don't think that was a very rigorous study. The best evidence would be the very well known blog post by Jeff Atwood [2] or this article on c2[3]. Also you don't need to ask LeetCode questions, simple for loops can throw most people off, that I know from anecdata.
Anecdotal but at previous job I interviewed quite a lot and found that java devs were as good on coding sessions but did worse on architecture and design / systems. Not particularly surprising really
I agree with your sentiment but it's not good to blame an entire class of people. I've had the same thing happen with devs who were using Python + Django and popular frontend toolchains.
What you hit exactly square on the head is the lack of caring about what is going on. At larger corporations or at places with a rigid developer experience they do only have to care about their small piece of the pie. This especially doesn't exist in startups but people still don't want to learn the tools. Every day I try to encourage my team members to learn more about what npm actually does, for example. I think it's just a personal preference toward priorities. I like to understand the ins and outs of my tools.
I agree that you can't typecast everyone who has worked in a specific platform. There are lots of high quality developers out there working on all sorts of things, and as an industry we put too much emphasis on resume's which can't really display what you actually did at a company
I think you are projecting your biases. A developer that has 10 years of experience solving problems, debugging though issues can learn faster the cool language of the day then a 1 year dev can learn the 10 years of experience.
Its not about learning the language. Take a Java developer who is used to Eclipse and tell them from now on they need to write Maven files directly and learn how to build and test from the CLI because thats how your CI works. Same thing with version control. I am always amazed at the number of development shops that still work by emailing around zip files with code in it, or places where the only place you can build software is on a developers workstation. There is so much more to software development then the language you use.
That Java developer might have started out using make anyways, and this is would be the 5th or 6th build system they are going to have to learn how to use anew. It isn’t really weird since build system fads change faster than fashion.
But if you really don’t want to hire someone, just ask a few esoteric GIT questions.
I work for enterprise companies for many years. All maven/gradle files are modified manually, builds, tests, checkstyles are run from CLI. IDEs are used for writing the code.
I think you are still generalizing, say you bring me in your project, is your job to let me know how to integrate in your tools, there are too many tools out so I can learn them all. Like in Web when we bring a new developer we don't expect them to just start coding , maybe they did not used gulp but some other similar tool, maybe they did not used less but used css.
I am not sure why you would generalize that most Java developers can't use CLI tools or a VCS, there are some bad developers in the world and some of them are also writing shit in cool languages and spam everywhere some toy project like a TODO app and you see it upvoted just because is in Rust/GO or Shiny.js 7.0
One data point but I have a ".NET background", primarily write "Enterprise software" in Windows stacks, but although I have a Windows Amazon Workspace at my disposal my daily drivers are Linux and Emacs.
That said I haven't really observed this phenomenon among any of my coworkers who run on Visual Studio and Windows full time. I think experienced devs who care about their craft enough to know a modicum of computer science understand what is happening "under the hood" when tooling like Visual Studio abstracts build steps away from them, or at least enough to be able to manually replicate it themselves if needed.
I don't want to contest your personal experience, however I find it very hard to believe you could work in an enterprise environment and not know people like the one's I have described. I have met these kinds of people at all the FAANG companies as well as every single software development firm I have worked with.
I have known people like this, but my point (poorly articulated) is that I don't think these biases against enterprise devs who happen to have experience with a particular toolchain are appropriate, since not all enterprise devs are like this, and, as others have mentioned, they aren't unique to developers with experience in those technologies -- for example, I've run into this issue pretty much exclusively with folks on the data side (not in the company I work for) using Python via Jupyter Notebooks and R via RStudio.
Anyway -- I think it's fairly straightforward to filter these kinds of people out of your pool without going the nuclear option?
One story that I always remember is a company in financial services. They only hire Oxbridge. For decades, 95% of the senior staff went to Oxbridge. They were, according to themselves, the elite.
Unf, and maybe not surprisingly, they are infamous for blowing up every few years. You name the hot, new trend...they will be balls deep and a few years from total destruction.
After going "all-in" on Japan in 1989, they were feeling a bit sheepish and decided to do something extraordinary: hire a poor person. The guy they hired went to the local uni, very smart, and the definition of self-starter/independent thinker. Within three years, he was out. Hired instantly somewhere else, and went on to make tens of millions (retired in late-40s).
The point is: actual ability does not matter to 99% of companies. This guy was one of the most able employees possible, he could have made literally billions for his first employer but that didn't stop him getting canned because he was an independent thinker (despite only hiring from Oxbridge, this company is known for having a "group-think" culture...work that one out). You can definitely make money from this inefficiency - turning 0xers into 1xers - but most companies are actively choosing not to do this.
I know of another company in the same industry that hires front office staff out of a single pool that rotates through operations/sales/marketing/etc. Pretty much exclusively hire from non-targets, focus heavily on training/teamwork. They have acquired pretty much all of the competition local to me: they come in, fire all the Oxbridge guys, and move their teams in. In the 80s, they managed a few million. Now they manage half a trillion.
This model works...but try telling someone that went to an elite uni that they could hire someone with half the training, at half the cost, and get (at least) the same result...they will never believe that (and, unf, tech has almost the same dynamic as finance where some people believe that having a certain piece of paper means you are better at everything).
Does anyone else find it out that the people (recruiters) in charge of finding good tech talent often have no experience in programming themselves? So, my question is how do they know if someone is a good programmer?
If all they do is read the resume, then we know, based on other people's comments here, that it's clearly not good enough of a method to find the best talent. So, if this is the case, why do we keep relying on recruiters to find us talent?
You need to present yourself as whatever image the employer/recruiter has in her/his head. For example my old employer thought that people who had their heir in a certain way was more structured and would be a better manager. Or the company might want do diversify, so they look for someone that is different. So in the end I think it's mostly about luck unless you are very good at figuring these things out.
Very true - there are often unofficial qualifications that aren't listed in the job posting too - things that would be strange to put into the official posting. We were hiring an analyst at my old company who needed to be tough. The job entailed performing statistical analysis, but also being the data liaison for some of our vendors. If the vendors were slow in responding or broke something, this analyst was the one responsible for getting them to behave.
We passed up several people who would have been a _great_ analyst, but definitely couldn't have managed the vendors. It got me thinking into how much of the hiring process is based on luck or other external factors that the candidate has no control over.
> It got me thinking into how much of the hiring process is based on luck or other external factors that the candidate has no control over.
Cue the old saw about how a hiring manager takes a stack of resumes, divides it in half, and then tosses them into the garbage: "we don't hire unlucky people".
Surely there's a way to wordsmith an expectation like that into the post. Off the top of my head, you could include a bullet along the lines of
- Responsible for advocating for the team's needs in liaison with vendors
Although doing so kind of points out the fundamental problem: that you probably shouldn't expect a data nerd to do this. Ideally you'd have an account manager of some kind with just enough technical understanding, but who's actually a negotiation/people person.
Yes the reason we decided not to include that in the post is that it wouldn't account for very much of the person's time, but it could absolutely produce a hang up if handled incorrectly. We could also have had an account manager to handle this but they would really just have been forwarding technical specifications from the analyst, and wouldn't have much work to do.
Superstitious practices are the hallmark of highly luck-based tasks, and it would be difficult to describe most hiring practices at these kinds of companies as anything but superstitious.
> They have a few experienced hires, but not many, and most of their experienced hires have something trendy on their resume, not a boring old company like Microsoft
Is this how Microsoft is perceived on the coasts? Here in the Midwest if you get a chance to work at Google, Microsoft and Amazon you've pretty much "made it" in your career.
The comment hasn't gotten better with age. There's a lot more respect for MS ever since they started their push to be more compatible with the non-MS ecosystem and developers coming from that ecosystem.
> Unlike me, he doesn't know a lot of folks at trendy companies, so I passed his resume around to some engineers I know at companies that are desperately hiring. My engineering friends thought Mike's resume was fine, but most recruiters rejected him in the resume screening phase.
I agree with the overall premise that people with particular trendy areas of knowledge get more noticed, but in my experience, a strong enough recommendation from an engineer on the inside can easily override a recruiter screening checklist, and it sounds like your friend has enough experience to warrant a technical phone screen at the least.
I wonder if your engineer contacts at the company in question didn't feel as strongly about the candidate as you did, and hence weren't willing to expend the capital needed to override the recruiter.
That raises the question: are you willing to spend the capital to convince them to do so on your friend's behalf? I mean by talking to them and convincing them. If this article is the attempt to do that, I'm not so sure it is properly directed.
> Wisconsin's rank as an engineering school comes from having professors who do great research which is, at best, weakly correlated to effectiveness at actually teaching undergrads. Despite getting the same engineering education you could get at hundreds of other schools, I had a very easy time getting interviews and finding a great job.
Ah yes, the reputation cartel of elite universities. This is a situation as old as formal education, and exacerbated by the cost of higher education and the inequality of opportunity in early education.
A solution to this is making quality public education from primary through University affordable and accessible to all working class people, just as was done for a specific subset of working-class people in the decades after world war II. That was the original purpose of the public university system after all - the wealthy had their system of private colleges.
Instead, the public university system has turned more to the model of elite private universities, which was more about burnishing credentials in order to retain the position in the class that you were born into. Hence the coining of the phrase "elite public university".
Here's what recruiters see: 1) Oh, it's not the same tech stack, our client isn't going to want to look at this, 2) This person either can't dedicate themselves to one career or is taking any job they can find. And the client sees 3) Our past contractors have built the crappiest products that aren't in sync with our patterns.
I basically work for RegularCo. And I can tell you, the one person they don't need any more of is a "Chad". They have so many "Chads". I'm sure you know one; white hetero male, 20s-30s, christian/atheist, good education, lots of opportunity, all using the same tech stacks that follow the same trends, no leadership experience, hyper-focused on technology rather than what it's being used to accomplish. If they have SV experience it's usually for a higher-paying, trendier job than they advertise for. They're obsessed with the best practice, the latest and greatest, and they get visibly upset when this isn't the case. RegularCo just wants to ship something.
All recruiters would send us is "Chads". We'd beg (and even threaten) them not to send any more god damn "Chads", and still that's all we got. We'd even look for alternatives on personal time.
You know who we wanted? Old, queer people of color. Junior People with 15+ years experience. People just getting their start. People with diverse backgrounds. People hungry to learn and build things. And most importantly, compassionate, ethical, sane people who want to cooperate and get things done. It is depressing how hard this is to find.
RegularCo isn't based in California or SV, doesn't need to impress VCs, and almost nothing they'd use is trendy. They're a regular company that uses regular tech to make products. But they don't want to hire another "Chad". Unfortunately, they have to hire somebody, so they end up settling for "Chad" after holding out for a year.
Ultimately, what the recruiter wants is different from what the company as a whole wants, and may be different than what a specific team may want. A single resume may get passed around within a company a dozen times over a year until somebody has the budget and timing to hire them. It's really stupid and there's no simple solution for it.
Sounds like a problem with recruiting, which isn't that surprising to me. As I've ranted about before, great recruiters are worth their weight in gold. On the other side of things, subpar recruiters are a risk. At best, they'll bumble around and never find you appropriate candidates but at worst, they'll actively alienate candidates that could have been a great fit.
It's a high risk, high reward profession. For some reason, you see a lot of clowns in it -- it always confuses me and has me convinced that executives and hiring managers don't fully understand what they should expect from recruiters and how to find an effective one.
This focus on key-words is brain-damaged. Tech details (keywords) come and go; what matters is the ability to learn them, make good decisions, get work done.
Recruiters have an excuse, in that they are largely ignorant. But the tech managers using them have less of an excuse.
"Google bigwigs regularly talk about the hiring data they have and what hasn't worked. I believe they talked about how focusing on top schools wasn't effective and didn't turn up employees that have better performance years ago, but that doesn't stop TrendCo from focusing hiring efforts on top schools."
As far as I know, that doesn't stop Google from focusing hiring efforts on top schools.
Anyway, I'm actually wondering about the future. Suppose you are one of the people hired out of school for $200k+. What happens in 10 or 15 years when you are no longer the shiny new thing, don't have the trendy skills, and have been working for boring companies? Do you still command a 2× salary (https://www.ziprecruiter.com/Salaries/What-Is-the-Average-So...)? Reversion to the mean? Salary cuts?
> Suppose you are one of the people hired out of school for $200k+. What happens in 10 or 15 years when you are no longer the shiny new thing, don't have the trendy skills, and have been working for boring companies?
I know several people like this. They'll either progress into principal tech level at the same or similar tier companies, or at worst retire. Unless the bottom falls out under the market those people aren't going to revert to the mean.
...and to be clear, the stuff Dan discussed doesn't really apply if you're one of those people hired for $230k new grad at Google or Facebook or Stripe or Lyft or whatever. Just the name is enough at that point.
>But if you think programmers aren't elitist, try wearing a suit and tie to an interview sometime.
My first interview at a startup I was coming from an east coast finance and healthcare engineering background.
I wore a suit to the interview.
At the end of the interview the hiring manager said “we are going to make you and offer, but don’t come back in a suit go buy some comfortable clothes.”
I always have a hard time deciding whether it's sour grapes or an actual problem when I read these posts. The mid tier startups should all be flushed out in a few years if they make such poor decisions, both in hiring and their tech stacks. For the giants I can only say - google and fb stuff works, even if you don't like their culture or morals so how wrong can they be in running their businesses? Over the next few years I'm assuming that the industry as a whole will mature and things will become more stable and sane.
I don’t think he’s talking about Google and Facebook as their foundation was built a long time ago. It’s about the thousands of startups cargo-culting on their hiring practices when their finances and needs are very different.
For those curious like I was as to when this was published, this is from March 2016. (The date isn't listed in the article, but if you search through the archive you can find it.)
This perspective reminds me a lot of the philosophy behind moneyball. You pay for players who are likely undervalued, not necessarily the highest valued players, because the highest valued players are too expensive for a smaller team to get when competing with the Yankees or the Red Sox. I think this probably applies to eng hiring.
> "who was tragically underemployed for years because of his low GPA in college. We declined to hire him and I was told that his low GPA meant that he couldn't be very smart"
I need some advice related to this. Years ago, I started undergrad at a top school and had a full ride. Unfortunately, I fell ill, which lead me to fail most of my classes. After losing the scholarship, I dropped out, started a few companies, and made enough to pay for my education. This time around my grades are great, but my GPA is still trash.
I'm terrified I'm going to be judged and overlooked because of this.
Do you all have any suggestions as to how I should deal with this when approaching employers?
Just leave your GPA off of your resume. I was surprised to read that in this article, my GPA wasn't great but I've never been turned down for a job because of it. In my experience, companies only ask about your transcript if you're a new college grad.
Agree with other responses that you really just shouldn't volunteer it. But if you're finding employers that you want to work for insist on seeing your GPA, you can reframe which part of your educational experience you calculate it based on.
- If you got an AA with a low GPA but a high GPA in the last two years before the BA, just give it for the last two years and say its a different degree program.
- Ditto if you re-enrolled at a different school. Many schools only consider your GPA at that school for the purposes of reporting it.
- Or if you went to grad school, just share your GPA from grad school. If I see a 4.0 in an MBA program I'm not going to ask what the undergrad GPA is.
If its really causing a problem there are one-year Masters.
My advice would be to not volunteer your gpa or transcripts and to avoid companies that want them. Apart from government jobs I haven't found very many that need a transcript
I've never mentioned my GPA to any job I've applied for. If they want that information, they can verify my degree while they do the background and credit checks.
When I worked on software for originating student loans, it was easy to pull that information from a web service we used.
My diagnosis is that almost nobody knows how to hire programmers. Recruiters don't know how to hire programmers. MBAs certainly don't know how to hire programmers. Even many programmers don't know how to hire programmers. Good programming sense is an art, and it's really hard to evaluate it in someone else without truly grasping it yourself.
So in the absence of real criteria, like a poorly-trained ML model everyone just latches on to superficial signifiers that have worked out in the past, and that local maximum probably gives them slightly-better-than-random outcomes, even if it's far below what it could be.
Is contracting on your resume really so bad? I recently made the jump from FTE to contracting because I've always wanted to and it's great. The compensation is higher and I can work the way I want to (put in a ton of effort to get something done, get paid for actual time put in and then move on to the next thing or take a break for a while to play with my two young kids).
In general, yes, it tends to be looked down on, particularly if it's most of your history. Obviously there are exceptions, but as a general rule, people will assume you are contracting because you could not get a full time position. This is more true at big tech firms that don't hire contractors for "core" engineering roles.
This was a great read and I've seen this kind of thing first-hand at a few companies I've worked/interviewed at.
> Wear a suit and tie to an interview
That's a personal test of mine. I have never showed up to an interview without a tie. My dad was a small business owner in a manufacturing sector -- he was the hiring manager -- everything I learned about job interviewing I learned from him and the first thing on his list -- being a previous generation in an industry outside of software development -- was "you wear a tie". There were various reasons given for this. Maybe its the area that I live in, but I've never had difficulty explaining away the tie whereas I know of a few folks in the area who, despite the environment being stricly "dress-down", still expect interviewee's to wear a tie[0].
It's easy to write off with a little transparency and careful humor: "Sorry for being over-dressed. My dad was a business owner and somewhat beat into my head that dressing up for an interview communicates that you want the job. Plus, I love Jerry Garcia ties and have far too many of them for how few opportunities there actually are to wear a suit." Nobody wants to be judged negatively about their appearance, but we tend to make sweeping judgements on that single variable alone -- by adding a little additional information, you eliminate the rabbit-hole of "is this guy going to be a rigid pain-in-the-ass about everything because he insists on over-dressing for an interview?" with "he's actively trying to make a good impression"
Another thing that tends to get lost in the whole "are they a good culture fit" is "is your culture all that great in the first place?" When interviewing people, shortly after determining that a candidate might actually be able to do the job, we tend to fall right into "Will I actually want to work with this person day-to-day". Someone who doesn't fit perfectly into that mold will cause anxiety. But what if the thing that "didn't fit with my teams' culture" is something that your team would benefit from? At a recent job, I was told that the ultimate decision for every employee being hired fell to the founders of the company in consultation with the people who interviewed the developer[1]. The question we're asked is "How will this person make us better?" It sounds fluffy, but it changes how you think about a candidate -- it says "I'm hiring not just to fill a need, but to bring this individual, along with their life experiences, into a team with the goal of all of us improving."
As far as the "personal test of mine" is concerned, I'm perfectly OK with being passed on for a job where my tie and explanation didn't satisfy the interviewer that I was a good fit. Chances are one of two things really happened (1) I wasn't right for the job for a lot of other reasons, but that's the one that was presented (if any were, at all) or (2) a place that would judge me negatively on something so unimportant is a company I'm going to have a difficult time understanding and succeeding in.
[0] This is stupid bit it happens. It's unlikely to disqualify someone, outright, but at these shops, a tie is a plus.
[1] And after a year of being there, I did a few solo interviews and can confirm that "it's true!"
I understand that 'culture' is more important, the smaller the group. You have to get along with everybody in the group, or conflicts quickly take valuable time that should be moving the project forward.
But this often devolves into discrimination. Everybody from the same socioeconomic slot means cliques, doesn't it? How can it not?
We used to have something called 'professionalism', where you worked with somebody in a role because, they had that responsibility and you had yours. Not because you could hang out with them.
I don't know that it always leads to illegal forms of discrimination.
First, defining the term -- when you're interviewing, you're discriminating. When you choose one person over another, you're discriminating between those two people. The question is whether or not the form of discrimination is legal, and accurate. Both should be true.
Looking at my own team as an example, there's a guy who's a mid-level who got his start from a boot-camp (30s), a 20-something with an advanced degree, an older[0] from (I think) Russia, we had an Iranian recently leave (for a better position -- she loved the job).
We're a relatively small shop (about 100 or so) but as someone who's given a lot of these interviews, and probably seen every resume of every candidate who came on to our team, we're pretty consistent. About 10-15% of the people who submit a resume are women, about 10-15% of our team is made up of women. Ethnic race/nationality matches up similarly. A shop our size "can't do more to recruit women" before we "do more to recruit ... human beings" We haven't enough budget to do much more than explain how great it is to be on our team[1], lay out the skillset we're looking for, and hope resumes show up[2].
[0] There's some form of -ism that keeps me from ever speculating on the age of a woman, but she is probably older than me.
[1] Yeah, that sounds buzz-wody, and there are lousy parts to any job, but there is so much upside to the work I do, the company (and people) I work for, that it's hard to contain my own enthusiasm for it. And no, we're not actively trying to make the world a better place by "insert thing that couldn't possibly impact the world in any meaningful way". We're just making neat things all day. It works for me -- might not work for everyone, but I include that last bit as part of the enthusiasm.
[2] Most of this is through anecdotal observation, not hard data, so I concede in advance that "I'm wrong on the Internet" :)
Lets not go in the direction of semantics - discrimination used in this context has a clear meaning - penalizing a protected group. To hire folks that can be friends with the quorum, means excluding folks who can't. If systematically applied, it probably means excluding entire ethnic, economic or social classes.
Ageism isn't a problem where you work - that's great. Nice upper-class educated people are doing well too - Iranian and Russian immigrants are generally like that.
Assuming the women applicants are identically distributed as the men's (a huge assumption) then those statistics matching is a good sign. If we ignore that 50% of people are women I guess, and only 15% of applicants are. So many women leave our industry (don't know what industry your company is in) the applicant pool is already selected for those who can hack the bro culture. It takes 'affirmative action' to get real parity there.
Hiring is hard, and I understand its an onus on the company to make efforts to find qualified minority candidates. But its also a reason to make an effort. Because there is a pool of overlooked candidates out there, who are not showing up in your middle-class neighborhood with resume in hand.
That's not the rule in my experience. There is tunnel vision in the technical interviews.
You get the tech wizz that has spent his 2 years of experience studying java memory model and think with your 20 years of experience you should know everything he knows. So you get to talk for 2 hours about JDK implementation details, optimisation of algortithms, the mandatory compiler questions or other he remember from uni. Because you worked last year on a big migration to the cloud that included as a minor item a JDK 11 migration, you need to be aware of all the garbage collector options and algorithms that he so wish to use when they eventually migrate the stuck in Java 6 app the position is for.
So the guy is disapointed, and sure that's not what you are supposed to be hired for, but that's a black mark on your set of interviews and if they don't need to hire immediately you get passed on and understand why the job offer has been opened for 6 months.
>When I started programming, I heard a lot about how programmers are down to earth, not like those elitist folks who have uniforms involving suits and ties. You can even wear t-shirts to work! But if you think programmers aren't elitist, try wearing a suit and tie to an interview sometime.
I am sure this is not a literal "going out for a beer", but still it bothers me that it exists and is called that way. I am 40yo (still junior though as I started learning to code at 37) and I don't drink.
I like to work on startups because I like to be generalist and solve problems that impact the fate of the company. So I always work with a lot of young people that like to go out. It is always a mismatch that I rarely go out with the team, and sad that this "go-out-for-q-beer test" is considered normal in some places.
The clip itself is from a TV show that, from what I can determine, was originally broadcast on the 22 of February 2009. Know Your Meme dates the clip’s use as a meme to as early as May 2011¹. If you have an earlier reference, I’m sure they would appreciate being informed, if you can give a link to to it.
You can also go-out-for-a-beer and not order an alcoholic drink. I've never met anyone who had a problem with someone for ordering a soda, especially if you say you don't drink. Go-out-for-a-beer can be any social event just to see if you'll get along with a team easily, or if it will be too much of a culture difference.
Where I work, when we interview someone on-site the team they'll be working with takes the person out for lunch somewhere and spends an hour or two getting to know them.
My university's career coaching always told us to dress at the level of the workplace + 1.
I think this is a good rule. You look good, but not awkwardly out of place. Perhaps it's an unfortunate social rule that we shouldn't have to follow, but I've learned to shrug my shoulder to a lot of such rules and just go with it.
Ask the recruiter. This is a common question. I've had them blow it off as dress nice but I usually ask them to tell me what the hiring manager is wearing (recruiting often dresses nicer)
If its a software company then I'd guess the default is T-shirt and jeans. If its doing software or tech inside a larger business organization then it may be business casual (khakis, collared shirt). You may be able to check the companies website or social media accounts to find pictures of the workplace.
If all else fails or you still aren't sure just ask the recruiter.
I hate the anti-suit thing in SV. Suits look great, you feel great wearing a good tailored suit, and honestly with so many engineers wearing the "unicorn uniform" of Supreme and Common Projects, it's not like they can't afford a suit anyways.
Maybe if it's 50° F indoors. I agree that there shouldn't be a pointless stigma against some outfit, but there also shouldn't be a pointless requirement to adhere to useless standards.
Jacket can be burdensome, if your shirts fit properly a tie isn't so bad, and, as Neil Stephenson pointed out in the book Cryptonomicon, well fitted dress slacks are actually quite comfortable.
Most people get button up shirts with the neck size a bit small so buttoning them for a tie and it really is unpleasant.
Maybe you feel great wearing a good tailored suit.
I personally find suits uncomfortable, even when they fit well.
But it doesn't matter. Wear what you want. I've worked at a bunch of places where people would wear suits to work sometimes, despite most of the people wearing jeans and a t-shirt. You'll just have to put up with the occasional "Oh, are you interviewing somewhere today?" jokes.
Twenty two years ago I wore a suit and tie to my first going-to-graduate-soon interview in the valley. It’s just what I was used to from DC.
It happened that my interview was on Halloween so I joked that it was that once I realized what was going on but still, extremely awkward and set the tone of each interview poorly.
Every time I go to Defcon or similar conferences, though, I think of that interview and imagine the hilarious counterculture opportunities of showing up in something other than the black t-shirt uniform.
Speaking of Halloween, in the late '90's I wore an Anderson Consulting polo shirt and khakis as my costume to a Halloween party. Multiple people approached me trying to get an inside track to getting hired there. My wife and I still laugh about it.
That's the kind of ultra generic advice bordering on truism. Without knowledge of exactly what that startup expects, it looks like (and the rest of the article enforces this) the only generically safe choice is jeans and sneakers. Suit is clearly defined as overdressing.
I can assume flip-flops would be a case of underdressing but I think that would be a bit ridiculous for any kind of interview regardless. So honestly, what's underdressing when it comes to such a startup interview?
> I can assume flip-flops would be a case of underdressing but I think that would be a bit ridiculous for any kind of interview regardless.
That's what I said in my comment but would anyone reasonably show up like that in an interview? A suit may or may not be overdressing but flip-flops or anything like that would definitely fall below just "underdressing". It would just be unreasonable and offensive if you ask me (and you could give any number of such examples that may be even worse).
For all intents and purposes jeans and sneakers already is the lowest reasonably acceptable way to dress for an interview, right?
>For all intents and purposes jeans and sneakers already is the lowest reasonably acceptable way to dress for an interview, right?
I would think so.
As for jacket/tie (or even suit) I take it as signaling that this is a professional interaction that they take seriously and have gone to the trouble of dressing up for. I know I'm not part of SV culture but I can't imagine dinging someone in an interview for dressing up, especially when that would still expected in quite a few places.
I also know a number of people who dress up for speaking engagements and it's just sort of part of their style.
FWIW, last time I interviewed (and took the offer), I wore a jacket and tie to my interviews even though I knew that would be a step up from the business casual or business casual with jeans that the people I'd be talking with would be wearing. I didn't need to and it didn't matter one way or the other but it made sense to me.
At Google I've interviewed candidates wearing flip flops and shorts in the summer. I barely noticed, and it didn't affect my thinking on them. Some people dress up, some don't. This isn't "wear whatever you want to an interview" advice, but a datapoint of "I can think of people doing that, and it was fine".
> barely noticed, and it didn't affect my thinking on them. Some people dress up, some don't.
Of course this doesn't say anything about their technical abilities. But showing you care about the interview matters and flip-flops don't send that message. It's basically as close to no effort as it gets while still being allowed in public. I'm sure you'd find the same as a sign of unprofessionalism in many other fields even if the clothes have no effect on performance.
> But showing you care about the interview matters and flip-flops don't send that message
I'm not looking for candidates to show that they care about the interview, or that they have put effort into preparing for it. I'm looking for them to show that they can take a verbal description of a problem and turn it into something concrete enough that they can solve, that they can think about algorithms, that they can code.
> I'm not looking for candidates to show that they care
I'm sure gut-punching you also doesn't change the fact that they can think about algorithms and code. But it does say something about them as people and their character. Showing they put effort in preparing for the interview suggests they put effort in preparing [period]. I've seen plenty of exceptionally qualified people that were a net loss for any team due their attitude. I imagined that as an interviewer you already saw that interviews consist of more than just technical skills (there were probably other people in that panel looking at those other things specifically).
In life, and interviews, it's not just what you say but also how you say it. ;)
I think gut-punching your interviewer is a strong negative signal about how it would be like to work with you, but wearing informal clothing is not much of a signal at all. There are just so many different reasons someone might be dressed that way: they could be the kind of person who doesn't put effort into things, they could think dressing up for an interview is cheating, they could not care about clothes in general, they could have been going off of advice to "wear something comfortable".
Similarly, if the candidate brings their own water bottle vs asks for a drink you could say that this is good because it shows them being prepared, but I think all of this is just too noisy to read anything into.
(I do think in other fields things are different. I'm just talking about programming here.)
Are you wearing flip-flops when you interview them? Do you tell them in advance to feel free to wear flip-flops?
> but wearing informal clothing is not much of a signal at all
You just moved the goalposts. I didn't say "informal is a problem". I said "jeans and sneakers already is the lowest reasonably acceptable way to dress for an interview" and "flip-flops or anything like that would definitely fall below just underdressing". This signals that you may believe you are too good to wear for an interview anything more than you'd wear when taking out the trash. And believe it or not that's exactly what myself and so many others noticed in practice. Many of those people do actually turn out to be very good, maybe even some of the best in the team. But as I said above they were finally a net loss for any team specifically due to this attitude.
And yes, bringing your own bottle of water would be the norm if asking for one was seen the same as asking the interviewer for a pair of decent footwear ;). Is it the same?
> they could think dressing up for an interview is cheating
Wearing jeans and sneakers instead of flip-flops and trunks is not "dressing up" in anyone's book.
You're taking the most unreasonable interpretation of everything (not just as hyperbole like my gut-punching example) and moving the goalposts just to make your point.
> Are you wearing flip-flops when you interview them?
Yes, in the summer I wear flip flops when I interview people. Flip flops and shorts are within the range of regular informal clothing at my workplace, and people don't dress differently on days when they're interviewing people.
> Do you tell them in advance to feel free to wear flip-flops?
I don't talk to them in advance of the interview. I'm not sure what recruiters/friends/etc tell candidates about what's customary, but I do think many people get advice like "you don't have to dress up, wear whatever you normally do".
> You just moved the goalposts.
I'm not trying to move the goal posts. I'm still talking about flip flops and shorts.
A suit costs way more money than t shirt and jeans. And people will know if you only have one suit, and people can eyeball if you have a bad suit — it’s like an advertisement for how low class you are, and it is in fact embarrassing and reflects on your credibility for those who don’t know you. That’s not something you control.
The casual look is as low a hurdle as you can make it. Complaining that you don’t walk in like it’s Goldman Sachs is a bit silly. What a deprivation.
Honestly go to any large unicorn or many FANGs and those T-Shirt and jeans are often a $200 "hypebeast" style shirt, $200 raw denim jeans, and $400 sneakers. I mean, I'm guilty of owning more than one of those items but I think it's dumb to claim that wearing t-shirt and jeans is much better in this regard.
> I hate the anti-suit thing in SV. Suits look great, you feel great wearing a good tailored suit...
Tailored suit? Seriously? Does that not smell like luxury? Why is that part of the discussion for workplace uniform?
A college student wearing a hoodie given for free by TripleByte doesn't look bad at the world's largest software firm. If you wear a t-shirt I cannot tell if you graduated from Stanford. But if you're a young man aiming for the Big 5 accounting world, your friends would advise you to own a battle wardrobe.
Wearing a bad suit is embarrassing, and people at the upper echelons of the company almost always have better suits. It is a smell of class.
> Tailored suit? Seriously? Does that not smell like luxury? Why is that part of the discussion for workplace uniform?
You can get a suit off the rack for $200 and have it tailored at the time of purchase for maybe $20. Your mileage may vary, but that doesn’t smell like luxury at all to me. It sounds like a reasonable thing to own for people in office jobs. It is de rigueur in many parts of the world, including certain software engineering jobs in the US.
The suit will last longer than your $500 phone, too.
> Wearing a bad suit is embarrassing, and people at the upper echelons of the company almost always have better suits. It is a smell of class.
It doesn’t take much effort or cash to escape from “bad suit” category. I don’t begrudge people wearing better suits, it’s just one of a million ways people use to suss out money or class. Wearing a suit doesn’t make you more of a participant in class warfare than you already are.
Some people also use the suit to escape racial profiling. A white dude can get away with wearing a hoodie and jeans to work, but even though it’s acceptable at work, darker-skinned folk can run into problems with the hoodie-and-jeans outfit on their way to and from the office. Now, you can lay blame for those problems how you like, but think of the suit and tie as:
// FIXME: Temporary, remove suit when problems
// with racial profiling are addressed.
Wearing a suit is armor for race specifically because of its association with money. Race is dangerous as opposed to merely inconvenient for some because of the association with poverty, desperation, and crime. I still remember the term super-predator when it was the hot political term.
Thus any symbol of class will always be a suit of armor for race in the way you describe, including Apple hardware. But the reason why Apple hardware is as much the same armor is because of thoughts around race and its connections to poverty, desperation, and crime.
You can wear Apple watch in and out of the office. But why shouldn't t-shirt be the status quo culture of the office? Because those who are judged by race need extra symbols of wealth to wear so they don't end up wronged? So let us band together and create sufficient distinctions of class so that those who make it out can show how they've made it out? How else do we know the Trayvon Martin from the thug?
> But why shouldn't t-shirt be the status quo culture of the office?
Any response to this question shorter than a hundred pages is going to do a disservice.
Because you asked: Because people are judged unequally for wearing a T-shirt. Because this fails to delineate between work attire (and spaces, modes) and personal attire (spaces, modes). The delineation is important. Because attire communicates, among other things, what you think about the people around you, and I dislike the message sent by wearing a T-shirt. Because the T-shirt is a symbol of Silicon Valley technology culture, privilege, and entitlement which I reject.
This kind of communication is not denotative, but it is full of information and intent, and interpreted differently by different people. Yes, it also encodes class, but so does every other form of communication, and attire communicates so many other things.
> Because the T-shirt is a symbol of Silicon Valley technology culture, privilege, and entitlement which I reject.
Why is this that solid of a fact to you? If you had to imagine the best way to scale a workforce, and you were worried about artificial barriers, why is not the suit which reeks of gate-keeping? How is it the t-shirt, which just about every young American owns, the culprit of privilege and entitlement?
I agree that the signals of money or power is an armor against racial judgments about criminal risk. I just don't agree to sustaining the gate-keeping as the necessary moral price to pay. In fact, if this armor is to be depended on, then its quality depends on the degree of gatekeeping. We are after all saying it is problematic if there isn't a visible symbol to show you're not one of the bad ones.
Have you been to an office where the dress culture is divided into two? I find it happens even to startups the size of 30. When the executive business class meets together for lunch or causal conversations between the hours, the concentrated signal of high quality suit is really loud to me.
In such mixed dynamics I have found the suit to be the signal of executive power, and the same to be true when the company is large enough for in-house legal. That is why I question why you are so confident that it's the t-shirt that's so elite.
In such mixed dynamics, you're never going to find it's the programmers who wear suits and the executive class look like young teenagers in hoodies. Who has the power here?
> That is why I question why you are so confident that it's the t-shirt that's so elite.
I don’t say that, at least not in that sense.
> In such mixed dynamics, you're never going to find it's the programmers who wear suits and the executive class look like young teenagers in hoodies. Who has the power here?
This conversation loses too much insight when we flatten things down into a single more power / less power dimension.
I will say that the programmers I see wearing T-shirts are earning $100k+, and they can work remotely, have a flexible schedule, and often ditch meetings which they don’t feel like attending. They go to a café and order coffee from a barista who wears a uniform and may not dye their hair an “unnatural” color, who earns $25k and doesn’t learn their work schedule until the last minute.
The suit, at least, if you wear it every day, can communicate “this is kind of uncomfortable and ridiculous, and as soon as permissible, I will take it off.” I can understand why some people would see it as a conceit, at the same time, to the people who must wear suits, it is generally annoying or inconvenient more than anything else.
> In such mixed dynamics, you're never going to find it's the programmers who wear suits and the executive class look like young teenagers in hoodies. Who has the power here?
“Never” is certainly too strong an assertion here, I’m going to interpret it as hyperbole because there are plenty of exceptions.
Some alternative comparisons that are very informative are to compare different departments within an institution. In tech companies, take a tour of where the developers sit, the QA department (if it’s not contracted out!), customer support, sales, marketing, communications, and HR.
There are also strong regional differences at play here. West coast casual attire is fairly unusual even compared to other parts of the US.
So I’ve come to have a pretty dark opinion of the T-shirt dress code. To me, it symbolizes the entitlement of the west-coast tech elite.
That means you're interviewing in hard mode and decreasing your odds. For sure it won't help you. So it's not well advised to wear a suit to a tech interview.
Unless perhaps that's genuinely how you like to dress and how you go to work. Then just make that clear at the start of the interview. Otherwise interviewers will be wondering why you're wearing a suit and are unlikely to assume it's merely an aesthetic choice (as it's rare that's the case - usually it's simply that they didn't know it was ok to be casual).
> Well, dude, no, actually you can overdress for an interview and you just did. Of course I didn’t say it. And we didn’t decline him based on what he decided to wear. We declined on him because he wasn’t a fit for us in many other ways. The suit was just the early give away.
Nah. Let's keep ourselves honest. It was the suit; or, at the very least, it was what the suit represented--professionalism that separates private, personal life from work life. Yuck. Who has time for that when you're trying to get rich off the next big exit? /s
Startup culture (and many tech cultures for that matter) is one of the most obnoxious, cringe-inducing things. I remember starting out in the culture, earning my stripes. It's like high school / college culture, transplanted into a professional work environment. Same toxicity and egos, just with bigger dollar figures. I don't personally wear suits, and I'm not saying you have to call me Mr. Lastname, but let's not fool ourselves: we're business partners, not bros, and this bro behavior is also the hostility that drives gender diversity away from our company. There are two things I swore to never do again: 1) never work in an office; 2) never work for a for-profit startup (i.e. a business that isn't profitable) unless I created it. I've only ever found one private startup that has been amazing to work for, and the CEO used to work directly for Melinda Gates in the Bill and Melinda Gates Foundation. Go figure!
I did my undergrad at Stanford and the whole Silicon Valley culture was just an enormous turnoff. I just can't do it. It strikes me as... total dumb BS that does not seem to understand it's total dumb BS. To be fair, that's probably tinted with the overly critical filter of an outsider.
In the enterprise world you are at least free to acknowledge that making profit for hyperwealthy private investors isn't your life's greatest calling.
> Nah. Let's keep ourselves honest. It was the suit; or, at the very least, it was what the suit represented--professionalism that separates private, personal life from work life. Yuck. Who has time for that when you're trying to get rich off the next big exit? /s
That is so very well stated I want to highlight it! Thanks for putting it so succinctly.
> Why after investing 11 years in Mike did Microsoft decide to let Mike go?
People are tremendously expensive to a business. Losing 11 years of IP is a nightmare scenario. This would be a clear red flag for me as a hiring manager.
My second question would be...
> Does Mike's resume look like he's kept up on what's current? If not could that be why Microsoft let Mike go?
The only question I am asking when I hire someone is. Where can I put them on day one. If I can't see where a person fits in then I'm not going to hire them. The worst thing you can tell me in an interview is "I'm willing to learn". Great so is everyone else. What I want to hear is "This is the state of the market, this is what I know now, these are the things I should know, this is how I plan to know them" and "what do I need to know to meet your needs on day one"
>Mike has worked on systems that can handle multiple orders of magnitude more load, but his experience is, apparently, irrelevant.
No one really cares. I don't care if Mike was on the nasa team that sent men to the moon. Tremendous achievement, useless to me right now. I care about what he can do right now. Does Mike have the answer to the QPS problem right now? If he can why isn't he there right now pitching them the solution.
There is no earned comfort anymore. You don't stick with the company long enough to get the good parking spot. No one cares what you did yesterday they only care about what you can do today? If Mike is on board with these values and is keeping pace with the skill demands of the market then I don't think he'll have any problem finding a job at TrendCo or anywhere else. If Mike thinks he's owed something for the time he put in at Microsoft then I suspect he's in for a rough go.
I'm sorry but I find it very hard to believe that someone with "11 years in industry" would have any trouble finding a job in this market unless there is something extremely wrong with that person. You don’t create a network of personal relationships with other professionals in 11 years? That’s crazy!
i've added a link to them in my hacker news profile. i'll remove it in a day or two, as i don't want to leave my connection to them permanently in my comment history.
not all roles build equally useful networks. i was in, i dunno, "research aerospace" for 10+ years, and it was basically a waste from a networking standpoint. nearly everyone i knew there is either still in the same job, or retired. the handful of others that left aren't even in the same state any more.
i think the job did really profound damage to my career because of it. i think i'd encourage CS college grads to work 3-4 places before they're 30, and make sure all of them are places with at least a tiny bit of turn over. nowhere that has people trying to hit 30 years in the same chair to get a pension.
I had the exact same experience at Raytheon. The network I had was almost entirely confined to the defense industry, and many of them had been at their companies for 10+ years. Once I decided I needed out of that industry, it all became useless.
Many developers simply don't take the time to cultivate a network or stay in touch after leaving. If you move cities or jobs, your old pals and supervisors can't offer you much help with a new potential job, other than being a good reference.
This is of course false. The world is not starving for competent people. It's starving for high-status resumes. If those resumes are attached to people who are competent or hard workers, that's a bonus.
The high-status resumes without that affiliation will be no less effective; their associated human will no doubt wash out of a series of roles when it becomes clear that they're neither "smart" or "gets things done", but in most of the industry it takes so long for that process to run to completion that resume status accrues to those failed roles, and those people have an easier time finding their next role, failing upwards until one assumes they reach management somewhere and perpetuate the cycle.
Erin, Patrick, and I tried to do a company to exploit this phenomenon and it was not a success; even the smartest, most engaged teams we worked with were a brick fucking wall when it came to resume status filters. So much so that I was happy just to walk away from it and work with some friends to boot up another company that hires in a more effective way and exploit the phenomenon directly, rather than trying to end it.
I guess I'm saying I agree strongly with Dan Luu when he quotes me as saying that smaller companies that hire like this are playing to lose.
I conclude with the immortal words of Herman Blume: "Take dead aim on the rich boys. Get them in the crosshairs and take them down. Just remember, they can buy anything but they can't buy backbone. Don't let them forget it."