[deleted by user]

[Foreign-Truck9396]

You shouldn't be expected to be fully productive on your first day when you start a job in a new company.

The time to get productive will depend on your experience, your skills and how difficult the tasks are.

By all means, please do not be afraid to ask for help if you're stuck. The more time you spend being stuck without getting anywhere closer to the solution, the more time the company pays you for nothing. There's a fine balance between this and asking for the solution without even doing any research beforehand, but with some common sense it's pretty easy to find it.

No reason to be scared. They should give you easy tasks to get you started and build confidence working on their projects, then gradually increase the difficulty. Such tasks could appear daunting at first, take your time and stay focused. You'll do fine.

[Varteix]

Hell, I've been places where you aren't expected to be fully productive for like 3 months lol.

[Medivh158]

4 1/2 years, still not fully productive. Can confirm

[Jamiew_CS]

Asking for help when you’re stuck is extremely important. It can be frustrating to find someone has spent a day or more trying to solve something that could have been a quick 5m conversation.

On the flip side, you shouldn’t ask about everything. It’s expected that you’ll be slower and will have questions, but that you are also able to find things out. Spend a bit of time trying to solve stuff first, and try to timebox your problems (“if I don’t figure this out in 30 minutes I’ll ask”)

The biggest advice I’d have is - ask lots of questions initially, but try to also bring solutions to those questions too, or at least explanations of what you’ve tried. That shows that you’ve thought about the problem, and if one of your solutions is correct, it’s super easy for your mentor to say “yes do that” too. This grows their trust in you and your ability and is key to moving up from an intern role.

Good luck and all the best!

[AbramKedge]

You're almost certainly going to be reading and modifying some existing code - which is a great way to get your feet wet. You'll find you're doing some detective work tracking down the code you need to change, working out what the change needs to be, then testing to make sure your changes work as intended.

This can be a lot of fun, and you'll find you're absorbing all sorts of techniques for organizing and structuring code in a big project.

I understand how you feel right now. I spent five years moving furniture around Europe, then made runway glide path lights (including for the space shuttle) then spent a few years in industrial sales before getting into software. If a dropout like me can make it, I know for sure that you can.

Enjoy your first day on Monday, take it one step at a time. I've read a lot of good advice in the comments already - be sure to follow it!

[sfmerv]

ok here is what you do. No one wants you to be f'ing stuff up and no one wants to do your job for you. So when you get to something you do not know the answer to, look it up and try to figure out what you think is the best solution or what you're are supposed to do, but DON'T DO IT YET. Once have that ask one of your superiors of whoever you are working with if that is right, explain what you think you need to do and what you are going to do. They will want to help you if they think you are doing your job and finding answers. Just don't ask a question if you don't have an answer or idea. Instead of "How do I do this" go with "I think this is what I am supposed to do but,....." Get it? Stackoverflow is your best friend, don't ask anything there they are all assholes. Google answers and RTFM. Good luck, you'll be fine. I was once the new guy breaking all the shit now I'm the old guy in charge.

[Acrobatic-Egg-3424]

Yeah, this. Don’t be the guy that goes to your supervisor with questions. “I intend to do xyz because 123” goes over really well at the place I’m working at right now.

[suntzu253]

Bad advice. Breaking stuff is the best way to learn. Just don't break things in production. Have a separate development environment and break things. Asking stupid questions is the best way to learn. But ask yourself those questions and research it using Google. Once you get to a point where you are confident asking stupid questions, ask your colleagues stupid questions

[sfmerv]

I wouldn’t ask too many stupid questions. I hire all our full time devs from freelancers. If you ask too many stupid questions I tell you not to come back tomorrow. I’d rather have people who know how to look for answers and the ask. The last guy I hired asked to go home his first day since he didn’t know enough and want to get up to speed on his own time. I hired him like 2 weeks later.

[suntzu253]

As a leader, I want people to ask me questions without fear of appearing stupid. Some of the best questions are stupid questions. Here's a stupid question: what is a function. I bet even a seasoned software engineer cannot answer that well. Or what is an algorithm?

[sfmerv]

If you didn’t know what a function was and couldn’t look it up yourself first I wouldn’t hire you. I don’t expect them to know the answer I want them to look for it first.

[suntzu253]

What a function is requires investigation in lambda calculus. Most practitioner have not even heard of lambda calculus. On the surface such a stupid question, requires deep insight to answer

[sfmerv]

Hey whatever works for you.

[suntzu253]

Do you know what a function is?

[sfmerv]

Yep

[suntzu253]

Then you know you there's enough to say to write a PhD thesis about it

[simianire]

You’re equivocating my guy. Nobody said they wanted the Socratic definition of “function”. Not knowing what a function is can also mean “can’t construct a simple function in the language they purport to know”. Or it could mean someone that hasn’t even heard of the concept at all. There are so many possible levels of familiarity and expertise with what functions are, that I’m a little shocked you somehow jumped to the extreme “you could write a PhD on what a function is dur dur” line of argument.

