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.
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.