You have been selected amongst a large number of applicants for a software developer role. You have been waiting to join, and today is the big day!
After the onboarding formalities and meeting your team, you are raring to go!
But where should we start? By asking the right questions:
- What is the purpose of our product?
- Who are it's users?
- What motivated the company to build this?
- Where can I find some documentation?
Book 3 sessions with your teammates. In the first two sessions, let two different teammates explain what the system does. Present your understanding of the system in the third one.
-
Integrate (but do not dissolve) yourself
- What database do they use?
- What is the request routing mechanism?
- Do they have their own communication protocol?
Note down the team's programming language, dependency tools, build tools, work hours, test framework, deployment manuals and rituals. Try to read up on any open source tech being used.
-
Adjust more and suggest less
- Don't jump to conclusions on design decisions or code quality.
- Don't suggest improvements right off the bat.
- Pose your thoughts as questions instead of accusations.
- Don't try to prove your utility by hunting for improvements in the system.
People are usually defensive about their work. It's best to take a slow and measured approach when putting forth your ideas.
-
Expect piecemeal tasks to begin with
- Your first task might be something very simple, almost mundane. Example: Logging a metric and sending a message to an analytics engine.
- The team wants you to get familiar with the software engineering process. They want to see your time estimation, testing and communication skills.
There is no harm in starting off at the bottom of the ladder and slowly making your way to the top.
- Write tests
- Your reputation depends on your code correctness. Code quality is a close second.
- The code reviews are smoother. Production issues are simpler.
The reputation of a software engineer is inversely proportional to the number and severity of the production bugs in their code.
- Speak in your team's language
- Who merges the pull request?
- Can anyone push a hotfix to the main branch without review?
- What is the testing criteria?
- How many reviewers are needed for a small/big change?
- Can anyone change a property file without review?
Make your team comfortable by following their protocols.
- Keep your team updated
- Use standups, meetings or the office messenger when making critical changes.
- More eyeballs and more documentation make the final product reliable.
Communication builds trust in your team.
- Don't be too harsh on yourself
You are probably doing great. It takes a month to get an idea of what's going on in your team, even for a senior engineer. Give yourself 3 months to get a hang of things.
Joke and laugh with your team at outings. Don't take comments on your work personally. The tougher you are, the fewer the jibes.
———————————————————————————————————
Stay confident, be curious and communicate clearly. The rest will sort itself out.
You can check out more software development tips on our YouTube Channel or our video course at InterviewReady.
All the best!