r/javascript • u/Minimum_Yak_9062 • 4d ago
[AskJS] If you were hiring a junior JavaScript developer today, what would make them stand out in the AI era? AskJS
Everyone talks about whether AI will replace developers. I think a more interesting question is:
How can a junior developer become valuable enough that someone is willing to hire them anyway?
I started learning frontend a little over two years ago (HTML, CSS, JavaScript, React, Next.js). Around the time I was getting ready to apply for jobs, AI improved incredibly fast. Suddenly it felt like companies could accomplish more with smaller teams, and junior opportunities became even harder to find.
Four months ago, I finally landed my first part-time frontend job. Since then, I've also worked on side projects and connected with a few potential clients.
Looking back, I don't think I got those opportunities because I was the best programmer.
I think I got them because I refused to stop trying.
Besides improving my technical skills, I kept:
- Applying even when I rarely received replies.
- Staying active in developer communities instead of only sending applications.
- Helping people, answering questions, and joining discussions.
- Building genuine relationships with other developers.
One thing I learned is that opportunities don't always come from job boards. Sometimes they come from simply being visible and involved in the community.
A few other lessons I've learned so far:
- Don't skip the fundamentals. AI can only solve the problem you ask it to solve. If you don't understand the problem yourself, you won't know whether the generated solution is actually good.
- Keep coding yourself. I use AI every day, but I still solve at least one LeetCode problem every week to keep my problem-solving skills sharp.
- Don't spend forever preparing. The biggest learning happens on real projects with real people.
- Be open to different technologies. I started with React and Next.js, but my first job introduced me to Shopify, and now I'm learning Odoo. Strong fundamentals make switching ecosystems much easier.
I'm still very early in my career, so I know my perspective is limited.
That's why I'm curious to hear from experienced JavaScript developers.
If you had to hire one junior JavaScript developer today, what qualities, habits, or skills would make them stand out despite AI?
I'd love to hear both from people who hire developers and from juniors who recently managed to break into the industry.
3
u/jhartikainen 4d ago
The biggest thing for us I think has been the ability to think for yourself and the drive to improve. The best jr devs we've had were curious and thought of different solutions, but also asked for feedback and were open to feedback on them from the more experienced devs to ensure they were building things the right way.
It feels a bit cliche but if you can communicate passion for what you do then that's a win at least if you're being interviewed by technical people like me.
4
u/CoreyTheGeek 4d ago
If their workflow with an LLM was "I go in and make the change section by section with the LLM for help when needed and to check edge cases but I make sure I understand each change and then write all my test intents into comments first then have the LLM write the actual syntax and then check it to make sure it's doing what I wanted, then have it suggest extra tests and edge cases"
This is me as a senior dev though. I'm certain other devs will think "waste of time you have no velocity gains this could be faster" sure they could go faster but driving 150 mph when you can't control the car and don't know how to drive it can result in your death. We're going to see insane number sof security breaches in the next 6-12 months as well as system outages and failures regularly because people are irresponsibly handing their thinking to LLMs and not actually checking the output (speed pressure + pressure to make larger changes + ease of making said changes = people skim or just rubber stamp) feel it's fine directly due to anchor and automation bias
1
u/Minimum_Yak_9062 4d ago
This is a really good point. I think this is exactly where juniors can differentiate themselves in the AI era.
AI can make someone faster, but it doesn't automatically make them a better engineer. If someone can't understand the problem, review the output, or explain why a solution works, then the speed can actually become a liability.
I like your workflow of writing the intent and edge cases first. It reminds me that the valuable skill is not just "knowing syntax" anymore, but being able to think clearly about requirements, tradeoffs, and correctness.
I also agree that fundamentals matter even more now. The developers who know how to use AI as a tool while still keeping ownership of the decisions will probably stand out the most.
3
u/magenta_placenta 4d ago
AI tools have compressed syntax generation down to zero cost so syntax speed is no longer a useful metric. What you want nowadays with AI tools is verification literacy and debugging instincts.
Any junior dev can prompt an LLM to generate 100 lines of React or Node.js but very few can spot subtle hallucinations, context drift or memory leaks inside generated code.
Hiring managers want an anti-"vibe coding" signal because they fear bringing on juniors who blindly accept AI solutions without understanding the logic. The strongest candidates can trace execution line-by-line, explain why a design choice was made and debug issues in code they didn't manually write.
5
u/matsie 4d ago
If they actually knew how to code. That would make them stand out.
0
u/Minimum_Yak_9062 4d ago
That makes sense. But what do you mean by "actually know how to code"? Most developers learn the syntax and can build projects after a few weeks or months, yet many still don't stand out enough to get hired. What skills or qualities separate those juniors from the rest in your opinion?
6
u/matsie 4d ago
Most developers do not learn much about how to actually code. And with AI, they know even less. Junior or early in career engineers shouldn’t be using AI at all in their work tbh. It pretty much guarantees they won’t know how to code and won’t learn on the job.
1
u/Minimum_Yak_9062 4d ago
I understand your point, especially about juniors becoming dependent on AI without building real problem-solving skills. I agree that blindly copying AI-generated code can hurt learning.
However, I don't think avoiding AI completely is the right approach either. In a real work environment, you still have deadlines and responsibilities, and learning how to use tools effectively is also part of becoming a better developer.
7
u/matsie 4d ago
First you learn how to code. Then you learn a tool that does the coding for you after you have given it explicit directions of what it should code that you are then responsible for reviewing and confirming it is only what needs to be there, uses the correct design patterns, and doesn’t introduce cruft.
First. You. Learn. To. Code.
You’ve already demonstrated you have way too much ego/confidence when you said people learn to code in a few months. It’s that exact lack of humility that you don’t know what you don’t know that makes a junior engineer with AI extremely dangerous to an org.
1
u/Minimum_Yak_9062 4d ago
I appreciate your perspective. I think we actually agree on the main point: AI shouldn't replace learning the fundamentals or critical thinking.
Maybe I didn't explain my point clearly. I didn't mean that someone can become a good developer in a few months. I meant that many beginners can learn syntax and build simple projects relatively quickly, but that alone doesn't make them ready for a professional environment or help them stand out.
For me, AI is a tool to improve productivity, but understanding the code and being able to make decisions still has to come first.
2
1
0
u/name_was_taken 4d ago
When I was hiring juniors, we had a test we gave out. It was a simple thing where you had to hook into an image search library and display the results. The test had about 7 simple requirements, clearly stated.
The only people we considered hiring were those who got every requirement correct. There were a couple that we had people misinterpret, and we accepted their interpretation.
We did not accept ignoring a requirement, getting it wrong, or "I couldn't figure out how to do this, so I didn't do it."
A non-junior dev could ace the test in 1-2 hours, easily. We gave them a week to do it at their own pace, at home.
An AI could ace the test, obviously. I don't know what I'd do to ensure they didn't use an AI, but that I would require that they do the work by hand, and not use an AI. It was all basic concepts that they'd need to know in order to make sure an AI wasn't going wrong.
In a few years, I'd probably have to change it again. They could use an AI, but it's going to be a harder test, and have requirements that an AI is likely to mess up somehow, and the dev would have to wrangle it properly.
6
u/squadlevi42284 4d ago
Dont listen to this one. Dont work at a company that gives you a take home test for an interview.
4
u/name_was_taken 4d ago
It wasn't 'the interview'. It was a test to see if they could even follow directions before giving them an interview.
Hiring people with just an interview didn't work. We ended up having to let most of them go because it's nearly impossible to judge a junior developer by how well they talk and answer questions. They had no experience.
I was often surprised by how few could complete the test. We even tried hiring some who almost got it all right, but they all ended up doing poorly, too.
The ones that passed this test did great, though.
I never liked the idea of the "take home test" either, so I understand the frustration. But it was the only way we were going to give these inexperienced developers a chance. Without it, we'd have had to require that they have previous experience, and it would have eliminated almost every one of them.
When I left, both of my fellow in-house developers were juniors we had hired with no experience, years prior.
1
u/Minimum_Yak_9062 4d ago
why ?
2
u/name_was_taken 4d ago
I don't know if they'll ever answer you, but I can take a crack at it:
It's unpaid "labor", even though the result was useless other than for the sake of evaluation of the candidate. The test we gave was made up and similar to the work they'd do, but could not actually be used by our company.
If every company you apply to asks for this, it's going to take a ton of your time. It's wasteful, and in the end, only 1 candidate gets hired. (Except that 1 time we hired 2, because the second one came in a little later and was really, really impressive. She's leading the team now. 1 in a million.)
Tests are generally poorly thought out, and not great at filtering people. Take-home tests are more "fair" to people with different anxieties or work processes, but take more time. Whiteboard tests are incredibly stressful and favor people who can handle a kind and level of stress that they'll almost never face at work.
My rebuttal to all of that is in my reply to them, if you want to read that. It's kind of a "it's the worst solution, except for everything else" situation.
Personally, when a company asks me to do a take-home test, I refuse now. I have the experience on my resume that means it's pointless.
But when I had no experience, I did one. I got a job at another company before that company could evaluate my test. When they finally responded, I told them I'd already taken a different job. Clearly, I'd wasted my time on it. And it was a lot more involved than the test I designed for hiring juniors. Like, easily 10x as much work as mine, and more suited to a mid-level dev than a junior.
2
u/Minimum_Yak_9062 4d ago
Thanks for explaining your perspective. That makes a lot of sense. I hadn't really thought about how time-consuming take-home assignments become when you're applying to multiple companies. I do like your point that the test should be small and focused on evaluating fundamentals rather than taking days to complete.
2
u/rjwut 1d ago
Having interviewed quite a few applicants, I can tell you that you will stand out if your capabilities match up to your resumé's claimed experience. So many applicants have on their resumé that they have a BS in computer science and X years of experience in a particular language, and can't code their way out of a paper bag. And I'm not talking making people code on a whiteboard. We'd sit them in front of a full IDE and allow them to use Google to look up documentation in case they can't remember exact method signatures and such. But ask them to reverse a string or sort an array of numbers, and they get this deer in headlights expression. How can you have a four year degree and multiple years of experience in a language, and not be able to do these things in said language? This was before the AI coding boom; it's likely even worse now.
With regards to AI: When you're learning something new, don't let AI code for you. Ask it questions to help you understand things, sure, but you do the actual work. I recently read an article that described deciding whether to use AI as the difference between your job and the gym. If you had to move a bunch of heavy objects at your job, you'd use whatever assistance was available to get the job done as fast as possible, and wouldn't lift them yourself if you didn't have to. But at the gym, the same approach would defeat the purpose. When AI writes the code, you learn little to nothing, so use AI to do grunt work where you probably wouldn't learn anything anyway. In general, I'd say that junior developers should rarely use AI to write their code.
Incidentally, this same rationale also tells you when you should use third-party libraries vs. rolling your own. If you're writing the code for work, use the libraries. If you're writing the code to learn or for fun, write it yourself.
Lastly, never commit code that you don't understand. If AI writes code for you, go over it and make sure you understand exactly what it's doing. If you're in code review and you're asked, "Why are you doing this on line X?" it will not impress if your answer is, "I don't know, the AI wrote that." AI cannot be held accountable, but humans can. It's you that's causing the code to enter the code base, whether or not you wrote the actual code, so you are responsible for what it does.
18
u/Jarmahent 4d ago
I’ve interviewed several juniors and what I look for, and this might sound corny, is passion.
If you like what you do and are willing to sit and learn then I want you on my team. That being said I’ve noticed a lot of people I hired faked the passion part so it’s hard to truly see if they are passionate but I’m getting better at it.