Ask HN: As an entry-level developer, what's expected of me on the first job?

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.

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.

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

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.

You won't let someone take charge of a critical piece for years? This certainly can't be good general advice.

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.

> 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.

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.

In the general case, would recording the conversation (probably just audio) likely be found acceptable?

I'd expect to prearrange terms for how the file(s) would be stored (encryption etc) and hard limits on how long they'd be kept.

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!

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.

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.

> 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-...

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.

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.

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!

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.

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!

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!