Posted by: changheuk | April 19, 2017

Had my first interview today, they basically grilled my resume and experience and traversed my tree of knowledge in depth first search style, extremely exhausting, i.e. they weren’t trying to make it “hard” or “easy” so much but to straight up tackle every corner of my knowledge and see how much I could spit up on it.

It really exposed a nasty truth to myself, which is that I have been intellectually lazy for my whole life, deferring and outsourcing decision making to random blog posts and well worded Hacker News responses, instead of doing deep diving into books, really learning, etc.

Some things (a lot of things) I’m missing:

  • Why PhantomJS processes run out of memory (lol I don’t know)
  • What hard things did I do with Node (lol I don’t know, what is hard?)
  • Talking way too fast, using filler words that suggest loose understanding (which unfortunately is true) and analogous thinking
  • Bad choices of words – I interchange the words ‘process’, ‘service’, ‘web app’, ‘server’, ‘computer’, even ‘program’
  • Node.js streaming – use-cases
  • Event-driven architecture – I couldn’t even conjure an example
  • Redis pub/sub vs. __MQ vs. HTTP for Microservice communication
  • Dependency Injection – don’t just say Inversion of Control or use a loose metaphor.
  • Caching – how might you have done it better
  • Even forgot the very basic Javascript, where:
    • if we wanted a partially applied function such as fs.writeFile(‘test.txt’, text) where ‘test.txt’ would always stay constant, then we should use const writeToTest = fs.writeFile.bind(null, ‘test.txt’), at which point which I forgot whether we could use null or fs as the context
    • could also use closures for the above, such as const writeToTest = (text) => fs.writeFile('test.txt', text);
  • Generally not knowing what’s new: Node 7, Loopback, async await

Was recommended the book Node.js Design Patterns.

A mistake I’ve mostly made is too little practice and even worse, too little input.

The bulk of learning for almost any usable knowledge happens during practice. Watching, listening and reading are the supplementary activity, supporting practice by filling explanatory gaps and details.

Source: Scott Young’s recent post on learning misconceptions

An obvious flaw in my knowledge can be illustrated using my not-knowing-dependency-injection, through several levels of “knowing”:

Level 1 – completely oblivious: what is dependency injection? Sounds like a malicious hack.

Level 2 – surface level terminology and example: *Googles* something Inversion of Control… uhh function($scope, $http, HelloService) { ... seems to incorporate that…

Level 3 – here’s an example. Instead of:

var Logger = require(‘Logger’);

function a () {

var logger = new Logger();


We can use:

function a(logger) {

var logger = new Logger();


This isn’t about singletons or all the code coming from one source, its that the function a is more easily interceptible since the dependency is an input rather than a requirement. It makes unit testing using mocks actually feasible.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: