
Ask HN: How to be a great Junior Engineer? - aJuniorDev
I recently joined a tech company (roughly 200 employees) as a Junior Engineer.<p>From a Senior Engineer&#x27;s (or teammates) perspective - what would be the ideal characteristics of a junior engineer joining your team?<p>* Asks lots of questions vs. making independent decisions on tradeoffs?
* Seeks additional code review vs. pushing a project and getting started on the next?
* Self picks projects from the backlog vs. asking after each project what I should work on next?<p>It&#x27;s my first time working as a full-time software engineer. I can write the code, but have zero experience in &#x27;this is how a junior dev should approach their role&#x27;.<p>Thanks!
======
borplk
\- Do _some_ research before asking a question. At the very least you should
google a few keywords and look at the first 5 pages before raising it with
someone else.

\- Don't ask things you can easily find yourself. I've had junior engineers
asking me "does git blah has a flag for ...?". It's disrespectful of that
person's time.

\- Don't question every tiny little thing you come across. Organisations can't
maintain perfection, there's gonna be ugly things and people are aware that
there's always room for improvement. Sometimes there is complicated history
behind things that look stupid on the surface. Some things are the way they
are just because they are. Not everything has some grand reason or
justification behind it. Sometimes people keep asking questions like "Why was
this written this way? Why was it not written that way? Why can't we make it
better? Why can't we make it faster?"

\- Remember the ugly crap you are seeing today was someone else's shiny shit
some time ago and you are not an exception. The cycle will continue and the
perfect little happy function you are writing today that's gonna solve
everyone's problems is going to be the next person's ugly crap to rewrite and
refactor and clean up after you have moved on.

~~~
cakes
Agreed and, additionally, don't escalate something you perceive to be "wrong"
up the chain of command without at least checking some history and/or asking
around.

------
cshipley
After 25 years in the industry, and been in the roles of senior engineer, lead
engineer, manager, business owner. Here is my advice and thoughts.

Companies, divisions and teams are inherently social and political.
Communication is very important. Understanding other people's perspectives,
even if you disagree. Keep your emotions in check. Take the high road. Don't
assume malice when incompetence is a sufficient explanation. Go out of your
way to help other people. It builds good karma that will pay you back. Get to
know other people in the company. Talk to them and show interest in them.

Perception is king. The only thing that matters is other people's perception
of your you and your work. That said, the best way to increase people's
perception you is to be a hard worker. Manage the visibility of what you're
working on and look for visible things to do. When a department is being
downsized, it's the people who are perceived to be of high value that are
retained. Remember that you're being watched, even when you think you aren't.
Don't look at porn at work. Don't be the last to arrive at work or the first
to leave.

Knowledge should be your main goal at this point. Knowledge increases your
value. Learn new technologies. Absorb as much as you can. Become the expert in
niche technologies used by your team/company. It is your responsibility to
make sure you understand what needs to be done. Don't expect someone to
explain it to you. Make an educated guess about what are the relevant for next
year and learn those. Code at home. Follow your interests.

------
officialchicken
Congrats!

Rule #1: Never ever stop tinkering or hacking on your own interests.

Rule #2: The passion to code will come and go, but keep your mind and body
razor sharp with quality food/exercise/sleep.

Don't try to reinvent the wheel[1]. Every problem you're trying to solve has
probably already been solved.

Verify all of your assumptions - ask questions, and realize the context the
answer was given (i.e. the same answer may literally not apply to production
vs development enviros or one language/API vs another).

Learn how to debug (this is an art), write tests, formal and informal QA
procedures, write documentation, and how to get your code pushed upstream (the
process) without breaking the system or anyone else's code.

Even if you've mastered the problem domain, most teams limit the ability to
contribute too much the first couple of weeks because you need to earn the
trust of your team (usually via a combo of defect-free code, humor, and
general geek knowledge). Once trust/confidence in your ability is established,
you will have plenty to do, and lots of guidance if necessary. But you may not
be able to implement your idea for a new foo() in the product until you have
reached that point. But watch out for NIH syndrome too.

Rely on more experienced members to help you organize your code files and
assets to begin with - align with whatever the team expects. There are project
standards, naming conventions, etc. and most of the time it's not written
down. Or self-conflicting / clear as mud.

