• Composer (proxy + client)
• Anatomy
• Webpage crawling
• Chrome api
• pico
• anki server protocol
• Semantic versioning
  • building a phar
  • php parsing
  • releasing php open source software
• laravel
• cordova
  • ionic framework
• nodejs
  • debugging
  • profiling

In this article I define a 1-5 rating scale for books in order to be consistent across my evaluations. Given that rating books is somewhat subjective, introducing some amount of standardization on how I rate them should help with managing my reading.

Format of presentation:

Score (from 1 to 5) Representative emoji

• Satisfaction
• Words expressing the level of satisfaction
• Strength of recommendation

1 🤮

• unsatisfactory
• very bad, horrible, boring, repetitive, disagreeable to read, waste of time, can't force myself to read
• strongly not recommended

2 ☹️

• unsatisfactory
• bad
• not recommended

3 😐

• satisfactory
• neutral
• might want to read

4 ☺️

• satisfactory
• good
• recommended

5 😍

• satisfactory
• very good, great, amazing, exciting, intriguing, fascinating, full of new knowledge, can't stop reading
• strongly recommended

References

• https://readingbookslikeaboss.com/review-rating-scale/
• https://www.writoscope.com/reading/how-rate-book-rating-system/

In this article I want to explore different aspects of scaling a company that need to be taken into account if you're trying to grow exponentially. Generally when discussing about growth we consider revenue growth to be the metric we're measuring. One thing that is important, and that is considered throughout the article, is to be a profitable company. There's no point in growing exponentially if it is unsustainable or your expenses are always going to be superior to your profits.

In the best scenario, your business grows exponentially without requiring any additional human power. The second best case is that it grows sublinearly, meaning that as demand grows, the amount of people required to support the company grows slower than the demand itself. Past this point, growth either matches with how many people need to be hired, or worse, growth is slower as you hire more people. Here you may have exponential human power growth to get linear (or sublinear) revenue growth.

When hiring people, you need to be able to onboard them while having as little impact as possible on the existing employees. If existing employees need to spend time onboarding new employees, then nobody is working on product development or support during that period. Here again, you want the number of people responsible to onboard and train new employees to be smaller than the number of people being onboarded. In other words, you want the ratio of onboarded to onboarders to be higher than 1 to 1.

When a company grows exponentially, every time the company effectively double due to new hires, the culture is now at risk of instability. If for instance 100% of the existing employees were following the existing culture, and 100% of the new hires have a different culture, then there will be a culture clash with no specific half of the company being in control of culture. Unless culture continues to be managed through the process of onboarding, the initial group of people and their culture will rapidly become diluted.

We're not made to interact with dozen or hundreds of peers. As such, it is close to impossible for an individual to work with more than let say 10 direct peers. This means that teams or groups need to be created. This also means that interaction between teams needs to be managed somehow. Having multiple people from a team interact with another team leads to the implicit creation of a larger 20 people team, which does not work very effectively. On the other hand, having single points of contact between teams is a surefire way to have single points of failure. In this specific instance it is definitely necessary to have at least 1 or 2 redundancies.

It is also important to keep the people that have been at the company the longest. As the doubling period effectively divides by two the average duration an employee was with the company, losing those senior employees will speed up the drop in employee average tenure. This means that a lot of institutional knowledge will be lost along the way. This would also mean that you should possibly prefer to keep a senior employee at the cost of hiring a new employee, unless you believe that the amount of time necessary to onboard and be effective is lower than the average employee tenure.

The process of onboarding should be optimized as much as possible.

Anything that requires human power to scale linearly or superlinearly with itself needs to be optimized so that it grows sublinearly.

• Define and agree on the purpose of the one on one
• Define the topics to be discussed prior to meeting
• Track and update metrics that you care about every time you meet
  • e.g., Predictability, Ownership, Purpose, Progress, Belonging
• Discuss the status of those metrics if necessary
• Write in a shared document (between the two of you) what is discussed
• If any action items are defined during those meetings, use a task tracking system to keep each other accountable
  • Always define a deadline on tasks to indicate when the task should be revisited
• Avoid using one on one for status updates

References

• https://web.archive.org/web/20211112152135/https://www.impraise.com/blog/1-on-1s-for-engaged-employees-how-good-managers-run-them
• https://getlighthouse.com/blog/questions-ask-one-on-ones-manager/
• https://about.gitlab.com/handbook/leadership/1-1/

• Read the problem statement
• Look at any provided unit tests
• Add any unit tests you think might be relevant and not currently covered
• Order the unit tests from easiest to hardest
• Ask questions to confirm your understanding of the problem and verify edge cases
• Think of a possible approach to solve the problem
• Share your approach with the interviewers and get their buy-in
  • You may do this by writing pseudo-code as you are explaining your thought process
• Implement your solution
  • If you encounter any difficulties, state them and explain what you are thinking
  • Make use of preconditions/early exit if possible to handle empty cases
• Run your code frequently, even if it is not fully working
• Discuss any follow-up questions with the interviewers