Hacker News Reader

Comment by hocuspocus | Hacker News Reader

> Recruiters want people who do side projects [...] having side projects and doing open source is valued in hiring

I think your premise is wrong and you're vastly overestimating the value of work done outside of your job.

- Having side projects: I was never asked past internship interviews. Even interviewing for my first job after graduation, I talked about what I did during my internship, not about side or school projects.

- Meaningful yet small contributions to open source: I don't remember anyone noticing nor asking.

- Major contributions to a big open source project: I assume these people get hired easily.

Recruiters are not dumb. They know that most good candidates are either not allowed or not willing to work on meaningful projects on the side, outside of a few very specific cases. Don't waste your time with companies that have delusional hiring standards.

View on HN

> I think your premise is wrong and you're vastly overestimating the value of work done outside of your job.

For purposes of impressing the interviewer or getting the job, yes. For purposes of actually doing the job, I would say formal education and previous work experience are often overrated, and side-projects are underrated. Most of the skills relevant for my job I learned from tinkering, side-projects, and hobbies, whereas I rarely use the knowledge from my PhD (besides meta-stuff like how to organise and how to learn new skills). But the recruiters look at the PhD, not the hobbies. And I know many cases where it played out similar to this. (At lease that's my experience, mainly in Germany.)

> I would say formal education and previous work experience are often overrated, and side-projects are underrated

As a hiring manager, I disagree. Nothing beats actual work experience delivering code in a real production environment to real customers from within a real team environment.

The vast majority of side projects I see from applicants are one-off toy projects that have the luxury of starting from a blank slate, haven’t been built in a collaborative environment, aren’t hosted for significant traffic, and often aren’t user friendly enough to be used by anyone other than the author who knows all of the right commands and steps to get it to work.

Side projects can be good for tinkering and playing with new skills, but someone having real-world experience deploying those skills within a team environment to real customers and experience real-world customer issues at scale will have significantly more experience.

> As a hiring manager, I disagree.

Sounds like you’re bolstering his point that hiring folk care a lot more about work experience than side projects.

As a senior devloper, I would disagree with you. It's true there are things you learn im a professional environment that you don't learn doing side projects, but the reverse is also true: ina professional context you often have to do things quickly, take shortcuts for speed, choose technologies and techniques you already know in order to reduce risk. In side projects you can slow down, do things properly learn things the hard way.

I'd say 40 - 50% of my value as an engineer comes from side projects , many of which I did before I'd even had a dev job.

Same here. My side projects have literally taught me things that have enabled me to save a company. I was out of the corporate world for ten years churning through side projects and doing research on advanced topics. Hired back into the working world and immediately noticed a deficiency across the board in all the people who had been deploying code for real customers all those years. Passed them all and literally saved the company from a major system crash caused by their ineptitude (a crash that made it onto the Associated Press).

It was all due to not reading documentation, false assumptions, and a fundamental misunderstanding of several libraries, platforms, and technologies. They didn't know how they worked and didn't bother to check on their assumptions. A whole development team of architects and senior devs ruined (still in business but sold/acquired on low eval) a company through pure ignorance.

>> As a hiring manager, I disagree. Nothing beats actual work experience delivering code in a real production environment to real customers from within a real team environment.

I fully agree with this, except it is difficult to gauge who did what from the outside when interviewing. This is especially true for major projects where multiple individuals work on the same tier. I've see linked-in profiles of former colleagues who wholly took credit for things other people did.

When interviewing, I usually ask a lot of questions on challenges and lessons learned from these projects, but even then, if you have worked alongside a group for a while you can learn enough to claim you did work. I found it difficult to determine in many cases whether someone actually did the work or just managed it or just did the easy portions alongside the hard portion.

> The vast majority of side projects I see from applicants are one-off toy projects that have the luxury of starting from a blank slate, haven’t been built in a collaborative environment, aren’t hosted for significant traffic, and often aren’t user friendly enough to be used by anyone other than the author who knows all of the right commands and steps to get it to work.

And every one of these bullet points can tell you a lot about how good a developer can be. Do they know the limitations of their project, what is it that they wish to have done better, why wasn't it done, why did they stop developing, etc, etc... there are so many questions to ask based on the individual contributions that give you a lot of good information about how well a developer can work.

When working as part of a team a lot of developers' short-comings can be hidden by the achievements of the other members.

From my point of view (as not a hiring manager) the only time when the achievements from a work environment are more important than the individual ones, are when we're talking about how well someone can work with others (which is mostly a soft skill you can gauge from conversation alone) and when individual projects can't really exist in the context of the technologies the team you hire for is working with, and you require previous experience with them.

> formal education and previous work experience are often overrated, and side-projects are underrated

I partially agree, in my opinion work experience > side projects > education experience. When I'm looking at resumes I pay the most attention to work experience, and that's what I'll dig into in an interview, but for fresh grads and anyone with very little experience I will absolutely go through their github and see what kind of code they write and what projects interest them.

> Most of the skills relevant for my job I learned from tinkering, side-projects, and hobbies

I agree with this 100%. Learning to use tools beyond what you use at work makes you a better programmer, which in turn makes work easier.

> previous work experience

In my experience it's underrated, people prefer to gloss over that in order to ask the all important Fizzbuzz questions.

> - Major contributions to a big open source project: I assume these people get hired easily.

Nope; it depends on market demand for the project. I know a guy who was a major contributor to OpenStack for years. He’s an E5 at a telecom and is having a hard time finding a better job. Turns out there aren’t really that many places with huge OpenStack footprints.

The one place it might matter is in consulting. And only because it’s a good way to signal to clients that you know what you’re doing.

> Recruiters are not dumb.

When it comes to hiring tech talent they kind of are. They usually have no idea what an engineer actually does, so they’re checking boxes off a list the hiring manager gave them.

That's a bit sad, but isn't it at least partially due to OpenStack's decline?

And yes I've come across bad recruiters, but this is a self-solving issue: either external or internal, they'll quickly be unemployed if they don't realize what expectations are clearly unrealistic in a buyer's market.

Yeah, I guess my point is that unless the open source project you contributed to is in high demand itself, your contributions don’t really mean much from a recruiting standpoint.

I want to second this a lot.

Even if I (coincidentally) have a side project relevant to a job opening, I make a point to mention it in my cover letter, and most interviewers still say they haven't looked at it (if they've read the cover letter at all).

I don’t think I’ve ever seen a cover letter from a candidate in over 25 years of interviewing. They’re maybe seen by HR, but long stripped before the interviewer in my experience.

I can only think of a couple of times where HR decided the cover letter was worth including with the resume in a very similar time frame.

Depends if you go through HR or not.

I have seen every cover letter accompanying a job application in every company I have worked for but I have never worked for a company with more than 200 employees or so.

Strange. I've worked in startups my entire career, hired over 100 developers and I can count on the fingers of one hand the number of cover letters I've seen.

Well cover letter has somewhat been replaced by an introduction email, no?

True. But there are still recommendations to email with a coverletter.pdf AND a resume.pdf. Maybe developers in Toronto don't follow those rules ...

For me, it varied. In the beforetimes, sometimes I walked into the first onsite interview and the technical interviewer had printed it out!

Reply on news.ycombinator.com