Don't be the dev that delivers sub-sub-standard code that's full of bugs. It's
OK if it happens at first, but understand why it happened (root cause
analysis?)

If you get stuck, please ask for help (or pseudo code) sooner rather than
later. Like an hour or less. Some team members will be better teachers than
others.

Good luck and happy coding.

[1] Consult experienced wheel builders first to make sure that it's your ONLY
option.

~~~
afarrell
> Learn how to debug

I recommend this book: [http://www.amazon.com/Debugging-Indispensable-
Software-Hardw...](http://www.amazon.com/Debugging-Indispensable-Software-
Hardware-Problems/dp/0814474578)

------
kevinsimper
You already sounds like you are thinking about the right things. I would say
that there is no correct answer, because it all depends on deadlines and how
busy the senior developers are, but in general:

you can't ask too many questions, BUT when you do get an answer, write it
down!

There is nothing that shows lack of effort when you have to spend your time as
a senior developer repeating yourself because the junior developer did not
write it down or could not remember it.

That is the only thing I would say to you!

And good luck and keep hacking!

------
panic
Before asking questions about the codebase, try to find the answer yourself by
reading code and tracing its execution. Don't be afraid to fix problems
anywhere you find them. This can be a good opportunity to learn how the system
as a whole works.

Participating in code review is great: if they're OK with it, try reviewing
senior teammates' commits as well. You can learn a lot by questioning why
particular decisions were made, and you might even uncover a bug or two.

------
facorreia
As a junior engineer, you're expected to be able to handle specific tasks,
that usually have been specified to some degree, or that follow existing
patterns.

This is in contrast with senior engineers, which are expected to be able to
handle responsibility for a large system or subsystem, and to be able to
design and coordinate execution of work at a larger scope.

In consequence, junior engineers usually are not expected to have necessarily
a very broad knowledge of different disciplines, methods and tools; they need
to have sufficient knowledge to execute the tasks that will be assigned to
them, and the ability to execute them correctly.

One particularly important skill to develop is how long one should try to find
out things on their own, before asking for help. Many people fall into
extremes -- either ask for specific help at every step (which hints at
incompetence for that task) or waste many hours or days following a wrong path
when a 5-minute chat with someone could have pointed them in the right
direction (e.g. "use this library").

So my advice would be to find out which are the kind of tasks that you are
expected to do at this point, which tools (including programming languages,
database, web server, etc.) that you need to know, and focus on doing a good
job in those specific tasks.

At the same time, slowly start increasing your scope (e.g. by doing reading
and playing with different tools in your own personal time).

My main practical advice would be to make sure you understand the requirements
of the tasks that are assigned to you. It's very common that senior engineers
take something for granted, as obvious, but junior engineers miss those
implicit requirements. E.g. "of course it needs to be highly available, fault
tolerant, and with sub-millisecond latency, duh!"

------
gonyea
Stop tip toeing and acting like you're wasting people's valuable time. You're
not. Be fearless, ask for info and get free lessons. Ask to pair. It's all
about you.

With that mindset, you'll know the product inside and out. No one will be
thinking of you as Jr after a few months.

~~~
whichdan
100000% this. If someone is hiring you as a junior developer, it's because
they want to mentor/train you!

------
bjourne
I don't see why the junior qualifier would be relevant. A great coder is a
great coder. Always try and learn new stuff, be humble, be analytical, help
people around you, don't talk shit and so on. If you are worried about how to
fit in in your workplace, then that is a different question.

------
cjhin
Ask the other engineers on the team these questions!

Every engineer and every team has different styles and preferences, and the
only way to learn is to ask (and also work with them for a while).
Alternatively, ask if there are any documents that outline established team
behavior/culture.

------
atarian
If I was a senior engineer on your team, would I be willing to get a beer with
you? i.e. the most important advice I have is to make sure you ALWAYS have a
good attitude.

People are always willing to praise, help out, and even promote guys with good
attitudes.

~~~
iqonik
Plus most of the best technical conversations take place over beer. Lots of
beer.

------
debacle
Don't be afraid of looking stupid in any capacity.

