Live data from Hacker News

Who Killed the Junior Developer?

medium.com

191–200 of 803 posts

Re: Who Killed the Junior Developer?

#191
Junior developer here.

I worked as a programmer for 1.25 years. I left 3 years ago, the company went bankrupt yesterday. When I last checked about it, I saw several of my coworkers replaced with someone else.

The boss kept adding people to his 10+ sales team, and I remained the only developer. Not very long after I joined I prepared a speech about needing a lot of time and preferably an extra developer to clean it up. The web app was written by 1 person for 4 years. No documentation of course, not tests, guess what also no version control. The boss had a sales background and I guess he considered salespeople sources of income, while developers - sources of expenses.

I guess I should be grateful that he hired me? Yes, but the only thing he cared about was if it works and how it looks from the outside. The few online comments there were on the bankruptcy article included one that said the place had mobbing, and another he was lucky he was rejected when asking for a job there because the interview was terrible. (When I was applying, I got a proposal to work with no contract in exchange for higher pay. I rejected that one.). I thought I was maybe paranoid or oversensitive, but now I'm sure I got hired in the first place because I looked desperate.

If I performed stellar, I would have a good success story, but there's limit to how many advanced topics a junior developer can pick up alone while still cleaning up. REST endpoints could really have helped against competition, but then again if he hired an experienced dev after me he would have saved him too. I made a point to write reST documentation describing everything I learned during refactoring/upgrading process, how to run tests, what the various modules are for, where the bottlenecks are, the staging server image, etc.

I fucked up when switching jobs and didn't sign a contract immediately. I thought a verbal agreement was enough. Then I was fired after 4 days, citing poor performance, slooow work speed etc. I never thought I was amazing, but with his other hand the new boss offered me to enter an internship program. He said I would learn a lot. He also sent me some Python video tutorials made by his friend (who works at a university). I told him I took mine from MIT and certainly don't believe a country whose best university is not in the top 400 globally could produce something better... and it was basically a backwater university, not even the top one. Later I found out he had a deal with an (state-funded) employment bureau. He was providing internship programs for aspiring programmers, and the bureau was super happy to send people on "training programs with guarantee of employment". Both parties were happy - the crook had a constant influx of temporary cogs, the bureau had could boast high effectiveness. I keep seeing new entry level developer jobs from that place, and yet the company is NOT growing.

Let me tell you it takes a tremendous amount of willpower just to train at home and remain employable. I've found that hands down the best thing I can do to keep getting job interviews is to regularly commit to github. I enjoy programming, but I'm not passionate about it. You can like strawberries, but 3 pure strawberry courses a day is too much for most of us. It helps to have not one but a variety of side projects so you can alternate between them, and at least one extra programming language (I rewrote someone's glitch art app in Rust).

It doesn't help job interviewers are kinda autistic. I don't mean in the "they suck" sense, but that they have major communication problems. They never tell why they didn't like you, you must infer it from their behavior and observe what kind of behavior gets you more interviews. They always think they can get another one, so why bother explaining anything. Depression + anxiety doesn't help. Dating is super fun by comparison. At least you get to see a pretty girl.

The bottom line: some people only hire junior devs to cut costs.

Re: Who Killed the Junior Developer?

#192
Got a side question.. how do I tell my junior developer who's still junior that he's not ready for being promoted. He feels he is because he understands more of the code base now, he often makes a lot of mistakes and is ready to point out the mistakes of others. He also does not get off his desk to communicate or question requirements.

Re: Who Killed the Junior Developer?

#193

The growth of undergrand CS program enrollment is pretty insane, same with bootcamps. Lots of these people have no real interest in the positions outside of pay, which is fine for most careers. But in tech we put a lot of value on self learning and interest. I've definitely seen the number of new grad applicants and bootcamp grad applicants at least quadruple in the past few years. Most of these can make an Angular a…

I liken the bootcamp business to the mortgage lending business before the subprime crisis.

In the beginning, there were plenty of candidates that were suited for careers in software engineering. Now we are at the point where each school has fewer great candidates so they market to a bigger audience.

Re: Who Killed the Junior Developer?

#194

I teach at a Bootcamp and see a lot junior developers looking for jobs. Many of them complain of it being hard to find jobs and it is. But I don’t think it is any harder than say 10 years ago when I got started. The main the problem is they’ve never interviewed for a technical position before or aren’t looking in the right places for jobs. Also a lot of jobs are perfectly suited for juniors but it doesn’t reflect tha…

Searching for a job is way easier if you have a professional network to draw on and beginners, pretty much by definition, really don't.

> a professional network

How? Let's say I work at some company...Then I know exactly my coworkers and customers. How does that help me build a network?

I could maybe ring up some buddys from uni that are working somewhere else... But contact to them also gets lost over time.

Re: Who Killed the Junior Developer?

#195

I teach at a Bootcamp and see a lot junior developers looking for jobs. Many of them complain of it being hard to find jobs and it is. But I don’t think it is any harder than say 10 years ago when I got started. The main the problem is they’ve never interviewed for a technical position before or aren’t looking in the right places for jobs. Also a lot of jobs are perfectly suited for juniors but it doesn’t reflect tha…

I think bootcamps are flooding the market with juniors. This may be the source of the issue. It could be a supply side issue. Too many juniors leads to the perception that nobody is hiring juniors.

Or maybe too many badly trained people (sorry a 6 week JS course doesn't make you a good developper) are trying to bullshit themselves through interviews, which casts a bad light on all of them.

Re: Who Killed the Junior Developer?

#196
post #179
post #140

Earlier quoted context omitted.

I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.

Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything excep…

I feel like the problems you're describing are more workplace specific and not specific to the method of CR itself. For example,

> They started humble and ended afraid to do anything except simplest tasks.

It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.

> Also, they got only and exclusively negative feedback.

This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!

All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.

Re: Who Killed the Junior Developer?

#197
post #95

Earlier quoted context omitted.

When I first got into programming, as a high school intern in the early eighties, I was told a programmer stays at a job, on average for the years. I haven't heard this number change at all. While I'm sure there are many jobs where people stay along time, the average length of stay is still fairly short. Boredom and wanting to work on something new is probably the biggest driver

Boredom and wanting to work on something new is probably the biggest driver I have to disagree with this point. Switching jobs is a very stressful and scary experience. Most people don't want to jeopardize their income without having some very strong motivator. In my experience, the most common reasons someone changes jobs is: - Promise of a higher income - Low perceived stability at the current job (employees want t…

I HAD to switch jobs 3 times within 2 years when first starting. (Redundancy, restructure, outsourcing.)

It's no longer scary or stressful. I now choose to switch jobs regularly because I get better incentives to join somewhere else and I get more bargaining power with each transition.

C-levels and shareholders made it this way - if they kept with market rates and the organisation put more value in employees and their IT I'd stay around. But I've been seeing more and more of a shift to outcome-based budgeting, maintenance and refactoring isn't even part of BAU budgeting - it's strapped on to project work. This is likely exclusive to non-tech companies (even though most companies are shifting towards tech as their basis ala "Software is Eating The World").

Managers can only do so much within an org, I haven't worked for a manager I didn't like (I've turned down jobs based on my interview process though). Not US based.

Re: Who Killed the Junior Developer?

#198
post #135

Earlier quoted context omitted.

I don't think dedicated mentorship is required for junior devs. There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.

Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.

If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?

Re: Who Killed the Junior Developer?

#199

I love mentoring. I always have. I used to help out other kids in my high school programming classes. Despite holding several high-level software development positions, what is the total number of times I've been asked by management to mentor more junior folks? Zero. I did it because I love sharing knowledge and I like seeing looks of understanding appear on my colleagues' faces when they "get something" for the firs…

I don't think dedicated mentorship is required for junior devs. There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.

When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior.

Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.

As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.

From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.

This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.

There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.

Re: Who Killed the Junior Developer?

#200
post #152

I love mentoring. I always have. I used to help out other kids in my high school programming classes. Despite holding several high-level software development positions, what is the total number of times I've been asked by management to mentor more junior folks? Zero. I did it because I love sharing knowledge and I like seeing looks of understanding appear on my colleagues' faces when they "get something" for the firs…

I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this. Senior devs are held accountable for what they deliver, and doing so on time. This is among other things like code reviewing PRs and attending meetings. For most senior devs working under this circumstance, the best they coul…

Strongly agree. I would like to spend more time teaching junior developers what I know. But anything that slows down a small, agile startup can mean the death of the startup, so this tends to undercut my ability to do any kind of mentoring.

Excerpt from a real life situation I was in:

===========================

June of 2015:

Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.

July of 2015:

I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.

I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

Post reply on HN