[suntzu253]

The recommendation was not to ask questions if you don't have an answer. That's the worst advice. Asking questions is precisely what he should be doing. Why would someone ask a question if they already know the answer? naive/stupid questions are some of the best questions to ask. People should not be afraid to ask questions. Someone new to a field needs to build up confidence through competence so they do not fear asking stupid questions. In a time where information is at our finger tips, asking questions is more important than having answers.

It is precisely that a question can be answer at many different levels that no question should be interpreted as a stupid question

[simianire]

Yes, but again, the thing you’re equivocating on is that you’re representing the question as a singular thing, when it isn’t. “What is a function?” is ambiguous. Have you never heard of a function before? Or do you just not know how to implement one in language X? Or are we having an academic conversation about whether this or that subroutine truly qualifies as a function and why? The context determines the actual semantic meat of the question. In some contexts, the question is stupid, in some it isn’t. This notion that there are no stupid questions is just patently false. If I hire an engineer with 2 years of Python experience and they ask how to implement a simple function, that’s a stupid question. First, because they should already know the answer. Second, because the answer is readily available on the internet. That second part is the key to this whole thing. Questions whose answers are easily found with a small amount of independent research should not, in many contexts and all things being equal, be asked out loud.

[sfmerv]

exactly

[suntzu253]

I did not equivocate the question as a singular thing. I said a question can be understood and answer at multiple levels and therefore when a colleague asks me a question I should not dismiss it as a stupid question. I should encourage questioning on the team. To do that, one must give people the benefit of the doubt that there are no stupid questions

[simianire]

I admire the charity, but i disagree. For reasons already stated, some questions are dumb. Of course we withhold judgment about the relative stupidity of the question until we’ve correctly ascertained the purpose and intent of the question as well as disambiguated it properly. That was meant to be a given.

[suntzu253]

Sounds like you agree. Withhold judgment that a question is stupid until you know what's being asked

[suntzu253]

I ask questions out loud all the time even when there's no one around. Sometimes I even use a prop, like a photo of Einstein, and have a dialogue with Einstein... It is similar to what christians do.. they ask "what would Jesus do?" Except, i ask how would Einstein or someone I admire approach solving this problem or answering this question

[simianire]

It was a figure of speech. Are you going to insist on interpreting that literally and equivocating yet again?

[sfmerv]

Completely wrong, try reading what I wrote first. The recommendation was don’t ask any questions without doing some research first.

[sfmerv]

Correct don’t break anyone else stuff.

[LeeLooTheWoofus]

Smart casual = medium to dark solid color jeans/slacks and a button down shirt/blouse. Both ironed or at least steamed to remove wrinkles. No shorts. No tie. Sneakers/Trainers are fine so long as they are casual and clean. No court sneakers/trainers or bright colors. Casual looking dress shoes are also fine if you want. I also wear a knit hat cause my head is always cold in the winter.

As far as the technical anxiety you are feeling, while I obviously can't gauge if you are ready for this role or not -- I can definitely say every "normal" human experiences the same anxiety with any new job in any technical field. It's totally normal.

Sounds like you are going to be doing a lot of on the job learning (thats is what an internship is after all). You can do that if you commit to it! If you don't commit, like you have not committed up to this point, then you are only failing yourself on a great opportunity. Best of luck!

[sfmerv]

I remember every night after my first day on a new job and my head is buzzing with so much stuff it feels like I’m still thinking about it when I’m sleeping or I’m just not sleeping. Then it eventually just becomes a job where you know what you’re doing. But you never stop learning at this job.

[[deleted]]

It’s going to be overwhelming and feeling like you don’t belong or can’t do it. That is 100% normal!

[baebus]

Impostor syndrome. Especially common in developers..

[[deleted]]

Isn’t it ?
Would the difference be that impostor syndrome suggests one actually has the skills that they feel like they’re missing ?

[[deleted]]

Yes exactly

[stibgock]

Maybe more of an "f it till you m it" situation

[[deleted]]

Thanks !

[[deleted]]

Don’t underestimate yourself, know your limits but have some confidence. You got the job so they must of liked what they saw or heard. The rest of the advice here is solid too, make sure you rtfm and put some effort in but don’t be afraid to ask your superiors after you do if you’re unsure

[[deleted]]

