03 Mar 2019
I had my onsite interviews for two companies that I’d like to work for this past week in Seattle. I don’t think I got those jobs, because there’s so many things that I could have done better. But given what I knew then, I’m not sure if I can do significantly better. But if I knew what I know now, I would:
- Focus on writing code a lot faster. I think one of the problems is I take too much time writing code.
- When someone is watching you and you’re being graded while you’re on a whiteboard, you tend to choke. So my advice to myself next time is.. do as many mock interviews as possible. Sure, you need to do a ton of problems to be able to identify what the problems types are, but there’s no point in doing this if you are not comfortable explaining your thought process to the interviewer. There’s a chance that you will completely bomb the interview because you didn’t practice explaining your thoughts and communicating effectively.
- Expand and detail all the answers. Be as explicit as possible. It’s better to throw out all the things on your mind, even if it’s wrong, rather than leave the interviewer in the dark. They might also help you if you throw out a good idea, even if you think it is bad. It might actually be good.
- Focus on really understanding the principles behind solving each problem. Personally, I think it’s important that you understand a few set of problems very well to explain the reasoning and approaches, rather than shotgun the total number of problems. Simply put, if you can’t explain how to solve the problem and your approach, i.e. explain why the asymptotic run time is the way it is, then you’ve memorized the problem. You never understood it. What I find that is helpful is that when I’m seeing other people’s implementations, it’s so much helpful to always go through the solution code on a concrete example. If I could do the interview prep all over, I’d summarize the big principle takeaways for all the problems I do and drill it down. Maybe even make a YouTube video for them.
- Screw the job part. Go in there to learn and have fun. I think this mindset is powerful and effective.
- When the interviewer give you a hint, or tries to lead you to the right direction. Drop the approach you’ve taken and seriously consider what he’s trying to tell you. Seriously. Stop. DO NOT GET STUCK IN A LOCAL MINIMUM. And look deeply and wide about what you’re doing. Ugh. I think this is the most important part I need to work on. But it’s so hard to get out of tunnel vision mode.
Anyhoo, I did definitely learn a lot, and for my next set of jobs I am looking forward to improving my skills with these newfound lessons.
17 Feb 2019
I read an Autobiography of Tesla called My Inventions.
I thought this book was pivotal and enlightening. It was a rather short read of ~80 pages. I highlighted and took notes of the important points of the book. There was one gem there that I found that was fascinating, which I will bold below. Here are my thoughts on the book:
- Early impulses shape our destinies. Tesla talks a lot about his early childhood and how that shaped who he ultimately became. I think this is true - if you are struggling to find a calling in life, one valid strategy is to dig deeper as to what you spent a lot of your time during your childhood - it may shed some light onto your natural tendencies and talents.
- Tesla went through a lot of training with his father on memory games, reasoning skills, repeating long sentences, doing mental calculations, etc. Theyhey were pivotal to setting the master inventor on the right track and gave him an advantage.
- There are things the man was born with. He had an extremely good visual memory. Even when he was little, he had this problem where random images would show up, he’d see it, and they’d be on his eyes for a while. He said he saw a lot of images show up in front of him as a kid followed by random flashes of light. He didn’t need pens or imagery - he could always visualize things on his mind.
- If you focus too much on the detail, you lose track of the main, overarching idea. He emphasizes this that he would continuously refine his inventions and crank out every detail, but sometimes he would lose the big principles on how the invention works because he was in the weeds.
- The man seemed super concerned about his diet and well-being. Seemed like he didn’t even drink coffee or alcohol, thinking that it would do damage to the artery of his brain.
- His parents wanted him to be a religious man. He dreaded going into the clergy. At a certain point, he got infected with cholera and almost died. He said to his father, “Perhaps I may get well if you let me study engineering.” His father replied saying, “You will go to the finest technical institution in the world.” He got better, and afterwards he took a gap year roaming the mountains with a bundle of books on his back to strengthen his body.
- What surprised me was that the man was already a genius himself, but he had a ridiculous work ethic. In his first year in college, he studied from 3 AM to 11 PM and did not skip weekends or holidays. He also thought that he squandered his youth in the library because he thought he spent his best years in the library. When he met Edison, he thought Edison knew so little compared to his reputation and says that at that point he was glad that he spent all that time learning. Anyhow, I was inspired by his work ethic. Even when he worked for Edison, he worked from 10:30 AM to 5 AM the next morning. Edison apparently remarked, “I have had many hardworking assistants, but you take the cake.” This was the most interesting part. When we think of geniuses, we tend to think that they have the world handed to them and they tend to work less. But it’s amazing that someone with Tesla’s intellect would work these crazy hours and have that level of passion. It was inspiring, and it made me a little bit ashamed that I wasn’t working hard to learn as much as Tesla. Someone with such innate talent.
- Tesla talks about how he theorizes that the longer he focuses on one object, the more toxic agents build up. He says that with enough of this toxic accumulation, his brain slows down to a crawl for almost exactly 30 minutes. Afterwards, when he turns to other work unrelated to the work that caused his brain to crawl, he finds that he would have breakthroughs on what he was previously working on. It’s interesting how the brain DOES do work in the background. My thought is that by not focusing on something, your brains takes itself out of a local minimum.
- A small story he mentions is that as a kid, he throw snowballs down a mountain and see how they would become huge. He states how subtle influences can drastically change our destiny. It really made me think about life in general. Small changes today could lead to big changes by the virtue of this principle 10 years from now.
11 Feb 2019
Today I did these things:
- I worked on homework for my part time grad school class(Computer Networks). It involved a graphs and I probably spent too much time on it because my understanding wasn’t super clear.
- I went to Chipotle.
- Slept a ton. Probably the most relaxing Sunday I had in weeks. It’s nice that my sleep problems have gone away. Didn’t planning on going to RC until I got this Computer Networks assignment off my back. By the time it was off my back it was too late. However, I found out about the 24 hour convenience store nearby though =D.
(1) For the grad school class, I struggled a hell of a lot on implementing the Bellman-Ford Algorithm in a distributed manner. What threw me off was that it was so different because the question asked you to take the algorithm, but implement only a subcomponent of it which applied to distributed systems. As in instead of calculating everything from scratch, the nodes passed a partially completed computation to you so you had to complete the algorithm from the partial result. Of course, there were a couple of details and edge cases that needed to be ironed out. I thought that was tough, mainly because I went down a rabbit hole of trying to implement the entire thing instead of using the partial computation. This video was super helpful: https://www.youtube.com/watch?v=dmS1t2twFrI
It was a baffling experience. The example they gave for the assignment didn’t match with my understanding of Bellman-Ford at all because it only focused on a specific subprocess.
When I approached this problem, I tried to read up on all the assignment material, to cover my bases. But some parts of it didn’t make sense, because I didn’t really attempt the problem. This leads me to wonder what the most effective way to tackle any kind of challenge. Is it to read up on the material before tackling the assignment? But if you do that too much, you lose touch with the assignment. On the other hand, you might be reading up irrelevant things without attempting the assignment. However, if you attempt the assignment without reading, how do you even know what you don’t know?!! After 10+ years of learning, I don’t know what the optimal strategy is… maybe it’s a mix of both?!
So this week, I want to dig deeper into graph algorithms and really understand how they work. I think I just had a shallow understanding which caused all this confuddling. I need to dig deeper into it - the math jazz, the whole 100 yards, and all. And try to solve as many graph problems as possible. Last week I was studying Dijkstra’s and for the longest time it didn’t click why we took the shortest path to the current vertex as the next node to be evaluated. Then it clicked: We’re effectively eliminating the shortest link at each iteration when we’re picking the smallest path. The best way to describe it is to evaluate all possibilities(expand), update the paths to that possibilities, and pick the smallest distance node so we can effectively rule that node out(shrink). I think there needs to be a blog post about this, but at one point, that procedure clicked.
(2) There was a Chipotle nearby. There’s so many Chipotles in New York city. I saw one on Google Maps, but I walked past it after taking a look at it with my phone - I subconsciously filtered it out. Anyhoo, I go, and get my usual order. The server gave me a TON of food because she was distracted by her colleagues. Besides that, I got to sit facing the window, and people watched as I ate. What was fascinating was that when I first walked in, the right side door was closed so people had to walk in using the left side door. When I first walked in, I tried opening the right door and realized that it didn’t work. So I came in through the left.
I was sitting next to the door facing the street, this kept happening:
- Person tried to open right door.
- Right door doesn’t work.
- Person tries left door.
- Comes in through left door.
It happened at least 30 times while I ate. It was **ing crazy. All that was needed was a sign saying that the left door was closed. But collectively everybody kept making the same mistakes.
It led to think: Christ, I wonder how much time we’ve wasted as a human collective over the ages making the same mistake over and over and over and over and over and over and over…
The only way we can warn people to NOT make the same mistakes is to tell them.
For major mistakes, people usually write about it. Through a book. But to be warned, you have to read the SIGN. Similarly, you have to READ the book. So now I’m sitting here wondering if there’s a better way to really drill it down to the future generation to not make the same mistakes that never worked…
02 Feb 2019
Recently I’ve been thinking about why some goals fail to be materialized. Then I remembered something that my dad told me, which he also probably got from some other YouTube video that he watched. He said something like this:
“You need to have a dream after dream”
For example a dream could be to get a job at Google. Or become a doctor. But when you accomplish that, what’s next? A lot of people accomplish their goal and have no fire to go further and become better.
Hell, maybe for some, they can’t ever go even after the little rung goal because they just don’t grasp the reason for it all. They fail to see the big picture.
So I think that’s why, like all things in life, you have to start with a good foundation of why you want to accomplish what you want to accomplish. To do this, you need to have a dream after dream. An overarching goal that’s big, ambitious, and meaningful.
The two greatest things that I have trouble always being consistent in working on is playing music and learning Japanese. Maybe reframing it in the dream after dream framework will help me be more consistent.
- I want to write and play music so others can relax and be merry when they listen to me!
- I want to learn Japanese to learn about the Japanese people and fully grasp the nativities of Japanese culture!
31 Jan 2019
Like all things in life, it doesn’t hurt to know how the thing works rather than blindly following instructions on StackOverflow/Google. For the longest time, I could never understand how file permissions work. But they’re rather simple. I’ll try to break it down to what the steps are.
Three different types of access privileges
For every file, there is:
- Read access(r) - Someone can read the file.
- Write access(w) - Someone can write to the file.
- Execution(x) - Someone can execute the file.
We need to be able to describe that file with the 3 parameters. And it’s binary - yes someone can read the file, or no someone cannot read the file. In total, there are 3 bits to represent the 3 attributes, and most unix systems describe those attributes as rwx.
Permissions for 3 different Groups
So one file. Three attributes describing the privileges. Now we’re done right? Nah.
There are three different types of groups/individuals who have access to the files. That’s how Linux is laid out.
Category 1: Owner- The person who owns the file, most likely the person who created the file.
Category 2: Group - There is a group that is attributed to that file.
Category 3: Other - Everyone else.
For each of them, we have to have 3 attributes - read, write, execute(rwx) for a total of 9 bits describing file permissions.
Great. Now we’re almost there. Now a command that a novice user writes a lot(and in reality they shouldn’t) is chmod 777 . What does this mean?
The number represents each category. The first 7 in the hundreds place(777) represents permissions for the owner, the second 777(tens) represents permissions for the group, and the third 777(ones) represent the other category.
Recall back to how binary works. Each place represents a higher power of 2. Starting with 2^0, 2^1, 2^2, and so on.
Here’s a picture for clarification: When you type Chmod 777, this means: Set the owner bits to add up to 7( 4 + 2 + 1). For this to happen you have to set the R bit to 1, W bit to 1, and X bit to 1. Similarly, if you did chmod 077, this means to set the owner bits to add up to zero(no one can read, write, or execute the file). Chmod 377 would mean allow write and execution privileges since 3 = 2 + 1, which is only possible when W bit is set to 1 and X is set to 1. This logic works for all three categories.
Shortcuts: chmod u+x, instead of writing down the numbers manually, are labels to convert letters to the numerical values. In this case, it means allow user category an execution privilege.
It’s a simple, yet fascinating system.