That's great for front-end guys, but it's frustrating to me as a back-end developer to have expectations that I can show live examples of my past work to potential employers when I've spent years designing and building enterprise internal systems which have no visible result outside of the code itself, which is under strict NDA.

I get it, development is a craft, it's easy to judge the quality or experience level of a coworker after having to deal with their PRs for a month or two. However, it's not like any toy project I could throw on github is going to have real relation to the actual work I do, and trying to replicate e.g. some of the third party integrations I've written internally as public stand-alone packages is going to get me fired and sued by an overprotective employer.

This isn't a hypothetical fear either, multiple times I've gone through phone interviews to a "lets review some of your past work" stage, and my "I can't legally show you any of these things, but here's general descriptions of some of the major internal projects I've led or handled solo" has resulted in failing to make the next interview round.

Have you tried putting together an abbreviated version of your work on github? I've had success with toy utility apps to demonstrate my coding style and basic competencies because I am in a very similar position. Generally I've found it's less about having a large, completed application and more about having a solid chunk that's well architected and demonstrates an understanding of best practices. Like I have a bare bones UI WPF app with multiple projects, dependency injection with a stairway pattern, thorough comments, and decent though not complete unit test coverage. It doesn't do anything special and it only took like a weekend to put together, but it shows I know what I'm doing. It's a private repo and none of the code shows up in Google searches so it's also pretty clear that I didn't just copy and paste someone else's work.

The sad reality of software engineering is that the wast majority of code everyone writes is not something they would want to show in an interview. Even if they legally could, which is rarely the case for commercially developed software.

Heck, even reasonably good software can produce a very negative impression. Utilitarian code can be seen as ugly or overly simplistic. Elegant conceptual stuff often runs the risk of grinding against biases and preconceptions of the particular reviewer.

Your first argument is true, but I would argue that if you already know what you're doing, you can write some demo portfolio code specifically to show off your skills in very little time. Make that code pleasant to read, free of legal constraints, and be ready and able to talk about it. You probably will spend at least 40 hours a week at your job and it will dramatically affect your life. That's worth spending a few days, maybe even a few weeks preparing for so that you can get one you like.

For your second argument, I know what you mean, but that's also totally subjective, dictated by chance, and would apply equally across the board for all candidates. Even if that happens, it sort of naturally levels itself out competition-wise.

Also, remember that you're evaluating the employer too - do you want to work for someone who chooses employees that way? Would you want to work with someone who has a closed mind and an axe to grind about certain concepts? I wouldn't trust people like that to make good decisions that will make the company succeed, thereby keeping me employed - let alone providing opportunities to advance. Plus they sound like they'd be a pain in the ass to work with.

> Make that code pleasant to read, free of legal constraints, and be ready and able to talk about it.

That would be difficult for people who work for companies that claim presumptive ownership over everything they produce.

Produce it on your own time, using no company resources. If a company claims ownership of everything you produce in your own time using your own resources, you've signed the worst contract possible and the company should go out of business. Most of the time, they claim things you make using their resources or company time. Avoiding that avoids most issues.

Anecdotal, but most companies I've worked for have policies that claim ownership of everything I produced in my own time on my own equipment. I think that's the rule, not the exception.

That's awful. You should negotiate that out of the contract or at least limit it.

Definitely not the norm and probably not enforceable. I hope you find a new job!

The article doesn't mention bias from employers, the problem is just delivering a course sustainably that gets people employed as devs.

You're right, maybe not the right thread for this.

I was commenting less on the article and more on the general disdain for bootcamp grads that seems to crop up in every article or thread about them. It always devolves into whether people with this education or that education are any good, and it's just completely irrelevant.

How do you know how much of the work person has actually done the work in the repo rather than fork and change, or even recommitting the files, copy-pasta, etc.?