
Ask HN: As an entry-level developer, what's expected of me on the first job? - csnewb
I graduated with a B.S. in Computer Science in September, and recently got a job with a well-known Silicon Valley company. It&#x27;s not a top-tier&#x2F;&quot;Big 4&quot; company, but its well-known and has been around for a while. Although I had one internship during college, its significantly easier compared to the work that I&#x27;ll be doing, and in no way do I feel prepared.<p>Quite honestly, I&#x27;m a weak programmer and it takes me a long time to do things, but I do take pride in having the perseverance to push myself hard to accomplish things. During the interview I didn&#x27;t know how to solve any of the technical problems, but through a step-by-step discussion with the interviewers I eventually arrived at the solution. Possibly what got me the job offer was my enthusiasm for what the company is doing. Its in the field that I&#x27;m very interested in, and am incredibly fortunate to have gotten this position.<p>I start in a couple weeks, but I can&#x27;t help but feel like I&#x27;m going to hardcore struggle and that I somehow fooled the interviewers by making them think I&#x27;m smart when in reality I&#x27;m just a mediocre guy and they&#x27;ll be pissed when they found out...<p>Will I be expected to hit the ground running and be a rockstar coding ninja? Will I have a mentor to help guide me through their massive code base and answer my questions? Will they patient with me if I&#x27;m slow? So many questions...
======
seren
As someone who work with new recruits, we are not excepting stellar
contributions from day one. We are more looking for people who are willing to
learn and grow, and start contributing steadily in a few weeks or months.

As a rule of thumb anyway, if you are new, you are not going to be in charge
of a critical piece of the infrastructure for years to come. Likely you'll be
giving relatively straightforward tasks, and once you'll have proven to be
reliable you'll be given harder and more challenging tasks.

It depends on the place, but I would say that 80% of software development is
rather mundane and "easy". And for the time being the harder decision will be
taken by more senior people. So actually, starting is pretty comfortable and
easy most of the time.

One piece of advice, do not hesitate to ask questions. We expect people to
have generic CS knowledge, but it is often not enough to understand 20 years
old spaghetti code. The worst recruits are the one that are too paralyzed to
ask any question, and as a result you have to spend twice as long to train
them because you have to guess what's wrong first.

Personally, I don't mind answering question or mentoring new people, I see it
as a form of investment. Sure I am "wasting" a few hour today, but your
contribution will save me countless hours in a few weeks.

