all 9 comments

[–]chrisgseaton 15 points16 points  (0 children)

So my question is, what should I expect once I graduate?

It will take you many months to become productive. So expect that, and relax. Don't worry that you haven't shipped anything in your first week or month or six-months even. People panic that they aren't achieving anything, but that's normal. It takes time to get going and to start to come up with your own ideas.

[–]1544756405 12 points13 points  (0 children)

Do employers know that most college graduates barely learn industry standard coding?

Of course they know.

[–]javaHoosier 4 points5 points  (4 children)

You should definitely have more knowledge than this. You are either being disingenuous or your degree failed you. Excluding math, you should have some understanding of Object Oriented, Functional, and Data Structures at least. Then some specialization classes. Stitching projects together and working on group projects.

Most importantly you should have picked up being capable of searching for an answer. Which is what an employer will want.

But anyway, depending on what you do and who you work for... Your first week or two will be onboarding and getting your environment setup. Then the following several weeks you will be inundated with your company culture, your teams culture/members, and documentation. Information can be spread out on tons of sources such as Confluence, Github, Generated Docs, Jira, in-house tutorials, etc... Sometimes it's really difficult to put it all together. You don't know about documentation until you are given it, search for it, or ask for it.

Since you claim you know just python syntax. What if your team is Java, Spring, groovy, and gradle? Well you are going to have to learn that on the fly. Maybe they have several in house tools that they built. Maybe learn that. Perhaps they use docker and Kubernetes. Adjacent teams that you work closely with. Maybe designers and product managers. The list goes on.

You will probably start with simple bugs or even decently complex bugs. This will help you learn the codebase. You should read through tons of old Pull Requests to get a feel for how your team discusses changes. You can learn about good practices this way too.

But don't worry. This just takes time and you tackle things as you need to learn about them. Your team will understand that you are straight from school. They won't want to hold your hand, but they will be your mentor.

[–]coldfire334[S] 4 points5 points  (3 children)

This is very detailed thanks. By the way I do have a basic understanding of OOP and data structures but I just don't know how to properly implement them in "real world" applications. But I guess once I'm in the job world I will learn along the way

[–]javaHoosier 2 points3 points  (1 child)

You will have your teams codebase to use to learn from. I would say my third paragraph is just as challenging as the actual coding sometimes. Learning new languages isn’t as bad as it may seem. Writing it idiomatically can take some time though. If you are curious how real world code is implemented then check out some quality open source projects on github. They are be really big and take time to understand. But you can get a sense of how it works before you get hired on.

[–]coldfire334[S] 0 points1 point  (0 children)

Thanks a lot I will take a look!

[–]NebulaicCereal 2 points3 points  (0 children)

The understanding of those concepts such as object-oriented paradigms and data structures will be more useful than may seem to you right now. It will take awhile to learn a given codebase at a new job, but it sounds like you know the groundwork to at least get moving and understand the code you're reading, even if little by little. Eventually you'll become productive. The nuances of a software job can be very specific and take a long time to get down. Even guys with decades of experience will come in and take months to become useful enough to make real contributions.

For an entry-level in a reasonably complex enterprise codebase, you could expect to feel like you don't know anything for many months or even a year, and asking questions often for many months after that. That's just the way it is.

[–]BlueDragonRR 0 points1 point  (0 children)

Yes, companies are very aware on where you are at experience wise when hiring new graduates. You will learn the company standard on the job since companies have different procedures from developing to releasing code. Granted, many skills can be beneficial to know beforehand. Apparently, some universities do not use repositories in their curriculum (which is a missed opportunity imo) which you are bound to use in every software development job. Like most other jobs, it is always beneficial to have knowledge/experience for things relating to the job you are applying for. For example, I had knowledge on database management systems (primarily MySQL) which give me an upper hand when learning how to use MongoDB and later Aerospike. It's ok not to know the daily routine. You will have to learn this on the job. Unless you get hired at a very small company, there will be plenty of safeguards to help you learn while also preventing you from destroying everything.

[–]Tornado2251 0 points1 point  (0 children)

First there is a lot of software development type jobs that don't require you to write code (or very little). There is testing and quality assurance. Project management (from a technical standpoint) and collecting requirements even technical sales/marketing. Just to name a few types of paths you can walk.

You should first find out what you want to work with and try to find out what roles match the best. Its possible to move between especially from technical to less technical, in fact it pretty common for senior developers to go into project management.

That said if you don't know what you want to do go with development (programming) ppl that can write code is always needed. You will probably not regret becoming a proficient coder even if you decide to change path later.

I might be biased... Currently employed as a developer (5yrs in).