I do understand (and sympathize) why many job candidates disagree with the importance of a "personal portfolio" and so we get repeated frustrations of comparing it to accountants, lawyers, pharmacists, etc. E.g. if pharmacists don't dispense drugs on the weekend "for personal fun", why do we "expect" programmers to do the same?

The way to make better sense of it is to not frame it in terms of "expectation" of a job seeker but of "identification and preference" of employers choosing one job seeker over another. Whether the preference itself is flawed is irrelevant. The point is that it's human nature to use a preference as a tie breaker.

Programming, much more so than accounting/law, is an activity that many more people like to do for personal "fun". Because of this, it's inevitable that some employers tend to want to identify them and prioritize them over others.

And hiring preferences are not unique to computer programmers. Here's engineer Ben Krasnow (of popular channel Applied Science) explaining how a "personal portfolio" helps him stand out and get good jobs:

- deep link and watch for ~30 seconds: https://youtu.be/ihbYtxaEDSk?t=248

So, if you're an electrical engineer getting angry at the world because employers shouldn't "expect" you to design circuits for fun on the weekend, don't be surprised if they hire Ben instead of you.

Edit to add another Ben K video covering the same topic but mentioning Valve & GoogleX and choosing between prospective candidates:

- deep link: https://youtu.be/4RuT2TlhbU8?t=112

The fact that I do programming at the weekend for fun on my personal projects does not in the slightest imply that I have fun at the kind of project that I have to do for the employer. So, judging by this criterion is a really bad idea of the (potential) employer.

I am not sure that was the argument being made. I think it was more like "If a candidate actively uses and develops their skill set in their own time, then they will be preferred over candidates that don't". Those candidates demonstrate a higher level of mastery of the skills needed by virtue of doing something, _anything_ over other candidates who don't, even if the demonstration is trivial. It can also signal a lower managerial load if the candidate has demonstrated the skill set to self-start and self-motivate. That can also mean less ramp-up time to being productive.

I don't see working on personal projects as doing personal development. What I do then is riddled with bugs, no unit-tests or documentation, and with no sense of project or time management.

Don't get me wrong if a personal project to you is production code, well then to me that is a hobby or maybe you are doing it to pad your resume, in which case sure it does seem like a good signal.

Overall though you have to have unproductive fun and that's what personal projects are for me, and this notion that anything tied to code equals resume is really insidious. Like when do we ever get away from work? Hustle culture seems to have made it's way into a white collar job, I need to tune out.

I am coding majority of my working time. Some more hours at home does zero for my learning.

Also, people who put really a lot into work during work day, don't have projects outside. Because they are literally tired from work. If they would not, they would work more intensively on work. Like, if one have slow boring month, then it is easy to crank some more. But in normal week when you do with full focus, you get tired.

1) Recent grads should not feel entitled to pay, respect, etc. etc. just because they have a degree.

2) Someone does not need to have a wide portfolio of projects to be a good developer, but those will probably make them a better developer.

The best junior developers will be the kinds of people who build constantly, but you don't need to be that to be a good, competent programmer.

They are also likely getting salary according to what their advisers or statistics tell.

Also, real life state of things is that for non-juniors, most companies dont actually care about side projects. And overwhelming majority of developers dont have them. It is meme on hacker news that it matters, but I think that is some bias here.

Also, If I were hiring a beginner accountant I would greatly prefer one who had set up imaginary companies in quickbooks, and it isn't hard to do so.

Actually building things demonstrates that you might actually build something in my company. It's just competition though. If you have two guys, one who has been in CS education for 5+ years but somehow has no personal projects in that time, versus a guy with no education and a few interesting personal projects, I know who I would pick. I'd also be kind of shocked that in 5 years of learning about a topic you never built anything interesting.

It functions despite the fact that your accountants didn't have a portfolio of personal projects when you hired them and don't do accounting for fun in the evening. To my knowledge, it's substantially only programmers who are expected to do so.

Accounting students are studying for a CPA, a similarly regulated exam that tests your knowledge of the rules and how it can be applied to specific cases.

By passing the exam, you're licensed to practice law or start doing tax/audit/advisory for companies or individuals.

There's no such analogue for CS grads, because CS programs aren't focused on training you for a specific credential.

I don't know if it's just or wise - but it's not unique to programming.

If you group it more closely to creative fields like design or writing—both fields where portfolio reviews have been standard hiring practice for decades—then it makes sense to expect to see projects. If you view it closer to a professional services role—accounting, legal, etc—then your comparison makes sense.