~~~
kspaans
Yup, don't hesitate to ask for help when you need it. Don't waste time
spinning your wheels fruitlessly. If you are worried that you are asking for
help too early (i.e. before you have explored the problem to the best of your
abilities), then try writing an email (or something similar). I find it to be
a useful way to anticipate the questions that others will ask ("Oh, have you
tried X yet?", "Have you tried turning it off & on again?"). If you can't
answer any of the extra questions that you come up with composing your email,
then it's probably a good time to ask for help.

~~~
Bdiem
The process of structuring and explaining a problem to yourself via email or
as before mentioned as "something similar" is available as a service:
[http://duckie.me/#about_section](http://duckie.me/#about_section)

Related information:
[https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)

This method helped me alot as I found myself explaning a problem to a
colleague finding the solution through the indepth explanation, wasting both
of our time and focus.

------
onion2k
_Will I be expected to hit the ground running and be a rockstar coding ninja?_

No.

 _Will I have a mentor to help guide me through their massive code base and
answer my questions?_

No.

 _Will they patient with me if I 'm slow?_

Yes, but only within a certain latitude. You'll be allowed to make mistakes,
but only once - if you repeat the same mistake that's definitely considered a
bad thing. You'll be expected to learn from your experience, from code
reviews, and from what other developers tell you.

While that might sound scary it's also worth noting that you'll probably be
given relatively simple tasks, like building forms and fixing bugs, so there's
nothing to worry about. You should be able to do what's asked of you because
_anyone_ who has the confidence in their ability to even apply for the job
should be able to do those things. Being "mediocre" is OK. Developer ability
fits a bell curve - _most_ developers are "mediocre" in the sense that they're
in the middle of the curve rather than "great" or "awful" at the top or bottom
ends.

Follow the company's practises, think through things, listen to other people,
and find what you're good at, and you'll be fine. To be honest, I'd rather
work with a junior dev who knows they're not a rockstar coding ninja but wants
to learn than a junior dev who thinks they are, even if they actually are.

~~~
seren
> Yes, but only within a certain latitude.

Another piece of advice related to that. If I am giving long, complex and
detailed explanations to a new guy, and he is not taking any notes.

I have to assume that :

1\. He has a good memory, and he will remember everything tomorrow (and I am
totally fine with that)

2\. He is totally oblivious of what I am talking about, and he will ask the
same question tomorrow.

So please, never put yourself in category 2. Be a genius, or take notes. And
always taking notes, especially the first week, is useful because you'll get a
lot of information in a short time. It is good to be able to process it a bit
later on.

For bonus point, if this is actually some process we have not documented and
should be, take this opportunity to create a reference document for the next
guys, it will be appreciated by your co-workers. You have a fresh look on
things, this is valuable.

~~~
allan_s
I second that, especially for the bonus point part. You'll need note anyway,
one day or an other, and writing them on the wiki/knowledge/whatever of the
team rather than on a sheet of paper, will also permit you to have some double
check from your team members, which may clarify even more your comprehension
of the subject.

------
neilm
The most important thing: don't worry about it.

You will probably feel overwhelmed on your first day, probably in your first
week too. That's normal. It takes time to get used to how the company works,
how the codebase is structured, who's responsible for what in the
organisational structure.

If it's a good company, there should be someone who you will be able to ask
anything you need, no matter how often you need it. I've run multiple projects
with perhaps a dozen programmers, and I try to make it very clear to new
recruits that they are never bothering me. They don't usually believe me at
first, but I mean it! Any significant codebase has a huge amount of knowledge
and structure known only to its developers, and new guys save so much time if
they can just ask a quick question than dig around for themselves. So don't be
afraid to ask questions incessantly. Definitely form your question sensibly,
but don't sit around feeling stuck.

Honestly, I feel the most important thing you can learn in your first day/week
is who is the best person to ask about each part of the code that you'll be
using, and a bit about the general structure of the code. You shouldn't
expected to produce anything straight away.

Also, have fun! I still really enjoy programming after doing it full time for
15 years and hopefully you will too!

------
hashkb
First of all, you're probably a stronger coder than you think you are.
Secondly, your B.S. in Computer Science (assuming you absorbed at least a
tenth of the material) gives you an advantage that many "rockstar coding
ninjas" are operating without. So, you're worried they'll figure out you can't
code, but they're just as worried you'll ask them about the runtime complexity
of what they wrote.

Also: taking longer than others isn't the same as being weaker, especially if
you do a better job. I would happily pay 50% more (in time) for 15% fewer
bugs, or better performance, most of the time.

Edit: typo.

------
squarepirate
Like you said, the company has been there for a while. So, they had plenty of
bad and mediocre coders. You won't fool them easily. They probably know the
difficulties you have, yet they did hired you. It's not like they expect you
to be the best but they know you have what it needs to be it. Programing is a
team effort.

------
JSeymourATL
> Will I be expected to hit the ground running ...

Very few companies do a good job nurturing and guiding new hires.

However, you can take ownership of managing the process. Read George Bradt's
book New Leader's 100 Day Action Plan, while geared towards mid-to-senior
level executives, you'll find many solid take-aways on managing up >
[http://www.goodreads.com/book/show/16775717-new-
leaders-100-...](http://www.goodreads.com/book/show/16775717-new-
leaders-100-day-action-plan)

On Mentorship-- the best mentoring relationships grow organically. Regularly
seek out the advice and counsel of senior colleagues, go as high-up as you
can. You'll know the ones you click with. The best senior execs will actually
welcome a reverse mentoring opportunity. There may some things you're able to
help them on.

------
logn
Be sure to test your code. Even if it's obvious that it should work.

Learn everything you can from code reviews. If you are not humbled in code
reviews then the reviewers are doing it wrong.

Get good at the non-programming parts of the job too. You'll be surprised at
how much of your day will be spent on configuration, builds, etc. Try to learn
this just like you would with programming instead of asking the senior dev to
set something up for you.

------
junto
Listen, learn, pay attention, ask questions.

Being passionate about learning helps a lot, even if the focus of your work is
dry.

I work in the insurance vertical and it is pretty dry!

------
brogrammer90
Your contributions aren't that important. What is important is how much you
pander to the senior members of your team and other teams. Your manager will
consult with them to determine your worthiness. If the senior engineers think
you're "smart" and a "good fit", you're on the trajectory to career
advancement.

------
camel_gopher
Some goals:

() Don't write code that takes the site down.

() It's ok to take a bit longer to finish something, just try to make sure
it's tested well. If you release something and there's a problem, make sure
you write a test for it.

() If you screw up, admit it, and let your boss know what you've done so that
mistake won't happen again.

() Chill out and get hacking!

------
DrNuke
You are in, that's good news because 1) they think you may come good for them
and 2) they will make you come good, provided you show willingness, enthusiasm
and grit. So, no worries, congrats on the job offer and good luck!

