- 2022-02-12: Limiting factor in playing an arcade style space shooter via sensors and a hooked up keyboard.
- 2022-02-05: Does the time taken to count integers (that are less than a threshold) in an unordered array, remain the same, or vary?
- 2022-01-29: Does splitting a service into microservices help or hurt the availability?
- 2022-01-22: Can closures+lambdas be implemented irrespective of whether the language is garbage collected?
- 2022-01-15: Debugger crashed before a breakpoint was hit. What happens to the program being debugged?
- 2022-01-08: No puzzle on account of my travels
- 2022-01-01: Relative CPU performance of a process b/w native vs
Some time between 2021-22, I ran a list of puzzles designed to push developers into developing a better understanding of the technologies they use on a day to day basis. Each puzzle is designed to be fun, provocative, and short.
This is a complete list of those puzzles. Each link takes you to the tweet where I first posed the problem. If you like any of them, please feel free to share with others.
Edit (2024-01-27): Adding other puzzles to this 2024 onwards. Criteria:
- Problem statement should be understandable by most in s/w tech, even if the ability to figure it out may not be.
- Thinking about the problem should lead to clearer understanding of some foundational concept.
- Should be short.
- Should be fun to ponder over.
I liked the way Grokking the coding interview organized problems into learnable patterns. However, the course is expensive and the majority of the time the problems are copy-pasted from leetcode. As the explanations on leetcode are usually just as good, the course really boils down to being a glorified curated list of leetcode problems.
So below I made a list of leetcode problems that are as close to grokking problems as possible.
/* | |
* ======================================= | |
* C++ cheat sheet | |
* ======================================= | |
* 01- string | |
* 02- vector | |
* 03- pair | |
* 04- set | |
* 05- map | |
* |
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
/* | |
cycle.js | |
2015-02-25 | |
Public Domain. | |
NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK. | |
This code should be minified before deployment. | |
See http://javascript.crockford.com/jsmin.html |