I'm not advocating for either view as the "correct" opinion either, I just think the disagreement has less to do with what qualifies a junior and more to do with how we conceptualize development as a profession.

> I'm not advocating for either view as the "correct" opinion either, I just think the disagreement has less to do with what qualifies a junior and more to do with how we conceptualize development as a profession.

I believe that there exists a good criterion to judge: If the employer considers programmers to be "fungible", programming needs to be viewed as professional services role. On the other hand, if you are considered and catered for like a "creative rockstar" by the employer (because the employer will have a hard time replacing you), it should be considered a creative profession.

Judge for yourself what is closer to the truth. :-)

Coding is writing, and choosing what to write about, and picking language to use to write about it. It is an unending series of creative choices.

If someone has no exposure to the process of making those choices, they are not ready to code.

Programming itself is also not limited to developers. That should be self-evident in that spreadsheets are the go-to tool for so many non programmers, and they are at heart accessible programs. In that sense, it is programming that is a creative endeavor, not development or coding.

Last but not least, the most creative (and valuable) part of programming is arguably problem definition and problem solving. I would argue these two things are shared, in one way or another, across most jobs and careers.

However, it seems to me - as a layman with zero accounting experience beyond Wikipedia and GnuCash - you could feasibly drop an accountant into any arbitrary business and they would eventually find their way around the cash flows, balances, and - given sufficient information - build up a general profit/loss and general idea of financial health.

It doesn't seem to me, however, that you could drop any software engineer into any arbitrary company and expect the same. You should be able to, but not right now. Some software engineers can do that. Not all of them.

I suppose my point being: a degree from a chartered accountant indicates a core level of competency to me. But a software engineering degree doesn't. This is why we interview them with whiteboards / fizz buzz / how many windows can you wash / what is the ideal shape of a manhole cover.

Because you can get a top class degree in S.E. / C.S. and still not be able to handle a JVM OOM error.

In general, I agree with your point. It's mentioned elsewhere that there's a difference between a trade school and a university, and a software engineering degree is a broad university degree. Much like an English degree won't guarantee you're a great author, it seems odd to expect a CS degree to guarantee you know how to handle an OOM error, for example. I think in many cases CS/SE degrees to themselves a disservice by trying to teach everything, instead of allowing specialization that can be clearly understood in the next phase of someone's career.

In university, we learned the concepts. We applied the concepts in internships and learned how to do things hands-on. When it comes to applying for jobs, internship experience is considered more important than academic coursework. So this is kind of parallel to how 'real world' experience developed from personal projects is more important than academic training in software.

So in this sense, this kind of reinforces what the original poster said. This kind of hands-on experience is important, and there are different ways of demonstrating it in different fields.

You are right though, no one is expected to do Quickbooks on the weekend. You have to realize that there aren't a ton of professional fields where people do what they do professionally as a hobby.

The good side of this is that in order to get hired in tech, you don't need a degree or a P.Eng. The downside of it is that you as an employer have to do the entire vetting yourself, instead of relying on universities and professional engineers associations to do a significant part of the vetting for you.

EPC companies do not give their civil engineering job candidates a civil engineering equivalent of fizzbuzz, because they don't have to. If they are certified, they have demonstrated they possess the required knowledge. I cannot see how fizzbuzz can be eliminated from software without a similar certification process being created in its stead.

To add: Other professions such as lawyer and doctor also mandate similar apprenticeship timeframes. It's time to take a similar approach for software development so that it can be taken seriously as a profession.

That's because imaginary companies are too simplistic to learn real lessons about accounting. And it's prohibitively expensive to start a new company just to practice accounting.

In programming, however, it is not prohibitively expensive to bring in even all the HN-hated build and dependency boilerplate of the Javascript ecosystem to publish a project to the world. You understand this and for some reason think that the sensible solution is to replace the imaginary teaching of university group projects and replace it with on-the-job "couple thousand of hours" teaching to develop proficiency. What happened to the weekend personal projects? That's a much cheaper and resilient form of learning by writing actual programs the student actually cares about. It's too bad that accountants can't do the same but what has that got to do with anything?

Edit: typo

At the same time, the best accountants I know are interested in accounting. But lets say you were hiring a writer -- would you look at one who could only point to class assignments as a portfolio of work?

Novel solutions for solved problems are generally non-optimal.