2020 Week 44 review (25-30 Oct)Sat Oct 31 2020
I'm reinstating the weekly review habit. See the previous blog posts for an explanation of the six different categories.
The six categories are:
- Side projects
As with last week, I'll rate each of the six categories on a four-point scale:
- Excellent (exceeding expectations: better than I could've asked for),
- Good (meets expectations: about as good as I could've asked for),
- So-so (some good, some bad --- OK overall, but room for improvement),
- Bad (didn't meet my expectations --- could have done better).
Review of the week
Got the offer from OGP! This represents a culmination of not just 50-60 hours of effort (in the short term), but also three or four years of competence built up by my self-study and doing software project after software project. I am very, extremely pleased that all my hard work has paid off and I have been vindicated: despite the fact that I studied PPE, my self-study and projects have been enough to land me a job at a well-regarded workplace, as a proper software engineer.
How much time did I spend preparing for the interview? And how many LeetCode questions did I do?
I looked through my spreadsheet and I logged 35 hours doing the problems alone. This is an underestimate, as I did not start logging the time taken for each problem until I was several problems in. I also spent additional time looking through the solutions and going through mock interviews (where I was the interviewer) which is again time that isn't logged. I would estimate a total of 40 hours for prepping for the technical part. I solved a total of 60 questions, the vast majority of which were Easy and Medium with only a handful of Hards. The questions that Chin Ying and Nikhil gave me were novel, but the LC practice made me quicker and more comfortable writing code in Python.
I also prepared for the interview by writing very copious notes on each project that I did. I also prepared self-introduction and answers to behavioural questions like why I wanted to join OGP and so on.
Inspired by what Hongyi said, I resolved to be a bit more proactive with IMDA. I told Eric that I thought the DeepStream SDK + RealSense setup was not ready for prime time, and that we would probably be better off writing the pipeline in Python. I think this is a true statement. While someone could probably make it work by puzzling through the documentation and installing the Aiereo third party libraries, our very niche use (DeepStream + RealSense + Jetson) means that nothing is going to work properly. Also if we think about it---what exactly is the DeepStream SDK giving us? Why do we need it? Eric said he trusted my judgement but to do more research on DeepStream first, and I told him I'd give him a report plus a document proposing the new Python pipeline.
I'm pleased with this because using Python means that I'll be able to get a pipeline up and running much quicker, and demonstrate---as Hongyi put it--- "extreme competence".
Overall, I'm very pleased with what I have achieved this week (but really it's more accurate to say what I have achieved over the years)
Last week I said "try not to get sick" but I got sick on Saturday. This came as an unwelcome surprise as I didn't sleep (that) late on any day and in fact I woke up earlier than the alarm on certain days.
Bad: both of my partners bailed on me and I had no motivation to continue
I should find a way to work on the project even if my partners bail. But at the same time I need to keep them in the loop. Think more about this when I have more bandwidth.
- Managed to meet six offenders and treat them to dinner.
- Met Jarel and Eliza
- Met CKY and Kuan and we had an interesting discussion about what CKY is doing, and what I should do in order to become a better software engineer. CKY told me about his plans: ship TWoAS, then try and get a job at Ubisoft.
Started to learn some new chords and new songs after my fingers got calloused. I learned the chords for "Jar of Hearts" and “浪子回头” and it was not too bad. I still need to learn how to strum properly but---as I've said before--- it really really helps to have the guitar right out there, makes practice frictionless and hence I practice more.
Very serendipitous---after meeting Jarel, Jarel followed me back (with Eliza) to look at the garden plots. Then Eliza asked us to accompany her to Pasir Ris(???) to buy some new plants for her bathroom or something??? And like, very serendipitously, I agreed, and Jarel as well. So her mom picked us up and sent us there. It was actually a lovely place, despite it being a 鸟不生蛋的地方; lots of plants and very cute frogs.
Overall rating for this week
- Career: excellent
- Physical: so-so
- Side projects: bad
- Relationships: good
- Skills: good
Questions I have
How do I become the best software engineer that I can be?
I will be a "proper" card-carrying software engineer soon. I want to focus on being the best software engineer that I can be. What should I learn in order to be the best? One good thing to do is to read and re-read OGP's career schema:
Software Engineers are competent individual contributors. They are comfortable with engineering tools such as source control, error monitoring, automated testing, and more. They can successfully run systems in production, though they may be unable to design such systems themselves. They can reason about the practical implications of a system design and can make useful contributions to design discussions. Overall, they are able to prioritize engineering tasks for themselves and complete them independently.
Concretely this means Software Engineers are able to:
- Write code that matches the readability and design standards of the team
- Implement systems from a given architectural design
- Understand the design goals and limits of a given system and work around them
- Prioritize engineering tasks effectively and avoid getting stuck on low impact work
- Use engineering tools effectively
- Collaborate with other engineers by writing well defined pull requests
- Participate productively in a code review both as a reviewee and reviewer
- Branching and merging appropriately in source control
- Configure build tools for simplified deployment and development
- Setup automated testing to prevent code regressions
- Operate production systems reliably
- Setup and operate cloud infrastructure for a given architectural design
- Implement logging and be comfortable searching through logs
- Configure basic alert systems to minimize downtime
- Deploy code to production using practices that minimize risk of user interruption
- Respond to production outages and recover from simple errors
- Conduct post mortems detailing the significant events and root cause analysis
It looks like the pull request and code review part can be learned through OSS work (or on the job), but how do I learn the learn automated testing and build tools? And how do I learn everything under the section "Operate production systems reliably"?
For completeness (although I won't reach here anytime soon):
Senior Software Engineers are fully proficient individual contributors who are able to provide technical leadership to their teams. They have implemented a variety of systems and understand the tradeoffs between different databases, frontend frameworks, and other system design choices. They can independently identify the important characteristics of the system, devise the necessary protocols and infrastructure, and choose the appropriate technologies and services. They are able to set up a skeletal framework for the project so that other engineers can easily build upon it. Overall, when given a project they are able to devise the architecture, break it down into engineering tasks, and make rapid progress on those tasks.
Concretely this means Senior Software Engineers are able to:
- Establish the coding conventions for a project
- Identify important system characteristics such as idempotency, data durability, or privacy given a general project description
- Devise engineering solutions to bureaucratic requirements and constraints
- Design the data model for the system to both be elegant but sufficiently extensible
- Design the infrastructure to be fast, resilient, secure, and efficient
- Design the system protocols to provide the desired semantics
- Design the code modularization to be easy to understand and maintainable
- Communicate these designs clearly to the team to discuss and understand
- Prioritize tasks for junior team members and provide guidance to help complete them
- Represent the team in technical discussions with other teams
- Setup the core infrastructure, initial codebase, and build tools to allow teammates to start making contributions efficiently in a well defined framework
- Make prolific contributions to the codebase themselves
- Triage, diagnose, and recover from complex production outages
What should I be focusing on now?
So being good in my career is going to be my main goal when I successfully transfer. What about now in this limbo period? What do I do? I could take it as a break: just do whatever's fun.
What my goals are for next week
- Think and ask around for advice a lot about what I need to learn in order to become a better SWE
- Actually start doing proper work at IMDA
- Carry on meeting and video calling my friends