Ask HN: How to start a job

You will most likely be working in a small area of the architecture (for example WebServices). Learn your small bit of architecture first, and become an expert on it. You will naturally start learning about other pieces of the architecture through your own (if you are building Services you will learn about where you are getting your data, etc). However, don't be complacent, force yourself to learn the pieces of architecture that connect to your piece, and move in a direction that makes sense for you. If you are starting out building services and want to do more front-end work, learn about the rendering stack, etc that is consuming your service. If you're more interested in the back-end, start learning whatever database you are consuming in your services really well.

As you grow in the company you should constantly do this. Once you become more of a value than a liability in one area move onto the next. This process should take months, if not years, so be patient and give yourself grace.

Here are some points that helped me and may help you :-

1) Every time you think of a question, write it down. If it's not the right time to ask now - when it is, you'll have them to hand.

2) If you're stuck with something consider where are the places you'll likely find help on it. When you go to ask a colleague, point out that you've tried here, here & here but still aren't sure and could they point you in the right direction. There's a big difference between helping you out and thinking for you. Ensure that with each problem you're taking a few investigative steps of your own.

3) Ask people to draw diagrams for you. Ask people in general conversation the same questions and compare their answers. Some people explain things in really awesome ways & some don't. Some have just 'lived' it that long it's second nature.

4) Keep organised documentation. When I'd learn a new process, I'd write it up & keep it in my file. It calms the feeling over overwhelm knowing that you are building your own backup. Also some tasks only need to be done every few weeks so there's limited opportunity to practice and notes from your first go will be very welcome.

5) Be enthusiastic and ask to sit in on conversations or discussions where possible.

6) Don't ever ever be afraid of asking someone to clarify something. It can be intimidating in a bigger company to say "could you just run that by me again" or "how do you spell that?" but it can save a lot of misunderstanding down the line - Terminology is key to be able to look up information at a later date.

Hope your internship goes well for you!

1)Ask as many questions as you need, but find times that don't interfere with others too much. Your an intern, they understand that you are learning and expect to help in your learning process, especially since this is your first. As long as your not bugging everyone every minute you should be fine.

2) Read files in the codebase as much as possible. Someone mentions a bug in a file at a stand up? Go read the file. Someone mentions a funny comment made is one of the files? Go read the file. Slow day and you don't know what to do? Read as many files as possible. The first time you get access to a large codebase it can overwhelming, but the more you sit down and become familiar with each file, you will become more and more familiar with it. There is no replacement for just sitting down and becoming friends with the codebase.

3) Out work everyone. In my opinion the way you overcome a lack of knowledge is by putting the work and time in. If it takes you twice as long to do something but you work for twice as long per day you end up with the same output. Now this is an unrealistic example but you get the idea. If you are an intern and out work everyone, you will impress.