In review: 3 months probation

In review: 3 months probation

It has been 3 months since I started my first job, and I have to thank my manager for all the learning opportunities that are given to me, both technical and non-technical.

Achievements and progress

On the technical end, I got to build a basic authentication service, design the database schema, draw the flow chart of the API routes, learn to set up elasticsearch for our business search requirements, ingest data and run queries.

These backend development experiences are exactly what I wanted to do. On the frontend, I created a web and mobile UI to showcase the authentication workflow.

More recently, I have started working on implementing the actual mobile app that we are aiming for our first launch, starting with authentication and onboarding flow, followed by the search workflow.

On the non-technical side, I definitely learned just as much as the former. Interpersonal communication skills have been one of the areas of life that I want to improve on.

I am given a high degree of autonomy in scoping out my tasks that involve reading up on good software engineering practices, researching existing technologies and software design, putting up a proposal, and estimating time effort, together with the guidance and support given by my boss when needed and requested, and finally initiating to discuss with the team on resolving communication overhead.


Even though coding is the bread and butter of a software engineer, I believe it is not the most valuable skill one can bring to the company.

From my experience so far, writing code is not near the top of my list of the greatest challenges I encountered on the job, although learning how to write code for various components of the system for the first time is usually tough(sometimes overwhelming), and actually putting the effort to write code that produces no output from the product and business point of view(refactoring, writing tests and writing enough of them) can be a little frustrating.

At the top of my list is drumrolls interpersonal communication, which is not surprising at all. Given that I am not outstanding at communicating thoughts and ideas, I have anticipated various obstacles that I might encounter. Examples of mistakes I made in communicating with the tech team(my boss and a colleague):

  1. Assuming

Assume I understand exactly what my boss is expecting when we are discussing the scope of my tasks and deliverables(this is one of the most frustrating issues, but has smoothened out after 2 months). I am still seeking to achieve a balance between making reasonable assumptions about certain expectations and asking about every single thing.

  1. Inconsistencies. Colleagues and boss have inconsistent views on the same issue. This is where having qualities such as initiative, and resourcefulness help a lot. By clarifying these inconsistencies, we have saved hours or days worth of time that could have been wasted.

  2. Tech team collaboration. Collaboration between developer and infra team, particularly the ci/cd pipeline, to get our backend services and apps deployed and fully functional in staging environment. The challenges of this are muti fold, both technical and non-technical.

On the technical front, the developer(me), knows little about ci cd in terms of setting up the whole pipeline(excluding deployment), and my understanding of kubernetes is even lesser, though I have a workable knowledge of docker container.

On the other hand, the infra guy knows little about app development. So when both of us are working on the pipeline, no one really knows the approach to complete the entire flow.

  1. Product tech collaborating Not checking with the product manager regarding the status of the mockup before writing the code. As we are still finalizing the product requirements, official product-dev sprints have not started, but we have our tech sprints at the moment.

I was tasked to do the signup and onboarding flow for the mobile app according to the mockup. Halfway through the onboarding flow, I clarified a design decision in one of the screens, one where the next button is fixed to the end of the scrollable list instead of sticking to the bottom of the screen. It was at that moment I was told that the onboarding flow is undergoing a major design change(oh shit!).

I should have asked and double confirmed before implementing because there is almost no way of knowing the readiness of the screens just by looking at the mockup.

On the other hand, what I think would have helped the handover process is a document or a way to refer to the latest update of the mockup at that particular point in time, so that I do not have to keep asking for confirmation and that should save them some possible headaches and annoyance too.

Good things rolling

Overall, I would rate my experience in my company as generally positive. The next few months will be the critical phase of my career that determines the path I will take, amidst the ever-evolving business requirements of a startup environment.

Did you find this article valuable?

Support Yap Han Chiang by becoming a sponsor. Any amount is appreciated!