Huan Truong

Notes from a developer


'But didn't you write an embedded OS?'


I have been job hunting in the last 2 months or so. Thankfully, I am settled with a company I admire now, and it seemed like I had more luck than the average job applicant. But among the handful of companies that I had the pleasure to interview with, I had my fair share of interesting moments.

The very first interview I had with a startup company was one of them. I mentioned in the resume I sent that I made an distro for the Raspberry Pi called Crankshaft, which is related to the work that they are doing and got a phone interview appointment. We chatted for a bit to introduce ourselves to each other. After 30 minutes, I was asked whether I was in front of a computer (implying it will be a live coding exercise) out of the blue. To set the record straight, I'm totally happy to do live coding exercises, and I understand companies are fed up with impostors who "inflated" their experiences on their resume. However, in that instance, there was no indication it was coming even in the interview appointment email. Nonetheless, I figured I can swallow it. After all, I have been programming for more than a half of my life. I figured being able to code spontaneously shows that I am a fearless ninja warrior when it comes to programming :^).

I was presented with a Leetcode-esque question. After the clarifications about assumptions and requirements, I said, "I can do it in two commands chained by a pipe in bash." And he said, let's treat it like a real CS question. So I asked, what languages can I code in, and the answer was any programming language I like. So I chose to program in Go. Now, when it comes to live coding challenges, one of the biggest problems is that the interviewer always knows the optimal answer when the applicant most likely can only come up with a suboptimal one given a very short time allowance. In a relatively successful interview, either the optimal solution is found when the two parties work on the plan of attack before the coding phase, or in the Q&A phase when a potential question or hint is presented to the interviewee.

I presented the general direction I would take (by the way, "translating" the solution from bash is forbidden). In this case, I did not come up with the optimal algorithm but nonetheless, we agreed to proceed to the coding phase. In the Q&A session, the interviewer asked me why did I choose Go but not C. My answer was I would always choose Go over C if memory or performance is not a required constraint. Go is easier to work with and less boilerplate to worry about. Then, the interviewer mentioned something about a solution involving hashes that makes the lookup operation O(1) and I disagreed with him, so then we settled on them being "practically O(1)." We had another exchange when he poked on my function that potentially use memcpy under the hood, and pointed out it was O(n) instead of O(1) as I claimed. Finally, we talked about some other stuff and I could sense that the interviewer being disappointed when I didn't come up with the optimal answer. I answered something like "I honestly don't know the answer for it – there are more things that I don't know than things I do know."

He asked, "But didn't you write an embedded OS?". Then I realized that he was expecting me to be using C and coming up with the most optimal answer, and not taking "I don't know" for an answer because I wrote an embedded OS. So I told him "Oh, it is actually written in bash, you can see it on Github," and I can feel that he wasn't very impressed by my leet bash programming skillz. The interview concluded not long after. I sent him a thank-you email but never heard back.

I guess I didn't qualify for the next round and was eliminated straight out. I don't intend to write this post to bash the interviewer or to say I should have been qualified – I didn't and I deserved it.

I think though, there is something to say about the virtue of having, expecting, and imposing artificial constraints when it comes to problem-solving in general.

Truth to be told, more than 95% of Crankshaft code is written in bash. I am not even a leet bash programmer. I still have to look up "bash equality syntax" when I need to do a number comparison because the syntax confuses me (I remember the string equality syntax now, though).

That brings me back to the past. After dropping out of college in Vietnam years ago, I had the pleasure to work on a much less technically-demanding job in a small company that resells various specialized software packages. I had the chance to interact a lot with the CEO and the CTO. I first heard the quote "if all you have is a hammer, everything looks like a nail" from the CTO, which has since become one of my favorite ones. The CEO told me he studied Vovinam, a Vietnamese martial art. He told me that one of the main themes of Vovinam is using "soft" to win over "hard." Essentially, it means whenever possible, one should exert the least energy, basically choose the path of least resistance to achieve what they want to do. In overall, I learned the spirit from both of them: It is important to first think about the goal rather than the mean.

The trend of using hard technology is prevalent in tech-savvy people. Just today, someone asked on a forum about using their phone to VNC to their Raspberry Pi to watch Youtube videos because they are inspired by the lack of Adblock on the Youtube app on mobile. They started worrying about Bluetooth and battery constraints, and VNC, and using Bluetooth, and bandwidth and interference between Bluetooth and Wifi. Which is indeed solvable by googling "youtube client without ads" and you'll see NewPipe among the top results, which is an app you can install in 30 seconds to solve the problem. But when you have a hammer that is the Raspberry Pi, the Adblock problem starts to look like a nail.

Recently, a close friend of mine who is a founder of a small company back home asked me to advise him on making a website/app to have "Uber for X" (X being his non-tech business). Upon talking, I realized if he wants to compete by making a good website/app, it's both hard and expensive to do. If his tech model turns out to be relatively successful, a medium-sized company in tech will be able to easily copy his model and out-compete him. Perhaps all he wants to do only need a website to advertise but he doesn't need a website or an app to execute. All he needs is an Excel spreadsheet and a relatively competent secretary to manage that spreadsheet and call people with demand and supply. But when you have a hammer that is Uber, the supply-and-demand problem starts to look like a nail, even when you don't have millions of people using it in real-time.

And I see the same trend in Machine learning, Big data, AI, Cryptocurrency, Internet of Things, Social networks, Decentralized networks, etc. Everything in life, however trivial or hard, is a nail that can be solved with those fancy hammers. So we can have a tablet juxtaposed on a fridge, a bluetooth speaker integrated to a salt shaker, a subscription model for juicers, and machine learning for all kinds of social problems.

I enjoy hard problems a lot. In the last couple of years, working on CUDA kernels to do parallel string comparison is one of the topics I busted my chops on. Some problems are extremely hard and need really clever algorithms and tuning to solve. But alongside with those, there are problems that only need a generally good idea to solve with very little hard code required.

And that's the moment of enlightenment: Writing dumb scripts may become my niche as a person who "wrote an embedded OS."

Edit: I want to make it clear that I think it was fair that I might have been disqualified due to failing to provide the optimal answer, and having a misconception about memcpy's complexity, and maybe a lot of other reasons I cannot tell. Once the expectation for the the superior solution involving hashes is set, those concerns are indeed valid. Whether it is a superior solution, you have the gavel in your mind.