I interviewed with a company. Naturally they asked for my side projects which I showed them. We talked about technical challenges, scaling, interesting bits of codes - all these kind of things. They were really excited. I passed the interviews and got the job.
Fast forward a couple month, still working on my side projects, some of which started generating a couple hundred bucks a month. My boss started asking me to stop any side projects and put all my time thinking about the company instead. I refused and said that I am 100% there during my work hours but what I do in my private time is not related and even the reason why I got this job in the first place. My boss didn't like that at all and even tried to figure the exact times out when I would work on private stuff to hold it against me. I eventually quit.
If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong.
It depends on your point of view. The boss wants the most sophisticated talent he can get, and he doesn't want to pay anything for it. Every penny he pays, and every second of your life he doesn't get for it, is a failure in his eyes.
Since the 1980s, employment has become a game. Employers don't like it if you realize this and play them right back, of course, but there's not really any other option. Their viewpoint is dominant and essentially universal. In response to monumental productivity multiplication due to technology, they froze wages, destroyed pensions, cut benefits, and extended the work week. They believe if an employee becomes irreplaceable, they have become expendable. Keeping employees dispensable is weighed as far more important than keeping skilled talent. Read books written by managers for managers. Their actions aren't random or stupid, most people just don't understand their reasoning.
And if you only get one tattoo in your life, I highly recommend this centuries-old quote from The Rubiyat of Omar Khayaam: "Make game of that which makes as much of thee."
I think this game is much more openly recognized in SV without too much cynicism. The average tenure is probably around 3 years, and people move between companies often. This serves both the employee by diversifying their skillset, and it serves companies by facilitating knowledge transfer for certain techniques, particularly around scaling and operations for larger tech companies that individuals can't get through mere education or even small-scale work.
Consider that we openly talk about Bus Factor as a way of explicitly quantifying the indispensability of certain people; but the solution is not to get rid of them, it's just to train more people on those aspects. Of course there's still some amount of Machiavellian maneuvering, but at least while talent is thin on the ground employees still have enough leverage not to get screwed—not as badly as most non-unionized employees anyway.
Do you have any recommendations for books for managers written by managers? The last book I skimmed on this topic was "The Alliance," by some people at linkedIn. According to one of the reviews on amazon it mainly just talks about industry-wide blacklists for employees if they leave their jobs for a better one.
I thought it was me. But now I see each job as a place where I grow my skills. I actively pick projects where I gain more technical skolls over those where I develop internal company knowledge.
So if you have any other interests, such as rebuilding old cars, would that boss still have a problem with it? That is the thing I don't get, is how some companies see a big difference between regular hobbies and programing related hobbies.
I only know a few companies that promote a healthy work/life ratio.
I believe that on average non-tech companies treat their employees better and give them more right and freedom.
With non-tech companies you usually sell your time. But with tech companies you sell your brain power, if your side projects affect your brain contribution to that company for sure they don't want that.
So silly of them, I always say this. Companies should stop treating their employees as assets.
And let me say again, there are successful tech companies run by smart people that don't do this! And most employees including the founders are happier because of it.
At SunSed we believe that we should treat business like a passionate music band — making money is not the ultimate goal — the ultimate goal is to see people enjoying your music while you enjoy playing!
It might actually make some sense for a programmer's boss to be concerned about side programming projects, even if they have nothing to do with what the company does, but not be concerned about outside interests like rebuilding old cars.
Programming all day at work and then spending a lot of your non-work time programming too could put you at higher risk for getting burned out on programming. Spending your non-work time rebuilding old cars probably won't affect your programming at work.
Note that I'm not suggesting that the boss should be able to make you stop programming at home. Many people can program at work and at home and not get burned out, and it should be up to the programmer to decide if they are such a person. I'm just saying that programming related hobbies are more likely to affect programming work than are non-programming hobbies.
Equally there could be beneficial aspects to working on different coding problems outside a main job- improving skills, learning new tools, whatever. But that's not the important thing. To me, the important thing for an employer should be performance: "I have these expectations for the role, how is the employee doing in relation to those expectations, and are they being paid over or under the market value for the position?" Even if the employee could be better if they didn't have a side project, figuring out balance and maintaining job performance are skills in and of themselves. If an employee can do that, great, if not, bummer. The external cause doesn't matter. What matters is the employee's judgement in the self care they need to do in order to meet the needs of their job. No need for employer to borrow trouble by trying to control non-work activities and incurring bad will.
That's not necessarily true. Companies certainly like to advocate for the idea that they automatically own any work you do that's relevant to any of their business interests, even if that work isn't relevant to your particular job. But that doesn't mean it'll hold up in court. Just a couple of days ago I was reading something about how courts regularly side with employees instead of employers in disputes like this, how they tend to interpret that as only applying to work relevant to the employee's job and not to other parts of the company. Unfortunately I don't remember where I was reading that, so I can't go find it again.
Of course, take this with a massive grain of salt. I'd certainly prefer not to have to go to court to try and figure out if this is actually true.
Were you reading it here: https://news.ycombinator.com/item?id=13142327 ? There's a couple of mentions of courts siding with employees and courts in California siding with employees.
All previous companies I worked for had this clause. I've heard it's not as easy as typed to actually enforce. However, the companies I worked for stated that any personal project "relevant" to company interests belonged to them, up to 6 months after you leave.
"For example, the California Labor Code stipulates that regardless of what an employment contract or PIIA says, an employee owns the copyright and patent rights to his inventions if the invention is made entirely on the employee’s own time, without using any of the company’s equipment or technology, as long as the invention (a) does not relate to the company’s business, or (b) did not result from work performed by the employee “as an employee” of the company. Washington state has a similar law protecting employee projects outside the 9-5 bounds."
Good point. Seems like the company's attitude is: "show us you're passionate and have side-projects, but of course, once you work for us, we want all of that passion focused strictly on us."
I've been penalized for showing side projects and kaggle entries that weren't production quality code. No shit it's not production code, because it's not going into production. I quit working on them when I stopped learning, and that was well before code polishing.
To be completely fair, if you are showing a project you have done, it should be a good representation of your abilities. Treat it like how other industries treat "portfolios" or "writing samples".
> If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong.
My impression was they generally want to see side projects for newbies/recent graduates, i.e. stuff the applicant would have been working on during college or something. Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here?
Anecdata: I'm currently in the middle of interviewing with a wide slate of mid-size SV companies, and not one has asked for code samples. It's all a mix of whiteboarding, on-site coding, phone-screen coding, or take-home coding.
So at least for 15-year veterans it does not really seem to be much of a thing. Although I do secretly wish they would discover my 4-digit GitHub user id, that's gotta be worth some kinda programmer-cred right?
> Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here?
Hmm, the way I see it is that side projects usually demonstrate that you have a passion for code outside of your work as well. From a company perspective I would probably also hire someone who is using his free time to advance his knowledge since some of that stuff he is using/learning could also become useful for the company at some point.
I personally don't mean any harm with my projects. I just really like coding, creating things and learning more (my way of learning also being to experiment/build something with technology X). The field is so broad and there are so many interesting things to learn about with new ones getting released almost weekly.
> side projects usually demonstrate that you have a passion for code outside of your work
In other industries, these are called "portfolios" or "writing samples". It's not just about showing a passion; it's your chance to make a piece of work that represents your best abilities and judgments.
When I interview candidates I find it easier and more constructive to ask design questions about the side projects than to contrive some hypothetical scenario.
IMHO the alternative, where you ask people to write code under the pressure of an interview setting, is far less informative.
I know what you mean, but it's also easier to fake. I've definitely run into the situation where someone's projects look good, but then they are terrible on the job. I'm left to conclude they were pairing with someone more knowledgeable or cloning some idea or maybe has spent years preparing to tackle that one problem and are not good in general problem solving.
Not saying you won't get a lot of false negatives with high-pressure on-site coding or whiteboarding, but if done correctly I think it's probably the most signal you can get for the least time. Granted it requires good judgement from the interviewer, and a lot of candidates to calibrate. It's also unfair to candidates who are easily rattled, and biased towards candidates who have time to do a lot of preparation. In the past I have preferred contract-to-hire as the gold standard if that works for a candidate, but that only works if the pipeline is small.
It probably depends on the company but I think this is right. If I interview someone with little working experience it definitely helps that they have some work on Github. But it would be strange to reject a senior candidate with a great resume who did very well in the technical interview just because they didn't have anything on Github.
I want to work in a group where they appreciate that I was basically born to code. That despite my youthful features, I have still been coding for over 30 years. That I can do many tasks in an hour, that other people would take days to do. That I will spend an extra 3 hours to put a cherry on top, just because I can. I may even do it on a Saturday, because code is what I like to do with my spare time too.
So when the last company I interviewed at asked me "what is the difference between range and xrange in Python?" I just kind of rolled my eyes (on the inside). To me this is like asking a professional translator "what is the difference between 'si' and 'sí' in Spanish?" They were not interested in the thousands of lines of code I have on GitHub for my side projects, nor in a recent project that got me 15 seconds of fame. I ended that interview by saying "I don't think I'm a good match for this job".
Different companies have different cultures. It's good to be able to identify the kind of culture you want to work in, and even better to be able to respectfully decline an opportunity because it doesn't work for you. Don't become bitter and think that all companies want you to be a coding robot, just because Google and Facebook do (or seem to; I'm not sure how many of my friends who work there actually have that many side projects either). There are plenty of jobs that will work for you that won't work for me, and vice versa.
The range/xrange question was likely to check if you were a fraud.
Having interviewed close to a hundred people in a year for a senior C dev position I can assure you that people lie like you wouldn't believe. They cheat with take-home tasks, they show others' code as their own. And that's in the system programming circles, where the level of professionalism is typically much higher than in app/web development areas. We got burnt really bad when a brilliant dude whom we relocated across the country turned out to be the laziest moron I've ever had a misfortune to work with. So you bet we started most of the interviews with fuzz-buzz kind of questions.
For my next job, I've thought about offering to work for free for a week or so as a kind of mutual trial period. I want to know what the entire office is like, what the codebase is like, what the tools are like, and what actually needs to be done. If they want to rip me off and get a week of free work, great! That's exactly the kind of thing I would want to know about a company upfront. And after that week, they should know the degree to which I'm a fraud and be excited to pay me commensurately.
I know this wouldn't work for most potential employees since they don't quit their jobs until they have another one, but I always take a few months between jobs. I wonder how I might actually be able to pull this off..
Not for a week and not for free, but we converged to basically saying to every new hire that their 3 month probation period is their hands-on interview. You look at us, we look at you and let's err on the side of caution and assume it won't work. So far it worked well.
On the other hand, I'm a skilled dev with only a smattering of python experience, but if you asked me this question I'd have no idea and wouldn't think twice about looking up the python docs for both. What are you actually asking?
P.s. I don't believe anyone actually fails fizz buzz.
I suspect failing fizz buzz typically is caused by nervousness. I've one gotten so nervous in an interview that I'm certain I couldn't have implemented fizz buzz either at that time. I've also seen it on interviewees. As the interviewer it also sucks because you can't be sure it's nervousness.
I don't believe that. I'd really like a 21st century study showing that devs with > 3 years of experience fail fizz buzz, and that failure is predictive of being a bad developer (and not being a shitty interviewer)
Yes, of course a dev with > 3 years experience should be able to fizz-buzz in their sleep! That's the point!
It's not devs with > 3 years experience or even > 6 months. failing fizzbuzz. It's people _pretending_ to be devs with > 3 years experience. Or folks who started in programming years ago and drifted so far they can't get back to nuts and bolts. Or people who know the principles but can't express them. Or any number of other cases.
Like other folks have posted here in response, I've seen some really sad fizz buzzes in my day, often from people who had no business being near a computer let alone interviewing for a tech job, but somehow landed a phone screen.
Bear in mind that everyone here on HN is here because they're interested to learn about advancements in technology (and matters of broader interest) - it's too easy to mistake this little echo chamber for the entirety of the talent market.
I often read people say they'd be "insulted" if asked to do fizz-buzz, or would "walk out". I think that's an over-reaction - fair enough they need to make sure you're not useless and lying on your CV. As long as there's a more interesting follow-up question, I don't see the harm.
If you don't believe Jeff Atwood, I'm not sure why you'd believe me based just on my anecdata, but at a previous job I gave a simple filtering programming task to interviewees (not exactly fizz buzz, but very close. Single loop, multiple 10-line solutions possible).
Out of 10, only 1 solved it well, 2-3 solved it acceptably (only edge case bugs), the rest never solved it, or had obvious bugs or code that would never pass peer review.
Of course, I could just be a shitty interviewer, but I always had a (changing) peer present during interviews, and I hope we were an honest enough company that they'd tell me if they thought I was.
In 2013, I interviewed someone who had allegedly been working for a few years as a support engineer writing Ruby (using the "watir" gem) who could not even write the loop part of Fizzbuzz. They went completely silent on the call when I pasted the Fizzbuzz requirements into a shared code editor we were both viewing. After a few moments and my gentle prodding, they admitted they didn't even know how to begin writing the loop, so I thanked them for their time, wished them luck, and ended the call.
You don't have to believe it - check out the comments in Jeff Atwood's post, where many people assert they can't believe people can't solve FizzBuzz, look they've solved it right here, and post their incorrect solutions.
I've never given a fizzbuzz test, but I can assure you that many people fail to write a simple for... loop to traverse an mxn square. I've seen it so many times that I have absolutely no problem believing that the same people would fail fizzbuzz.
You really don't realize how bad candidates can be until after you've interviewed dozens of them.
I've also never seen anyone fail FizzBuzz in the wild; I feel like even the barest of 20m phone prescreenings should be able to avoid that...
I was asked for my second job ever - on the phone - for commands that would list files in a directory, change directory, and create a symbolic link. I guess I've started doing that kind of prescreen now too
Once I failed a programming test on factorial. I was younger and less experienced in interviews than I am now, nerves got the better of me.
I implemented the thing, but with plus in place of multiplication. Before that, I realised I was struggling and asked the interviewer whether it was + or *, that was probably the moment he failed me.
I ask similar questions if somebody says he/she is python expert. failing that is not an immediate issue, but i would continue probing by asking other questions on this level.
to figure out what the "expert" label means according to my own experience.
I consider myself pretty good at Python, and I would need to look that up. OK yeah whatever, one's a generator. Makes sense. Why would I need to memorize something like this in order to be "legit"? Clearly if I was gonna generate a fairly big range, I'd be like "I wonder what the memory implications for this are".
Web dev chiming in with a similar experience. Last month I interviewed three people claiming multiple years of PHP/MySQL experience, not one of them could tell me what an SQL transaction is.
Knowledge of the deepest arcana of the Python language is less valuable than the humility and self-awareness that keeps one from forming fast conclusions based on little data.
Oh how I wish I had that skill! And the complementary skill of knowing when what little data you have is totally enough and you should trust your gut instinct. I've waited far too long to make a decision when the answer should have been clear a long time ago.
Unless you've written a lot of Python 2, or ported a lot of it in my case, then you wouldn't know. It's a stupid question with little basis in actually seeing if someone know's what they are talking about.
Really? I used python for a few years a long while back and I thought that this was common knowledge. Perhaps it was the timing of it all as I now that I google around a bit most of the SO posts and such are from when I was writing Python.
It doesn't need to be rationalized. I don't know it without googling it, but I can still get by writing some useful automation for Ops work. Granted, I haven't interviewed for a full-time Python gig, but even the one or two REALLY sharp programmers I know need to reference the web for a lot of stdlib stuff they don't use often.
xrange vs range is basic competence for any Python 2 programmer. They are two of the most commonly used functions and have very distinct uses. I think that was the point of the original post, however, that the question is so basic it is actually insulting - like interviewing a doctor and asking the difference between red and white blood cells.
I don't know this. And I don't care. I don't self-identify as anything near a "Python programmer" and yet I've written, modified, read, and debugged (and put into production at times), let's say 100's of thousands of lines of Python since the late 90s. Not a ton, perhaps, but I certainly feel qualified to write it.
I'm forced to maintain (or deploy) other people's Python code all the time. Personally, I would rarely choose it for a team project I have to maintain (if the choice is mine) because I've seen most teams commit the same annoying type errors over and over in every dynamic language I've ever used, including epecially Python. I've worked with much more competent Python programmers than myself who still do this.
But if I was on your team, I wouldn't complain and my code would be somewhere between pretty good to great. I would help the team ship that Python and ship it well.
I'm not sure what this rant says more about: me or this 'range vs xrange' question?
The problem is that it's bad style to write (in Python 2.x):
for i in range(n):
# your code here
because it potentially allocates a lot of memory for no reason whatsoever. It's the equivalent of this C code:
int* r = calloc(sizeof(int), n);
for (int j = 0; j < n; j++) r[j] = j;
for (int j = 0; j < n; j++) {
int i = r[j];
// your code here
}
free(r);
If you don't want to deal with the distinction then what you can do is just treat range() as deprecated and always use either xrange() or list(xrange()) depending on the situation. But you had probably ought to know about the issue.
Ok, I would certainly agree then that I ought to know about that (for Python 2.x).
And here's the thing: despite my rant, given that explanation, I'm going to have to say I respect that as a Python (2.x) interview question.
But that's because I care about performance optimization and good style in every language I use. I'm not sure that everyone else always should or that this should be a deal breaker for a python dev gig.
I'd say that the correct answer would be "Which version of Python are you using?" but I actually kind of like the question - it's an important enough function that most people doing more than toy projects would have needed to use it at some point or at least would have considered it, but it's also something that has changed recently enough that people who are claiming long-term experience will have dealt with both versions.
My Python is rusty, but I actually had to go look up the differences - my initial thought was "I'm pretty sure it used to be that range() generated a list and xrange() basically just iterated a value, but at some point range() was changed to use the xrange() behavior - I'd have to look it up to give you more detail than that." I didn't realize that xrange() had been completely removed from 3.x, for example. For that matter, I was thinking that both of them might have existed in 1.x, though it looks like they were added in 2.0.
From that article (buried near the end for some reason):
>One more thing to add. In Python 3.x, the xrange function does not exist anymore. The range function now does what xrange does in Python 2.x, so to keep your code portable, you might want to stick to using range instead.
On the other hand, I think it's a good idea to sanity test your candidates, especially when it feels like everyone is trying to pass themselves off as a developer nowadays.
I have worked at a prestigious tech company, and I know what OP is talking about.
A lot of very talented people don't have side projects, and they don't do any coding outside of work. They don't go to hackathons. They don't bother to learn the newest reactive javascript framework. They go to yoga classes after work. They talk about TV shows they watched last night during lunch.
But they EXCEL at what they do at work.
I can say that this is really a subjective thing. When you make a judgment about these people, it actually tells more about yourself than the person being judged.
When I saw these people who are super talented, but "waste away their lives" just climbing up the ladder I just couldn't sympathize. Also personally I like them but I would never think about starting a company with them.
That's why I understand where OP is coming from, and he's right in a lot of cases, but also I think he should understand that not everyone will agree with you on how you view your life. People like me can't stand not working on my own project, but there are also super talented people who are perfectly fine with living a balanced and stable life. Talent and intelligence has nothing to do with how you live your life.
So, I think no one should judge anyone else. The company who didn't hire this guy may have lost a talented person, but in many cases talent is not what companies need the most.
For large companies like Amazon (which OP seems to work at) this type of employee is the ideal choice since they get the talent AND stability.
But for startups, the concept of stability doesn't really make sense anyway so it's a different story. If I was doing a startup and had to pick the first employee, and was given a choice between a passionate, right out of the college guy, and an experienced and talented engineer who wants to live a balanced life, I would definitely choose the former. (Although the best case would be to find the third guy who's passionate AND talented)
Having spend the last decade living the startup life, and now searching for something more stable, I have to say you're setting up a false dichotomy between passionate and balance-seeking. They are completely orthogonal, you can be passionate and work widely varying hours; you can also be indifferent and work widely varying hours.
On a tangent, I don't really like the word passion anyway. What makes me a good programmer is not my passion for it, it's my curiosity and motivation. My motivation is a primary factor in my performance, and that probably is 80% influenced by context, and 20% by the content of the task itself (at least for most things that fall within the standard purview of programming tasks).
Finally, you don't mention talent for the new graduate. That is a huge factor. If the new grad is not extremely talented, they will never produce anything of value. If they are highly talented they can likely power through a lot of things, but they also need to make good decisions about what to work on since time allocation is the single hardest thing about getting early traction for a startup. Yes, all else being equal, take the guy that wants to work 16 hours a day and has no other distractions, but if the veteran who wants to work 30 hours a week has better business sense and a smarter idea of what to build and when, then that dwarfs the code quality consideration.
Sorry that it came off that way, I tried to make myself clear with "I can say that this is really a subjective thing. When you make a judgment about these people, it actually tells more about yourself than the person being judged."
From my experience, all these brilliant, intelligent, and talented people (who don't do extracurricular activities related to coding) have completely different motivations than myself. My point is that it's fine that they do, and it's fine that I don't think that way either.
I'm just saying that there are people who are fit for certain type of situations, and some people--no matter how talented they are--are not fit for certain jobs just because their life values are not compatible with the situation. That doesn't mean the employer who made that decision is an idiot. They're just not compatible, and that's fine.
When I started programming, I had side projects coming out of my ears. It was pure recreation.
After getting a "real" programming job, where I had to deal with design-by-committee, power struggles, keeping up appearances, etc. I didn't dare jump back into recreational programming--I'd never go back to my actual job.
Even now, working for myself, I have to be very disciplined when I crack open the "fun" code, because I know it will be very painful when it is time to go back to the code that pays the bills.
> When companies say they want "passionate developers" that are coding in their free time, when companies say they want "the best," I get nervous. It's a myopic approach to team building. It's a subtle way of requesting human machines.
I take issue with this.
I don't write code in my spare time for fun, I have a family.
When I do write it, and when I do Open Source it, it's because it makes my life easier. It makes it easier to check my email, track what I still need to do on the house, and cut out half my work tomorrow, so I can take some leave and be with my family.
I release it to the wild so that others might benefit, and I can pull it out when recruiters ask to see my code, even if they can't understand it, which is most of the time.
I've had a few companies ask me for my Github account, so they can see what code I've written. I never give it out, because I think the request is pointless to start with.
A friend of mine, who works for a well-known technology giant, recently told me about a Linux guru they interviewed and hired. He was amazing in the interview, and they gave him an offer on the spot. When he started working, however, he constantly turned in sub-par work. A couple of months later, one of the members of the team who had interviewed this guy flew out to where he was working, and discovered that the guy sitting in the cube doing the work was not the guy they had interviewed. It was someone else. The guy went through quite an effort to cheat his way into a job, but when he was discovered, he was immediately fired.
If cheating was my thing, and I really wanted to get a job via nefarious means, so I could worry about my job on a daily basis, how hard would it be to pay someone to write a bunch of Github code for me? Exactly, which is why the request is pretty dumb to start with, I think.
For a bunch of smart people, we engineers sure have a hard time figuring out how to interview people and ascertain their skills.
>A couple of months later, one of the members of the team who had interviewed this guy flew out to where he was working, and discovered that the guy sitting in the cube doing the work was not the guy they had interviewed. It was someone else.
This seems absolutely incredible to me (just in the slang sense, I don't mean that I'm incredulous). I mean it's way more than enough for the company to sue for fraud the (highly qualified) person who showed up to the interview, or to sue the person doing it. TBH if I were that company I would likely sue for damages. I mean it's just so blatant and goes so far.
I've never heard of this. So I would be curious if you would reply with a somewhat more detailed write-up (maybe 1 or 2 paragraphs) of anything else you know about that case! But, maybe you've mentioned everything already. (You said a friend of yours told you about this case, so I realize we are reading this third-hand.) I would just be really interested if you could mention anything else you remember.
There have been a few stories over the past few years of people outsourcing their own jobs, but I'm not sure whether any of them have actually been shown to be based in fact. That said, this could be the same kind of thing - did the guy in the cube hire the "guru" to interview, or did the "guru" interview then outsource to the guy in the cube?
oh I didn't even think about that. fraud either way :)
I think outsourcing is one thing - but being an employee who is on payroll and physically shows up to warm a butt in a seat, goes a lot farther. Regardless of whether the cube guy paid someone to do his interview, or the guru hired a body double after getting hired, it's pretty insane. do you have any links to anyplace you read about the same thing?
The entire drive to hire "passionate developers" makes me very nervous. It's a double edged sword and most people don't want to see it. Yes, passionate developers are more likely to stay up to date on technologies and are also more likely to put in extra time. However, they are also much more likely to use technology that isn't ready yet and overcomplicate things because of some misguided aesthetical sense or best case spend way too much time gold plating the wrong thing instead of providing business value. The cost of those things is generally much higher than someone going home sightly early or not knowing the very latest JS framework.
No one has ever shown anything more than a nodding interest in them, as they lead me to a whiteboard and ask me to regurgitate a couple of pages from Crack the Coding Interview.
As someone who does have a bunch of pet projects, I appreciate the author's sentiment. I often wonder whether my programming world presence (GitHub, HN, &c.) accurately reflects the kind of person I am (or perhaps want to be).
it might never happen, but when one employer decides to go crazy and try to blame you for leaking code (that you may have written even before joining them) on open source projects, you are going to regret skipping the silly interviews by showing your open source persona to them. best thing you can do is keep it to yourself. then when you really need it, say for a research grant, then go public.
I appreciate the advice, although with the jobs I've had so far I've been sure to tell my employer in advance about my open source work.
Maybe I've just been lucky, but all have been either okay with it or actively supportive (even when concurrent with in-house development). That being said, I've been careful to avoid open-sourcing projects that I think come to close to hired work.
I agree with the author. You can't judge the passion of someone by his behaviour, that's silly. You can be as well a passionate programmer when you don't code home than when you do.
However, coding home has one - big - perk: it's almost the only way for you to code something from scratch. Alone. You and your code. You and your progress rate. You and your bugs. You and your choices. You and your mess. Nobody to smooth any angle.
I believe coding from scratch - alone - makes you a completely different kind of programmer indeed. But it has nothing to do with passion. Nothing at all.
I think (I can be wrong, still trying to validate that) that "number of projects from scratch" is the metric that tells the ultimate level of a programmer. In other words, if you've almost never coded anything from scratch (below say 40-50 projects), I do believe you are not very good at programming. Conversely, I know from experience (my own) that coding from scratch can make you so good, that you would find Amazon SDEs complete novices (I know from my own experience at amazon) and this before your 30's. It can make you better than principal engineers before your 30's. It can make you so good that TDD, OOP and agile development sounds like novice exercises to you. It can make you a programming master and beyond.
Could you be as good without coding from scratch really? Well, ultimately maybe but not as fast. Coding from scratch is so painful, so hard, so stressful, so frustrating that maintaining code or adding small to medium sized features is a baby step in comparison. Now of course, if you add something pretty big to an existing code base or make a god damn big refactor, you're doing the same thing as coding from scratch basically. The thing is that it's rare you 1) add that big a feature to an existing codebase 2) alone, in a big company.
I'm pretty sure the author has passion for programming, probably as big as anyone else. And balanced life is good for skills as feeling great makes you more creative amongst other thing. It's just that coding home makes you write a type of code that is 100 times more difficult than the one you do in big companies. Paradoxically, I'm pretty sure interviewers don't, at least consciously, know that.
there another side to it. coding alone making all decisions on the fly and as needed can also be very relaxing. in the big company, most of the work is getting agreement; fighting legacy code; planning transitions; making sure everybody is on the same page as they contribute...
Exactly. I have seen people who are fantastic developers when working on solo projects but start to struggle when placed in a business/group environment. Once things like business priorities start informing what people are going to be working on when, once folks need to start coordinating with other developers and their own quirks it starts going downhill
This, a thousand times. I'm an excellent bug-fixer/chaos-manager/refactorer and this led me to believe I should be an excellent project-starter as well. It has bit me in the ass more times than I can count (although I'm getting better with each new project).
Part of the process for me has been to try to do as much of my job as possible in the open source world.
Naturally, I can't open-source any private business code. But if I'm doing my job right, I'm building libraries and reusable code that isn't tightly coupled to business logic -- and there's no good reason to avoid throwing all of that on github, and have it be used by as many people as possible.
Of course there are going to be companies that aren't onboard with the idea of open-source. It's taken a lot of places a lot of time to get to that stage. But are those the places you really want to work?
I am generally suspicious of someone who has no sample code to show. You can't take a few hours a week for a month to put a small project together as a demo of your abilities?
Skip the novel writing for a month and instead create a 10 hour project that shows potential employers you know what you're talking about. You can use it for years so it's well worth the time investment.
For most jobs you don't have to have a ton of active side projects or contribute to open source. You should have something to demo though.
Most, but not all people who are employed have contracts which assign ownership of everything they do, including in their spare time at home on their own equipment, to their employer. And yes, a very small number of states consider such standard clauses to be unenforceable.
Most candidates who show their previous code, either written for their employer, or from side projects that are still within the scope of their contract, are violating non disclosure clauses of their contracts. Someone who has sample code to show is likely an unreliable candidate who thinks nothing of violating his signed contracts. Such candidates should not be hired.
Most employers who include such clauses and aren't open to negotiation are violating common decency. Any company so incredibly tone-deaf is likely an unpleasant employer that thinks nothing of treating their employees poorly. Such companies should not be serviced by professionals.
I'm not sure I like the tacit implication that folks who do lots of side projects are superior engineers or are very passionate about "coding".
The assumption that "lots of side projects" is somehow a positive attribute (from an employer's perspective with regard to "types" of engineers) is very much a flawed one.
I stopped reading when the author referred to the amount of people living in cities as "a tiny puddle" of the larger population. That's not even a little bit accurate.[1]
No, this is nothing more than pity-party because one person wants to fit in and be recognized for something they aren't. I am glad you think your dog business,and art, and running makes you equal to or better than someone who is passionate and dedicates themselves to their interests. You aren't that person. that's okay. but don't try and form the world to fit your views. You aren't the best developer, you don't want to be, move on.
I totally agree with this. If you can do the job well, who cares what you do in your free time.
I've been on the other side (the hiring side), so let me give my perspective. It's okay to not have side projects, or a presence on Github. It is perfectly okay to say "I don't have a very active Github account, but let me tell you what I enjoy about programming". "Show me your side projects" is a (poor) way of asking, "show me that you are passionate about your job". I'm not looking to hire the elite, but I am looking for someone who will be happy to come to work.
I disagree with the article and the notion that asking for a portfolio is about passion. I guess it does add insight for that, but really only shows basic proficiency. I wouldn't hire an artist, writer or designer without seeing a portfolio of their work so why would I hire a software developer?
I too have been on both sides of the hiring discussion. Because anyone can write anything on there resume, there are only two way to know if someone can code. They can write some code of they can show some code they have written. As both an interviewer and interviewer I would rather work with real world problems and discuss real world solutions.
So the choice seems to be between stupid whiteboard processes or portfolios. I suspect there is a reason writers and painters don't have auditions and perhaps that same logic maps onto programming.
I always go through an extreme opposite hiring experience. I'm not on linkedin by choice. Currently I use my SO developer profile as my online resume. But the lack of a linkedin profile and associated connections makes it look like I'm not a professional in the view of certain employers. I have a decent bunch of side projects, and a moderately active github profile and I have gotten all my jobs including my current one based on that. I don't regret not being on linkedin. I'm just happy showing my side projects for my coding knowledge as I cannot show code I have worked as a part of my employment. Also I believe when talking about code written as a part of employement, it all boils down how effectively one communicates/talks to the potential employer than how actually we did it. This is one of the reasons I try to maintain side projects independent of my day job.
For me, the whole idea of proving oneself as professional by being on linkedin has been a biggest turn off. Coupled with this, when I look at some of the people's linkedin profile and the actual attitude and proficiency they demonstrate in their jobs makes linkedin look like a ridiculous circus.
> when I look at some of the people's linkedin profile and the actual attitude and proficiency they demonstrate in their jobs makes linkedin look like a ridiculous circus.
Once I was not accepted for a job because I had very good side projects. They said I was a risk to them, because I could stole ideas, contracts or be a competitor. Today I have my own business, if we compete, it's just in hiring talent.
I worked for a remote office of AMZN's and found that the office I was at had great work/life balance. At any big company, work/life balance will be very team-dependent.
I am passionate about code. But, most of my github is little hacks to solve some particular need or scratch some particular itch, without any need for overarching design or maintainability.
The good stuff (including libraries and frameworks) is all in my professional career.
I feel like if you use open source libraries and are a decent developer you'll naturally end up submitting a PR to Github at some point. I find bugs in almost every open source library I use and have had so many PRs to fix them.
It depends on the projects you're touching, of course.
I've contributed bugfixes to GNU less, GNU screen, and GNU emacs, and GNU make. None of those would be easy to dig out references for, and none of them use github.
A boutique app firm is a small company that builds apps for clients. Generally those clients are going to be smallish businesses (probably mostly less than 1000 employees).
Some examples from my area include a small grocery chain (5-6 stores) with their own app and a local credit union with their own online banking app with support for mobile deposits via photographs of checks.
> I've made it a point to add to my resume and online profiles the other things about which I am passionate. The silly art project that I launched in Austin. My dog business. Running, painting, writing. It's important to me that these attributes be valued by my workplace
Good luck mate, that's got nothing to do with software development. If you don't love software development then applying for a software job at a software firm probably isn't the best idea. Many small buisnesses need software people who are pasionate about other things. Many of these things include "Running, painting, writing" but a software shop writning software owned by people in the software industry populated entierly by people who absolutly love writing software probably isn't the place for that.
I actually don't mind being a human machine. Not that I've had the chance yet. I'm still in college to get my CS degree and would fall into one of those people where "coding is a Craft". I genuinely love programming. I don't have a family, or really desire one. My weekend plans always consist of building another project of my own. A place that will let me code all day, give me a nap room, a shower, some salary, and food sounds like a dream. It's unfortunate that it costs so much money to get to the cities that promote this.
I think the author is just realizing that this field isn't for them. Tech moves fast and to stay on top of it you have to move fast too. At least for modern tech. Maybe that author would be more comfortable being a COBOL programmer, or an embedded systems one.
Lol try having the CTO say when the billing system you look after hits its first 5 mil a month "this had better be right other wise we are both out of a job"
> For a field that doesn't cater to people with families and other life obligations too well
There's no reason that the field (of computer science/software engineering/etc) _can't_ cater to people with families and other life obligations.
Jobs that don't cater to people with families include being a surgeon, a pilot, a firefighter, etc.
I've worked at several software companies (including a company worth hundreds of billions[0]) and it totally comes down to (1) employer (2) team.
There's nothing about being a developer that is at odds with people with families. Some employers have awful work life balances (due to company culture) and others don't. Some employers have teams with awful work life balances and others with great ones.
If a company has an awful work life balance, the solution isn't to remove people with families and other life obligations, it's to fix the company culture.
I agree that there is no reason that it can't, however the loudest narrative (and in the cultures of the flagship companies) is that it does not. If the author doesn't gel with that for whatever legitimate reasons, then they are looking at the wrong companies. The company culture is like this because it is apparently working (so far). People who don't like it should go to better companies for them, or push for a collective change like a union I guess (just look at HN's love of 'old geeks'), or start their own. Nothing is stopping them from doing that.
There's a middle-ground to be found, for sure, between OP and parent. I do think it's a little odd to have years of experience in software development and not one "if only ... I'm going to make it."-project.
> Tech moves fast and to stay on top of it you have to move fast too.
This is a myth that comes out of drinking too much VC kool aid and watching too many TED talks. Most successful tech is built using 20-40 year old programming languages, operating systems, and data stores. Depth is far more important than breadth.
> My weekend plans always consist of building another project of my own. A place that will let me code all day, give me a nap room, a shower, some salary, and food sounds like a dream.
Of course I do. I like painting, and photography, and history, and sketching. But most of the time (since I'm in school) I'm working on projects on the weekend. It boosts my portfolio and hones my skills.
I interviewed with a company. Naturally they asked for my side projects which I showed them. We talked about technical challenges, scaling, interesting bits of codes - all these kind of things. They were really excited. I passed the interviews and got the job.
Fast forward a couple month, still working on my side projects, some of which started generating a couple hundred bucks a month. My boss started asking me to stop any side projects and put all my time thinking about the company instead. I refused and said that I am 100% there during my work hours but what I do in my private time is not related and even the reason why I got this job in the first place. My boss didn't like that at all and even tried to figure the exact times out when I would work on private stuff to hold it against me. I eventually quit.
If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong.