Ask HN: Career Advice for a Junior Developer | Hacker News Reader

Ask HN: Career Advice for a Junior Developer

3 pointsrandom42157 comments

Hi everyone!

I am pretty sure that many people reading this are smart developers, and I consider myself one. I am a CS graduate and I have been working for 3 months as a backend developer in a company (in Italy) that delivers mobile and web apps, like many others.

The first problem that I'm facing is that my senior (and my junior teammates) constantly takes bad programming decisions that affects the long-term stability of the project, such as ugly db models or not following the single-responsibility principle for example. He gets to choose all the design but he's not the one coding so he also does not realise the errors by himself.

The second problem is that my company, like I think many small companies that work for clients, accepts projects with low budget and thus there is not enough time to properly write good code (we write js backends without testing >.>).

Obviously I'm not here just to complain. I thought about some solutions I can opt for:

- Work for a big tech company where there is less hurry to finish projects and there are clear coding rules to follow (like testing and so on). Good pay, less pressure but maybe no real engagement of designing complex systems (don't really know).

- Learn frontend technologies and try to slowly become a full stack freelancer. Good pay (hopefully), no boss and I get to design the systems. The problem is getting started, make the connections, build a resume and learn how to do it properly.

- Change from backend to frontend, where maybe design is not so important, though I don't really like it.

- Change to some other field like ML, but I would need some time to study and I don't think I could get a job without a master's degree (you tell me).

I'm really thirsty for your advice. I currently live in Italy but open to relocating pretty much anywhere in the world or work remotely. Thank you for reading this!

First, the are smaller number of smart developers than you think.

Then see the project's scope. Big project's architecture may not works well for small scoped project, and vice versa. As long as it pays well, small, quick, with duct typing projects are worth to develop.

Usually the problem is small project with tight budget, which makes the margin small and causing you unable to improve / improving your tools.

If that's the case, you may look for other company which have higher margin and pay-to-work hours ratio. It does not necessarily means bigger companies.

Now for the paths:

- front end knowledge is valuable even if you don't aim to be front end devs or full stack, so more or less knowing how they work is useful. Afaik react devs are in high demand and highly paid. However front end grows very fast compared to backend.

- machine learning is good, but I lack the knowledge in this topic. My concern is the tooling today may be very different with the tooling in following years, CMIIW.

Thank you for the comment. Do you have some advice on how to see the mode of working within a company during the interview process? Or how to choose a company before sending an application.

For me, I especially avoid companies which take and create multiple projects for clients, or outsourcing companies.

If you love quality, look for companies that have / makes product(s), or companies that use their own product (such as SAAS).

Personal opinion to your 2 problems: 1. Work with your teammates to figure out what is the best for the company. It may be hard, due to communication, personality, etc. But the bright side is now you get a chance to show your skill, your leadership. Maybe you are able to be the lead of the engineering team after 2 years, and become a partner of the company owner. If you feel the senior is making bad decisions frequently, talk to them, talk to their boss, talk to the company owner, WITH PROVE. (if the company's culture is truly toxic, quitting the job is also a good option).

2. don't worry about test. the most popular open source project(linux kernel) do not have test code. it is overrated. When you interview for a job, nobody will ask you how good you are in writing tests. If I were you, I would prefer no test code required, so that I can focus on learning more important stuffs to grow myself: design pattern, infrastructure consideration.

3. about ML: you don't need degree. if you can be top 10 in kaggle, nobody cares your degree. If you truly like ML, you probably don't care about the job. How do you learn ML: google, online courses, and the most important: projects. The best case is that you can work for a company that is willing to hire you as a software engineer but then they allow you to work on ML projects. But this is kind of luck and you have to do google search to find that type of company. But, getting a degree and naturally getting hired as a ML engineer would be safer plan if you have decided ML is what you like. But there is cost: time and money.

Thank you for the comment. For what I know about ML once you have a problem you just pick some solutions from the literature that apply well to that problem and use them. Apart from the engagement of reading papers, do you think there is some interesting problem solving in that field?

I am not a ML expert, so I cannot give you correct guidelines. But I do know that there are a lot of problems in kaggle. You can pick a direction/domain: cv, reinforce learning, nn, etc.

Keep learning. Customers don't care if something adheres to SRP or not, they just want the output - if it works (good enough) you might get repeat business.

Reply on news.ycombinator.com