Just being hired as a senior developer, never even been a junior developer, what should I expect? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Software Engineering Stack Exchange.

Closed 6 years ago.

Improve this question

I've been a freelancer and a coder by night for a while, and recently, I've been hired after several levels of interviews in a nice NY company, even though I've some lacks in specific fields. Is this common for companies to hire seniors with less experience? Will they wait some weeks to respect a certain learning curve?

I don't know anything about working in a company, so that's why I worry. After one week, I'm still checking and exploring sources, but after one week of work, it seems that some coworkers are considering that I'm slow. I'm good in maths, physics, algorithms, but still I need to learn about all the templates used in this company.

Anyone here already received a less-experienced senior member in his team? Is this acceptable?

I'm planing on having a meeting with my boss to stop worrying about that. Sounds like a good idea?

[EDIT]

Thanks for these answers. I'm definitely a -new - senior developer. I returned to the office with more confidence on Monday. I guess that it's normal to feel a bit incompetent in front of unknown templates/sources during the first weeks when you receive a good pay.

Answer 1

There is no commonly accepted definition of "senior developer". Definitions may exist within organizations but a senior developer usually represents someone:

1. With software development experience (3-5 years minimum),
2. Can work without constant supervision (often with no supervision),
3. Familiar with the development environment and tools,
4. Capable of supervising or teaching junior developers,
5. Capable of designing and implementing small to medium sized projects.

It is hard to talk about your specific situation but there is usually is a learning curve when joining a new team.

No matter how standard the tools and processes they use, each team has a history of decisions that lead them to their current state. If the organization uses custom libraries or environments, my first question would be to ask about documentation and training. Big companies may have formal training for new employees, even senior ones. Read any existing designs, the build environment documentation, processes and so on. If these do not exist, offer to document them.

I would then ask to pair with an existing senior developer. This is usually the fastest way to learn what is expected and how things work. How did they solve that problem? How much effort did they spend on unit tests and reviews? Why did they do it this way and not that way? Ensure the other developer helps you setup your development environment and walks you through the release process, too.

Make it clear to them you know the language and tools, just not their techniques. For example, if you did things a different way previously and think it is better than their way, tentatively and respectfully suggest it.

Hopefully, pairing with them will not slow them down. They may even appreciate another set of eyes to catch typos and issues before they are committed to source control.

Lastly, realize you are not going to fully understand a large project within a week so start fixing small bugs or features. Make sure your buddy reviews them and you get any and all feedback. You will miss things. You will make mistakes. That's OK. Learn from them, do not repeat them and work hard. If you are good at what you do, you will get there.

Answer 2

After one week, I'm still checking and exploring sources, but after one week of work, it seems that some coworkers are considering that I'm slow.

One week is a short period of time. Even after one month, you will still be checking sources. You are not engaged by this company to know their code by heart. Your development tools or IDE are here to help you with this. If some problem occurs with some coworkers after one week, simply ask them how they work and which tools do they use. If they considers that you are slow after one week, this is totally abusive. The minimal time necessary to understand an existing application is about one month. Especially with corporate stuff, that is sometimes or most of the time not documented at all. You are a human, not a computer.

You should ask to your coworkers to stop showing you that you are slow or they are better than you, this is non-sense! For sure they are quicker than you, because they wrote the stuff... Somebody gives you the job, you have been hired for what you are able to do and what you've done before, so these guys should only welcome you, help you with a kickstarter explaination, daily stand-ups and weekly debriefs. If they continue with this behavior, this is seriously worrying and you should consider to solve this problem with a manager or go away.

I'm good in maths, physics, algorithms, but still I need to learn about all the templates used in this company.

This is pretty normal, and can take months. Try to work on very small bits of the app first and then you will learn and become able to have a global view off the code, processes (this is maybe as important than code), methodology (even if it's not formal), etc.

Answer 3

Even for people experienced in "working in companies", being on your toes is not necessarily a bad thing, it keeps you alert and focused. As long as you keep your confidence and don't get paralyzed.

It becomes easier. Working on a large code base, it's to be expected that you'll need time to familiarize yourself with its intricacies. I had more than a decade on the clock working for a number of companies before I switched to development (a little over a year ago) and I still have moments of self-doubt when dealing with complex problems or daunting amounts of code (our code base line count runs in the many millions), but I just soldier on, keep Google, StackOverflow and this here web site open, work my butt off and I'm not too proud to ask for help. You're part of a team, no longer the lone coder at your home desk. Benefit from your colleagues' experience and knowledge.

You got hired after several levels of interviews, that means they made an informed choice by hiring you. Be cool, you got the job. That means there's already a level of trust in your abilities and you've been coding for a while now. You'll do fine.