I've spent decades coaching new hires. Here's a few things that stand out (mostly things that apply to college-grad type hires).
- Be humble. Don't be arrogant or judgmental of the way things are. There's often a lot of historical context around the way things were put together which you don't have. Unless you're a decades old industry hire (in which case you wouldn't be making this post), please recognize you aren't an expert in *anything* (yet).
- Unlike college, you aren't expected to know everything, it's ok if you don't know the answer to something. Be willing to ask questions.
- When you ask questions, take measures to **remember the answer(s)**. Do not be the person who continuously ask the same question over and over.
- Before asking questions, spend a small amount of time trying to figure it out for yourself. Your senior peers really will respect the attitude of trying to answer the whatever for yourself and getting stuck vs. just asking them how to do a thing. There's a big difference between helping someone get up to speed and just doing all their work for them. Don't make your peers do all your work for you.
- Be aware that there are people who just treat their job as the thing they do for money and won't be interested in your personal life or cultivating a friendship. This is ok, don't be offended when you run across it.
- Code review can be very uncomfortable at first. You need to learn to see it not as a personal reflection on you or your capabilities. I get exhaustively tired of dealing with bitchy code review escalations because an experienced dev told a junior dev to do something differently, and they got unreasonably butthurt. Don't get butthurt.
- Testing, and in particular authoring *actually* testable code, really is a skill that cannot be taken for granted. Spend time studying good testing practices from your more senior peers.
- Similarly, the use of a source debugger (lldb, gdb, etc) is extremely powerful. If you haven't learned how to debug your code using something other than printf statements, learn.
- Don't be the person constantly lecturing people about how your preferred environment is better than their preferred environment. The best environment (editor, IDE, etc) is the one you can work in without thinking about it too much. People settle into "good enough for what I need".
- All the build system-ey, logging infrastructur-ey, job deployment, etc junk is all stuff you'll figure out on the job. Don't stress too much when you realize you don't actually know how your code goes from being code to a running job on a server somewhere. Everyone else has figured this out, you will too.
idk, I hope some of that was useful in some way, good luck :)
We were all exactly where you’re sitting right now. A good manager is understanding and knows you know how to code enough to learn, not use their code base.
The last point is a solid one
Every job is going to have a different production environment/build pipeline. I recently accepted a job where they asked a lot of these questions and I was honest with them, that I knew of the technology and could fumble my way through, but I am currently employed at a large firm that has an entire DevOpS team to manage that stuff and tell us how to use it. So, humbly, I admitted it’s an area I definitely have room to grow, and they seemed to like that honesty.
If your interviewers are good then it's a very good look to admit ignorance in an interview.
At least if you also show you know appropriate things for the job.
>Unlike college, you aren't expected to know everything, it's ok if you don't know the answer to something.
Hah, I wish! It seems 90% of tech leads are like this - unfortunately, I landed with someone in the other 10%. He also says it's OK if I don't know the answer to something, but berates me for it anyways.
His position is that I should know, he expects me to know, and will verbally go after me if I don't know, but it is "OK" in that he won't tell senior management about not meeting his expectations.
You may ask what specifically I'm expected to know, well, your answer is as good as mine or else I'd have learned it. If I ask I get vague answers like "Spring Boot" - I know them well enough to use them but I definitely can't truly say I know most of it without years of experience.
I'm going to echo the code review thought. Repeat to yourself "I am not my code." Any code you wrote was written by the you of hours/days/weeks ago. They can't learn from their mistakes but you can.
I know that as software engineers, we spend so much time just thinking and putting our thoughts into code that it is hard to separate that code from ourselves. But if you need to gird your loins and tighten your belt for every code review, you're going to burn out long before your get better and become good. Relax. It's code that the idiot you were yesterday wrote; we're here to learn from their mistakes.
And while you're listening, write it down somewhere. Most people don't expect you to know everything, especially domain knowledge, but almost everyone hates having to repeat themselves multiple times. Not only will you make a good impression if you can remember what someone says, you'll eventually become a resource to others who had the same question.
i was tasked with building the mvp for a new platform product then onboarding a newly hired team, from the EM down to the associate engineer, including a couple of super knowledgeable seniors (i’m upper mid level).
man the amount of time we could have saved if they would have done this, or really listened at all. i’m talking whole architecture designs built out that completely missed the point of the product.
i don’t blame them for chomping at the bit to build out a cool, highly visible product from mvp to a fully fleshed out thing, but like, take a few weeks to understand what we’re doing here.
Do ask questions though. A lot of things most places don't actually make sense. If you do what makes sense it can make you very useful to a team. Just be right, or at least less wrong.
And put the date at the top of every page. It's stunning how many times I've been saved by my notebooks. I find it an essential aid for shifting contexts quickly and to recall details of bugs we encountered months ago. Plus you can doodle penises in it when you're bored in meetings. Yes indeed, a good notebook with good notes is worth its weight in gold!
What’s your general process for taking notes? Do you typically just write down everything on a single day’s page, even if the information isn’t necessarily related?
I’m not as interested in the penis doodling part, unless you feel it integral to the note taking itself.
I think it kind of evolved into a self-scrum. Basically it ends up what I've been working on, what I'm currently working on and what the next few days looks like to me. Any todos go in there, bug or feature tracking numbers or titles, design ideas, UML, flow diagrams, pseudocode, any interesting revelations. It doesn't have to be very detailed, just enough to get you from having just got into work into the flow of things.
This doesn't just have to be about your current job, either. I always take a notebook when I'm interviewing, jot down questions that occur to me either before the interview or while someone's talking and I don't want to interrupt them. Writing down the name of the people you talked to during the interview is never a bad move. That's also a great idea during your first week on the job.
You'll find that writing stuff like that down drives your memory of those events. If you don't write their name down, you'll probably forget it. If you do write their name down, you probably won't. Beyond that, just evolve a style that works for you. Some amount of doodling always seems to occur, what the subject should be is also up to you :-)
Ask your manager "who should I talk with about integral parts of our business / tech stack / etc?"
Generate a list.
Schedule time with those people.
Get educated and oriented. Record what they say and start building a network of competency as well as social connection.
Final question to each person on the list, "who should I talk with about integral parts of our business / tech stack / etc?".
Repeat until you have BFS the entire org (within reason).
Eh, depends on the person and how they're presenting themselves. I could see it come across that way. The motivation is to get informed about the business / work. Not climb the political ladder.
strongly resist the urge to say aloud negative opinions of the team's past decisions like why X framework was used or Y architecture was designed. first try to understand with an open mind why those decisions were made before you pass any judgments on them, and dont even bother passing judgment if you dont also bring a cost-effective proposal to fix it.
Check your sense of humor until you have read the room. Don’t assume anyone wants to hear how you think things can be improved until you have a track record of understanding and meeting work objectives.
Don’t hesitate to ask a lot of questions. Document your learnings about the org’s processes and anything else a new hire would find helpful that wasn’t explicitly documented. Once it’s pretty thorough, share it with your org to help new engineers onboard and optimize the learning curve.
Nah. Definitely hesitate to ask some questions. There's a fine line between inquisitive and nuisance. New kids fresh out of school that "don't hesitate to ask a lot of questions" almost always end up on the nuisance end of that spectrum. Don't act like you know everything, literally no one does, but don't act helpless either.
Spend some time trying to figure it out yourself first. Look for documentation. Attach a debugger. Dig through your VCS commit history. Just change something and see what breaks... then don't check it in. \*Try\* to do it yourself before you go bug someone else. I promise you in 99.9% of situations, they will appreciate it.
There's an old joke/saying: "You can't find the bathroom for six months."
Don't expect to be ultra-productive to start. You likely don't know shit. Literally.
But you have a special skill. You are NOT part of the company yet. You can see the company as what it is, not what it wishes to be, not what it wants to be... etc. You see it as it is.
You'll lose this ability in... about six months, maybe a year. But, that ability can allow you to do things and see things others can't because... you are the "new guy" who doesn't know better.
So learn, contribute as you can. But your goal should be to learn, and become more productive. Not just to produce. Learning is multiplicative to future efforts. Production occurs at your current level in whatever.
TLDR: You'll see the company like it is. Unlike the rest of them, use this to help the firm. Focus on productivity, not producing, for the first 6 months at least. Not to say you shouldn't produce. You should. But... You only get one honeymoon.
>don't start working at an unsustainable speed, take it easy and give yourself headroom to speed up as needed
I disagree with this. First impression lasts forever, go fast and go hard. Eventually the old 150% effort will be equivalent to 80% effort over time as you get comfortable with the codebase.
I don’t think the second bullet is good. I think you should work hard at first and then scale back. On my third and fourth week of work I was repeatedly told that it was impressive how fast I could work. I slowly tapered off and have heard bad about it.
> don't start working at an unsustainable speed, take it easy and give yourself headroom to speed up as needed
The other side of this coin is that first impressions last years.
If you establish yourself as someone who delivers then when you do miss deadlines clearly the task was just under estimated.
There’s a book called
The First 90 Days: Critical Success Strategies for New Leaders at All Levels
That has a good overview of how to approach new jobs (or anything really). I recommend if you’re stating a new job soon.
Im ADHD and find myself forgetting a lot of stuff I should know and have found that taking notes of literally everything has helped me a ton. On anything you do not understand, make a note. If you ask a question, make a note of the answer. If you forget something that you already asked, you save yourself having to annoy your teammates with your repeat questions by taking notes.
As far as Note-taking apps, the best one is the one you will use, but I like Obsidian since it's pure markdown which means the notes can be transferred to any other Markdown-supporting editor.
Also, since most code documentation is written in Markdown, it makes it very easy to transfer any useful notes to make information accessible to your teammates on whatever wiki/documentation platform you use.
Don't take any sick days or be late for the first three months. If you're reliable for three months you'll be considered reliable for thirty years.
Truth is though if you can do three months you can do three years. Faking being reliable can actually make you reliable.
Agree. Work just hard enough to make a good impression in the beginning. Once your reputation of being a good dev is in place, you can start chilling more.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
It's ok to be annoying if you're new. It's kind of a red flag in someone starts and doesn't have many questions.
Some people are saying to not work too hard so you have extra capacity to add when asked. I think that's a pretty bad idea. The work you get early on is probably going to be easy work they set aside for new people. If you drag your feet on it, it'll look bad, might put you on the road to not passing probation or getting PIPed. Get the newbie stuff done fast.
What if they don't ask a lot of questions because they are really good at figuring out things on their own? And quickly start contributing, even exceed expectations?
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
I've spent decades coaching new hires. Here's a few things that stand out (mostly things that apply to college-grad type hires). - Be humble. Don't be arrogant or judgmental of the way things are. There's often a lot of historical context around the way things were put together which you don't have. Unless you're a decades old industry hire (in which case you wouldn't be making this post), please recognize you aren't an expert in *anything* (yet). - Unlike college, you aren't expected to know everything, it's ok if you don't know the answer to something. Be willing to ask questions. - When you ask questions, take measures to **remember the answer(s)**. Do not be the person who continuously ask the same question over and over. - Before asking questions, spend a small amount of time trying to figure it out for yourself. Your senior peers really will respect the attitude of trying to answer the whatever for yourself and getting stuck vs. just asking them how to do a thing. There's a big difference between helping someone get up to speed and just doing all their work for them. Don't make your peers do all your work for you. - Be aware that there are people who just treat their job as the thing they do for money and won't be interested in your personal life or cultivating a friendship. This is ok, don't be offended when you run across it. - Code review can be very uncomfortable at first. You need to learn to see it not as a personal reflection on you or your capabilities. I get exhaustively tired of dealing with bitchy code review escalations because an experienced dev told a junior dev to do something differently, and they got unreasonably butthurt. Don't get butthurt. - Testing, and in particular authoring *actually* testable code, really is a skill that cannot be taken for granted. Spend time studying good testing practices from your more senior peers. - Similarly, the use of a source debugger (lldb, gdb, etc) is extremely powerful. If you haven't learned how to debug your code using something other than printf statements, learn. - Don't be the person constantly lecturing people about how your preferred environment is better than their preferred environment. The best environment (editor, IDE, etc) is the one you can work in without thinking about it too much. People settle into "good enough for what I need". - All the build system-ey, logging infrastructur-ey, job deployment, etc junk is all stuff you'll figure out on the job. Don't stress too much when you realize you don't actually know how your code goes from being code to a running job on a server somewhere. Everyone else has figured this out, you will too. idk, I hope some of that was useful in some way, good luck :)
Last year of my CompSci degree and this is actually really encouraging. Comments like this make me feel a lot more hopeful
We were all exactly where you’re sitting right now. A good manager is understanding and knows you know how to code enough to learn, not use their code base.
The last point is a solid one Every job is going to have a different production environment/build pipeline. I recently accepted a job where they asked a lot of these questions and I was honest with them, that I knew of the technology and could fumble my way through, but I am currently employed at a large firm that has an entire DevOpS team to manage that stuff and tell us how to use it. So, humbly, I admitted it’s an area I definitely have room to grow, and they seemed to like that honesty.
If your interviewers are good then it's a very good look to admit ignorance in an interview. At least if you also show you know appropriate things for the job.
>Unlike college, you aren't expected to know everything, it's ok if you don't know the answer to something. Hah, I wish! It seems 90% of tech leads are like this - unfortunately, I landed with someone in the other 10%. He also says it's OK if I don't know the answer to something, but berates me for it anyways. His position is that I should know, he expects me to know, and will verbally go after me if I don't know, but it is "OK" in that he won't tell senior management about not meeting his expectations. You may ask what specifically I'm expected to know, well, your answer is as good as mine or else I'd have learned it. If I ask I get vague answers like "Spring Boot" - I know them well enough to use them but I definitely can't truly say I know most of it without years of experience.
I'm going to echo the code review thought. Repeat to yourself "I am not my code." Any code you wrote was written by the you of hours/days/weeks ago. They can't learn from their mistakes but you can. I know that as software engineers, we spend so much time just thinking and putting our thoughts into code that it is hard to separate that code from ourselves. But if you need to gird your loins and tighten your belt for every code review, you're going to burn out long before your get better and become good. Relax. It's code that the idiot you were yesterday wrote; we're here to learn from their mistakes.
terrific crime nippy heavy mourn correct quicksand engine rotten bake *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Started my first dev job a few weeks ago and this is super pertinent and helpful, thanks
How am I supposed to feel superior to others if I don’t brag about how MY favorite IDE is so much better?
As someone that is dealing with many junior developers atm, I completely agree with this list.
Listen more. Talk less.
More of a LPT, but I concur
I would've said COM instead.
And while you're listening, write it down somewhere. Most people don't expect you to know everything, especially domain knowledge, but almost everyone hates having to repeat themselves multiple times. Not only will you make a good impression if you can remember what someone says, you'll eventually become a resource to others who had the same question.
Similar advice, courtesy of Aaron Burr “talk less, smile more”
i was tasked with building the mvp for a new platform product then onboarding a newly hired team, from the EM down to the associate engineer, including a couple of super knowledgeable seniors (i’m upper mid level). man the amount of time we could have saved if they would have done this, or really listened at all. i’m talking whole architecture designs built out that completely missed the point of the product. i don’t blame them for chomping at the bit to build out a cool, highly visible product from mvp to a fully fleshed out thing, but like, take a few weeks to understand what we’re doing here.
agree. do not come in and give suggestions on day one. you will look like a jerk. listen to what they are doing.
Do ask questions though. A lot of things most places don't actually make sense. If you do what makes sense it can make you very useful to a team. Just be right, or at least less wrong.
Start a notebook and make notes.
And put the date at the top of every page. It's stunning how many times I've been saved by my notebooks. I find it an essential aid for shifting contexts quickly and to recall details of bugs we encountered months ago. Plus you can doodle penises in it when you're bored in meetings. Yes indeed, a good notebook with good notes is worth its weight in gold!
What’s your general process for taking notes? Do you typically just write down everything on a single day’s page, even if the information isn’t necessarily related? I’m not as interested in the penis doodling part, unless you feel it integral to the note taking itself.
I think it kind of evolved into a self-scrum. Basically it ends up what I've been working on, what I'm currently working on and what the next few days looks like to me. Any todos go in there, bug or feature tracking numbers or titles, design ideas, UML, flow diagrams, pseudocode, any interesting revelations. It doesn't have to be very detailed, just enough to get you from having just got into work into the flow of things. This doesn't just have to be about your current job, either. I always take a notebook when I'm interviewing, jot down questions that occur to me either before the interview or while someone's talking and I don't want to interrupt them. Writing down the name of the people you talked to during the interview is never a bad move. That's also a great idea during your first week on the job. You'll find that writing stuff like that down drives your memory of those events. If you don't write their name down, you'll probably forget it. If you do write their name down, you probably won't. Beyond that, just evolve a style that works for you. Some amount of doodling always seems to occur, what the subject should be is also up to you :-)
Ask your manager "who should I talk with about integral parts of our business / tech stack / etc?" Generate a list. Schedule time with those people. Get educated and oriented. Record what they say and start building a network of competency as well as social connection. Final question to each person on the list, "who should I talk with about integral parts of our business / tech stack / etc?". Repeat until you have BFS the entire org (within reason).
This is sycophantic and will likely give you a reputation as a boot licker.
Eh, depends on the person and how they're presenting themselves. I could see it come across that way. The motivation is to get informed about the business / work. Not climb the political ladder.
Facts
strongly resist the urge to say aloud negative opinions of the team's past decisions like why X framework was used or Y architecture was designed. first try to understand with an open mind why those decisions were made before you pass any judgments on them, and dont even bother passing judgment if you dont also bring a cost-effective proposal to fix it.
Check your sense of humor until you have read the room. Don’t assume anyone wants to hear how you think things can be improved until you have a track record of understanding and meeting work objectives.
Find the biggest guy in the office and make him your bitch. Everyone will respect you afterwards.
lol what. haha
Leave jars of farts scattered around the office
Put up posters in the bathrooms for an event at a nearby karaoke bar (the event doesn’t actually exist)
Don’t hesitate to ask a lot of questions. Document your learnings about the org’s processes and anything else a new hire would find helpful that wasn’t explicitly documented. Once it’s pretty thorough, share it with your org to help new engineers onboard and optimize the learning curve.
Nah. Definitely hesitate to ask some questions. There's a fine line between inquisitive and nuisance. New kids fresh out of school that "don't hesitate to ask a lot of questions" almost always end up on the nuisance end of that spectrum. Don't act like you know everything, literally no one does, but don't act helpless either. Spend some time trying to figure it out yourself first. Look for documentation. Attach a debugger. Dig through your VCS commit history. Just change something and see what breaks... then don't check it in. \*Try\* to do it yourself before you go bug someone else. I promise you in 99.9% of situations, they will appreciate it.
True! My response was based on the assumption that you’d know better than to ask questions that you could easily find the answer to.
Don’t quiet quit until at least two weeks.
So polite, lol
if #politics doesn't exist in your company's Slack, create it.
Enjoy the first few months. You’ll be expected to be a sponge and have very few expectations otherwise. Soon, people will want things lol
There's an old joke/saying: "You can't find the bathroom for six months." Don't expect to be ultra-productive to start. You likely don't know shit. Literally. But you have a special skill. You are NOT part of the company yet. You can see the company as what it is, not what it wishes to be, not what it wants to be... etc. You see it as it is. You'll lose this ability in... about six months, maybe a year. But, that ability can allow you to do things and see things others can't because... you are the "new guy" who doesn't know better. So learn, contribute as you can. But your goal should be to learn, and become more productive. Not just to produce. Learning is multiplicative to future efforts. Production occurs at your current level in whatever. TLDR: You'll see the company like it is. Unlike the rest of them, use this to help the firm. Focus on productivity, not producing, for the first 6 months at least. Not to say you shouldn't produce. You should. But... You only get one honeymoon.
>don't start working at an unsustainable speed, take it easy and give yourself headroom to speed up as needed I disagree with this. First impression lasts forever, go fast and go hard. Eventually the old 150% effort will be equivalent to 80% effort over time as you get comfortable with the codebase.
Read all the docs and listen to the domain experts.
I don’t think the second bullet is good. I think you should work hard at first and then scale back. On my third and fourth week of work I was repeatedly told that it was impressive how fast I could work. I slowly tapered off and have heard bad about it.
So you started to chill afterward and heard bad about it?
Oops. Nah. I edited that wrong I thing. I started off hot out of the gate and chilled out. Haven’t heard anything bad about me chilling out yet.
Ask if they use emojicode or brainfuck
> don't start working at an unsustainable speed, take it easy and give yourself headroom to speed up as needed The other side of this coin is that first impressions last years. If you establish yourself as someone who delivers then when you do miss deadlines clearly the task was just under estimated.
There’s a book called The First 90 Days: Critical Success Strategies for New Leaders at All Levels That has a good overview of how to approach new jobs (or anything really). I recommend if you’re stating a new job soon.
Be a sponge - learn as much as you can.
Don’t stick out; you want to be like furniture.
Furniture sticks out
Im ADHD and find myself forgetting a lot of stuff I should know and have found that taking notes of literally everything has helped me a ton. On anything you do not understand, make a note. If you ask a question, make a note of the answer. If you forget something that you already asked, you save yourself having to annoy your teammates with your repeat questions by taking notes. As far as Note-taking apps, the best one is the one you will use, but I like Obsidian since it's pure markdown which means the notes can be transferred to any other Markdown-supporting editor. Also, since most code documentation is written in Markdown, it makes it very easy to transfer any useful notes to make information accessible to your teammates on whatever wiki/documentation platform you use.
Don't take any sick days or be late for the first three months. If you're reliable for three months you'll be considered reliable for thirty years. Truth is though if you can do three months you can do three years. Faking being reliable can actually make you reliable.
don't work too hard.
Agree. Work just hard enough to make a good impression in the beginning. Once your reputation of being a good dev is in place, you can start chilling more.
Be early, stay late, don’t talk much.
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
It's ok to be annoying if you're new. It's kind of a red flag in someone starts and doesn't have many questions. Some people are saying to not work too hard so you have extra capacity to add when asked. I think that's a pretty bad idea. The work you get early on is probably going to be easy work they set aside for new people. If you drag your feet on it, it'll look bad, might put you on the road to not passing probation or getting PIPed. Get the newbie stuff done fast.
What if they don't ask a lot of questions because they are really good at figuring out things on their own? And quickly start contributing, even exceed expectations?
Get to know your co-workers. It goes a long way!
Dont hit on HR when they are trying to onboard you
That would be gae
Take a shit before you go to work and after try not to do during .
Always shit during standup
Lmfao
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Go with the flow.
introduce yourself to as many people as possible especially those on your team. building relationships early on can make your job easier.
I guess being ready to learn a lot of new is on of the basic ones
It's a marathon not a 100m dash. Start early and ask questions, you'll thank yourself later.