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