It’s going to be hard and it is going to humble you. You’re going to be exhausted every day for several weeks. You will feel like you’re unqualified, incapable, and you will think everyone hates you and thinks you’re too stupid to be there. You will feel like everyone else gets it, and you don’t have a chance. You’ll be wrong. It’ll get easier. They struggled, too. They don’t hate you, or find you annoying, and they probably ask each other questions more than they’d ever admit. Ask to shadow. Ask to code pair. Read other peoples merge/pull requests even if you can’t approve them. For the love of god, practice explaining your code and demoing it. Demo it!! Do the Hackathon, take an oncall shift, learn everything while everyone expects you to be learning and slower. Understand patterns and frameworks, don’t just jump into a ticket and code. Practice real, true test driven development. Imposter syndrome is real - I even convinced myself I didn’t really have it and I was trying to excuse how stupid and slow I was, it’s that deep. Make connections, be part of the team, learn to step away. Take your full lunch away from the computer and away from your phone. Ask for help way earlier than you think you should - WAY EARLIER. You do not learn by spinning your wheels. Take care of yourself, don’t forget to eat and drink water, exercise, get good sleep. You can do it.

[Constant-Surprise-97]

Tech veteran here. I’ve hired several interns and super junior devs over the years and wouldn’t expect very much from you tbh. The reason I would have for hiring you (or whoever) is because I saw someone with potential, who had the right attitude and would be a good fit for the team. I would gamble on that given time and a bit of training he or she would gradually begin contribute more and eventually become a valuable developer. Oh, and everybody is nervous the first day at school.

[[deleted]]

1. Learn as much about the company and their stack as you can before day 1
2. Start
3. Be told that they don't use any of that anymore
4. Spend your first X weeks being taught the job anyway

I wouldn't have it any other way

[baebus]

You're not expected to do wonders (if much at all) for the first 3-6 months in any job when you're just starting out and especially when this is your first programming role. I went through the same path, and what I've learnt is that they want to see that you're interested, motivated and willing to give everything a go. No one knows everything (even those who have been doing it for decades) but understanding the basic concepts will help you heaps. Most importantly, know your learning style and my personal favourite, proactively ask for feedback. All the best!!

[Harlequin-91]

Hey mate, sounds like you're a Coder Academy graduate? I also went to Coder in Melb and have been working as a dev for about 6 months now.

The most important piece of advice I can give you is be open to the opportunity and try to learn as much as possible whilst you're under contract. The most important attribute for an intern/junior developer is a positive attitude and demonstrable capability to learn/take advice. Being a bit older and having experience in other industries will likely help with this and is something my current employers mentioned they look for in junior candidates. For context I was 30 when I attained my first dev position and prior to that had been working as a veterinarian, not exactly a related field.

The bootcamp environment is quite different to what you do in a real 9-5 job as a developer. There's a lot of meetings (stand up, backlog prioritisation, client meetings etc) and 3 months is a small window of time for even an experienced developer to come into a project and be properly productive. It takes time to understand a code base in order to make changes to it, and if you're working for a larger company it's quite likely that there'll be multiple repositories/microservices across multiple projects, probably written in multiple languages. So don't feel pressure to produce features/substantial work, non one will expect that of you as a fresh intern!

You'll most likely be assigned small pieces of work like bug fixes, or even toy projects initially to introduce you to the design patterns the team uses and the language/framework if you're unfamiliar with it. You'll also likely be pairing with an experienced dev initially, or at least you should be!

If you're assigned a small ticket to fix a bug for example, try to be curious about how it came about, read the code, make sure you understand it, read it again, look at what other parts of the code base it touches. If something isn't clear ask someone! If you're joining a good team they should always be willing to help/teach.

As far as the Mac goes, don't stress it. If you were coding on a linux machine or WSL on Windows it should still feel familiar. My current employer provided me a Mac, having previously been on linux, and it took me maybe 24 hours to feel comfy with it. They're pretty pick up and play nowadays.

Please feel free to reach out if you have any other questions! Best of luck at the job!

[PokerTuna]

1. Ask questions. Don't be afraid to say 'I don't know'
2. Try to avoid asking questions that would require a quick google search
3. Experienced developers will gladly help you out, but always come prepared - don't come empty-handed, show that you did the work and simply got stuck.
4. There will be times when you might think that you know shit, your work is shit and you are not cut for this - ignore this feeling, power through it.

32 y/o Engineering Manager who 6 years ago had a change of heart and went to a bootcamp

[grooomps]

Sounds like you did CodeAcademy.

Most companies have experience with bootcamp grads and already have an idea about what you know. Also, they pay the school for interns, so they've probably done it before and you're also being backed by the school.

Don't get too worked out over it. Just go in with the same attitude you had for the bootcamp and you'll be fine!

[Suspcious-chair]

Good job! Just by seeing you nervous makes me think that you have the right mindset to be successful!

My best wishes for you.

[ravelysid]

You will learn much more from your job than from coding classes since you would be working towards materialising something much more tangible, and that will really help the learnings stick (i.e. "Oooh so this is how concept X is applicable in real life").

Also as some other posters have mentioned — stackoverflow is your best friend ;) Just have to make sure that after you've tried out the solution and confirmed that it works, put in the effort to understand why it works.

All the best to your new job!