3 answers
4
Questions
Asked
670 views
What are some hard-ships you encountered out the gate of job corps in computer tech?
I need some expectations on what challenges I might face after Job Corps.
Login to comment
3 answers
Updated
Brett’s Answer
I can't speak to Job Corps specifically, but here are the issues I've encountered in new tech jobs (even after I had lots of experience!) and that I see students and juniors mention:
- Getting that First Job: It's a classic problem, getting experience without a job and a job without experience, but in tech it's worse. There is a real bias towards hiring senior people (and experienced junior people) that will show in other points in this answer. Interviewing is a very random process - I and many of my friends have failed interviews at some companies only to nail interviews at jobs that are easily argued as "better". This randomness is worse for devs who don't have much interview experience and are trying to figure out how to "do better". There are things you can do, but also often things you can't control and shouldn't try to, so effort + persistence is the key. It gets better quickly as you get more experience on your resume, but the first job is by far the worst.
- Unclear Expectations: Most jobs will be pretty clear about the main thing they want you to do: "Here's a codebase, add/change/fix this feature". However, DOING that will include a ton of related steps. Examples: learning the codebase, reporting progress, finding subject matter experts to get answers from, following local coding standards and conventions, testing the code, involving Design/Security/QA/DB Admins/etc as needed, getting through code review, and merging to the right place. It's overwhelming. The trick is that they don't actually EXPECT you to know all this - no one could - they just haven't taken any steps to provide you the answers in advance (or their provided info is out of date - it's a good sign if they have such details documented, even though they do tend to be perpetually up to date). My advice: Take explicit notes. Anytime you aren't sure about something, write down a specific question. If you are anything like me, if you say you're confused someone will offer to help and ask what is confusing and your mind will be unable to recall anything specific, at all. A written list helps a lot - not only do you get answers, but you demonstrate what they need to answer for new hires. More than one job has asked me to write up my questions and answers to help "onboard" future devs. Staying quiet and trying to muddle through without asking for help is probably the worst thing you could do, unless you are explicitly told to figure it out for yourself (which speaks poorly of the employer)
- Lack of Mentoring/Mentoring Skill: Most places will not actually provide any explicit support for you to grow and improve as a developer. When they do, those resources often have no particularly training or experience in being a good mentor, and the advice that worked for them may not work for you. If you good resources, that's fantastic, make use of them. But most likely you will be on your own, hoping to improve passively through experience. My advice here is two fold: (1) Pace yourself. Striving to improve is good, but a lot of it is making the most of what you are doing, so don't burn yourself out. Being a new dev is a ton of learning, don't discount all that effort and pay attention to learn the most from those experiences! (2) With point 1 in mind, do set yourself explicit goals and try to get specific feedback. When you get answers to questions, ask "Why?" to get some lessons. When you find code in a code review you don't understand, ask if you can get a breakdown as to why it was done one way versus another. (Make sure you come across as asking, not saying the alternative is better - coders can be defensive!) When talking with mentor/manager, get specific feed back: Not "You've done well", but "You did X well, and I'd expect you to improve in Y in the next few months". Being a Senior+ Dev involves not only saying "it depends" a lot, it means knowing what it depends ON - a junior dev looking to improve should be finding those conditions.
- Imposter Syndrome: All professions have this problem, but tech is particularly prone to it. In my anecdotal experience, about 80% of devs have severe feelings of feeling like they are a fraud that will be caught someday (different devs have these feelings at different frequencies, and ~20% are blissfully gifted with more reasonable levels of self-doubt). This is an industry where there is too much to know it all, and more is being added faster than you can learn. Knowledge one dev considers trivial and basic may be completely new to another senior+ dev. Despite (or perhaps because of ) this, many devs are unwilling to display ignorance for fear they will be "found out", and the problem only gets worse as you get more senior. I saw one tweet from a Principal dev at Google saying their answer to "what are you going to do now that you're a Principal?" was something like "start revealing my ignorance so I can learn more". As a new dev, it is easy to feel both ignorant and at-risk, but as a new dev there is the greatest expectation that there is a ton you don't know: get comfortable with being open to learning and not knowing, and you'll help generate a healthier environment for yourself and others. Trust me, as the decades pass you really want to be comfortable with admitting you don't know something because the self-imposed expectations only get bigger.
- Cultural Separation: The world is a diverse place with peoples of different shapes, colors, cultures, habits, and backgrounds. Your new workplace most likely isn't. It doesn't even have to be a well-understood cultural difference: When I entered my first job in Seattle I was surrounded by people visually similar, yet to me I was a geeky socially awkward vegetarian RPG nerd who almost never drank surrounded by athletic gym bros that would argue over how to best make a steak during their bar crawls. Each workplace will have a different culture, and the odds are high that you and they will all have to make adjustments (and sometimes they are unwilling). Heck, some differences seem small yet end up being important - I know people who mean different things when they nod, so one person is explaining and seeing the other party understand, while the other party is simply indicating attention and not yet understanding. That's the kind of difference that causes confusion and strife without any malice and the only mistake being unfamiliarity. Confidence counts for a lot socially, so confident sounding people will have short term success but may or may not be doing the right things long term, while their confidence will lead them to not seek out other opinions. Working through these issues is a constant process for everyone. This is true everywhere, but arguably tech has a higher percentage of people who prefer technical problems to social ones. New Devs have the unique pleasure of being introduced to these feelings and problems right at the time they have the least confidence and least experience. I don't have good advice here other than to find support - a solo dev is a lonely person to be, and the habits you form now are all the more difficult to change later. Never be ashamed of being yourself, but always strive to be more inclusive, more cooperative, and more welcoming.
Hope this helps, good luck!
- Getting that First Job: It's a classic problem, getting experience without a job and a job without experience, but in tech it's worse. There is a real bias towards hiring senior people (and experienced junior people) that will show in other points in this answer. Interviewing is a very random process - I and many of my friends have failed interviews at some companies only to nail interviews at jobs that are easily argued as "better". This randomness is worse for devs who don't have much interview experience and are trying to figure out how to "do better". There are things you can do, but also often things you can't control and shouldn't try to, so effort + persistence is the key. It gets better quickly as you get more experience on your resume, but the first job is by far the worst.
- Unclear Expectations: Most jobs will be pretty clear about the main thing they want you to do: "Here's a codebase, add/change/fix this feature". However, DOING that will include a ton of related steps. Examples: learning the codebase, reporting progress, finding subject matter experts to get answers from, following local coding standards and conventions, testing the code, involving Design/Security/QA/DB Admins/etc as needed, getting through code review, and merging to the right place. It's overwhelming. The trick is that they don't actually EXPECT you to know all this - no one could - they just haven't taken any steps to provide you the answers in advance (or their provided info is out of date - it's a good sign if they have such details documented, even though they do tend to be perpetually up to date). My advice: Take explicit notes. Anytime you aren't sure about something, write down a specific question. If you are anything like me, if you say you're confused someone will offer to help and ask what is confusing and your mind will be unable to recall anything specific, at all. A written list helps a lot - not only do you get answers, but you demonstrate what they need to answer for new hires. More than one job has asked me to write up my questions and answers to help "onboard" future devs. Staying quiet and trying to muddle through without asking for help is probably the worst thing you could do, unless you are explicitly told to figure it out for yourself (which speaks poorly of the employer)
- Lack of Mentoring/Mentoring Skill: Most places will not actually provide any explicit support for you to grow and improve as a developer. When they do, those resources often have no particularly training or experience in being a good mentor, and the advice that worked for them may not work for you. If you good resources, that's fantastic, make use of them. But most likely you will be on your own, hoping to improve passively through experience. My advice here is two fold: (1) Pace yourself. Striving to improve is good, but a lot of it is making the most of what you are doing, so don't burn yourself out. Being a new dev is a ton of learning, don't discount all that effort and pay attention to learn the most from those experiences! (2) With point 1 in mind, do set yourself explicit goals and try to get specific feedback. When you get answers to questions, ask "Why?" to get some lessons. When you find code in a code review you don't understand, ask if you can get a breakdown as to why it was done one way versus another. (Make sure you come across as asking, not saying the alternative is better - coders can be defensive!) When talking with mentor/manager, get specific feed back: Not "You've done well", but "You did X well, and I'd expect you to improve in Y in the next few months". Being a Senior+ Dev involves not only saying "it depends" a lot, it means knowing what it depends ON - a junior dev looking to improve should be finding those conditions.
- Imposter Syndrome: All professions have this problem, but tech is particularly prone to it. In my anecdotal experience, about 80% of devs have severe feelings of feeling like they are a fraud that will be caught someday (different devs have these feelings at different frequencies, and ~20% are blissfully gifted with more reasonable levels of self-doubt). This is an industry where there is too much to know it all, and more is being added faster than you can learn. Knowledge one dev considers trivial and basic may be completely new to another senior+ dev. Despite (or perhaps because of ) this, many devs are unwilling to display ignorance for fear they will be "found out", and the problem only gets worse as you get more senior. I saw one tweet from a Principal dev at Google saying their answer to "what are you going to do now that you're a Principal?" was something like "start revealing my ignorance so I can learn more". As a new dev, it is easy to feel both ignorant and at-risk, but as a new dev there is the greatest expectation that there is a ton you don't know: get comfortable with being open to learning and not knowing, and you'll help generate a healthier environment for yourself and others. Trust me, as the decades pass you really want to be comfortable with admitting you don't know something because the self-imposed expectations only get bigger.
- Cultural Separation: The world is a diverse place with peoples of different shapes, colors, cultures, habits, and backgrounds. Your new workplace most likely isn't. It doesn't even have to be a well-understood cultural difference: When I entered my first job in Seattle I was surrounded by people visually similar, yet to me I was a geeky socially awkward vegetarian RPG nerd who almost never drank surrounded by athletic gym bros that would argue over how to best make a steak during their bar crawls. Each workplace will have a different culture, and the odds are high that you and they will all have to make adjustments (and sometimes they are unwilling). Heck, some differences seem small yet end up being important - I know people who mean different things when they nod, so one person is explaining and seeing the other party understand, while the other party is simply indicating attention and not yet understanding. That's the kind of difference that causes confusion and strife without any malice and the only mistake being unfamiliarity. Confidence counts for a lot socially, so confident sounding people will have short term success but may or may not be doing the right things long term, while their confidence will lead them to not seek out other opinions. Working through these issues is a constant process for everyone. This is true everywhere, but arguably tech has a higher percentage of people who prefer technical problems to social ones. New Devs have the unique pleasure of being introduced to these feelings and problems right at the time they have the least confidence and least experience. I don't have good advice here other than to find support - a solo dev is a lonely person to be, and the habits you form now are all the more difficult to change later. Never be ashamed of being yourself, but always strive to be more inclusive, more cooperative, and more welcoming.
Hope this helps, good luck!
Thank you Brett, this was very informative to read and gave me a good idea of what to expect when I join the work force. I really took note of asking questions because honestly I would feel a bit ashamed asking questions once I have attained the job but I guess if its for my growth and the employers want me to grow questioning is the clear path to this goal.
Jacob
Updated
Srinivas’s Answer
Job and nature of jobs changes Pretty fast. Be ready to continuously adapt yourself to changing on a daily basis. Try to gain expertise by self learning and smart learning.
Updated
Heather’s Answer
I think the biggest challenge going into working full-time in the tech industry has been imposter syndrome! I work specifically as a software engineer, and there are so many technologies that you could learn related to software engineering. There are numerous programming languages, programming techniques, algorithms, data structures, and general technologies that you could learn. In your future, it's likely that you'll encounter someone who knows a lot of these components of software engineering, but you don't. That's totally ok! Everyone starts somewhere, and you can't compare what you know to what someone else knows. That is to say, don't compare yourself to others, only compare your current self to your past self. I really struggled with understanding this when I first got into the industry, but understanding that it's ok to be wherever you're at really changed my outlook.
Good luck moving forward!
Good luck moving forward!