Recent submissions

Comment · 6 years ago
I'm a Bay Area resident. I went to Costco today at 9:00 AM and it was an absolute shitshow.
Comment · 6 years ago
Yes, I do.
Comment · 6 years ago
Good question, and that's the main reason I prefer to own physical books over Kindle books. I know that I own a physical book, but a Kindle book can disappear at any moment. Kindles are great while traveling though.
Comment · 6 years ago
Go to the gym and lift weights or do some cardio.
Comment · 6 years ago
Security
Comment · 6 years ago
Problem Solving 101 by Ken Watanabe provides a toolbox of problem solving techniques. One method I've been using to decompose problems us to use a "logic tree". Start here: https://en.wikipedia.org/wiki/Issue_tree. Another technique is to first explain the problem and solution at a high level (pretend you're explaining it to a friend or coworkers), then write pseudocode for how you would solve it, and then convert that pseudocode to actual code.
Comment · 7 years ago
If you're located in the Bay Area I'm up for it. Or even working together remotely. I'm somewhat junior (3 years of experience) but mentorship is something I've been looking for in my career.
Comment · 7 years ago
Become a T-shaped developer. Have a broad range of skills with a deep expertise in one.
Comment · 7 years ago
Oh look, a thread about my current company. I'm actually in a bug fixing team right now separate from the main product development team. It's an extremely difficult position because as someone else mentioned, you need an incredibly deep understanding of the system to truly resolve these bugs. Unfortunately I work on a 20+ year old legacy codebase with minimal documentation and poorly written code, and our dev team is unwilling to spend any time helping to resolve these issues. They're too occupied with churning our new features, while the bug team is abandoned to clean up the mess from all this new code without any sort of help whatsoever. Another perspective that many people don't discuss is that only doing bug fixing is soul crushing. With things constantly breaking, it can be very mentally draining having to fix them. That being, the attrition rate on the team is quite high because there's very little career growth or satisfaction in being a bug fixer. This experience could be exclusive to my company, and I can't say whether it's effective for the business to run things this way since I'm still really early in my career.
Comment · 7 years ago
Should be titled "How to Ace the Technical Interview in the Bay Area". Even absolute shithole bottom tier companies or unknown startups are asking these questions. Write perfect code on the whiteboard or get rejected. You have to put in A LOT of time into preparation even if you don't want to work at Google, which is ridiculous.
Comment · 7 years ago
The books that I've read that have helped me immensely: How To Solve It, Problem Solving 101, 5 Elements of Effective Thinking, and Peak: Secrets from the New Science of Expertise. Trying to improve my problem solving ability in coding forced me to look inwards and analyze my thought process to understand why I'm able to solve some problems and unable to solve others. Ultimately I've realized the root cause of my inability to solve hard problems was poor problem decomposition. Every hard problem can be broken down into subproblems, and those can be further broken down until they become easy enough to solve. Then you just connect all the pieces together. It takes a lot of deliberate practice with many problem types to be able to recognize how to decompose problems, however.
Comment · 7 years ago
So basically you're asking for a HackerRank screening. In my experience, if your code doesn't pass 100% of all test cases you get automatically rejected. At least with a human interviewer, they can evaluate your thought process even if the code itself isn't quite correct. Trust me you don't want to me interviewed only by robots.
Comment · 7 years ago
Spaced repetition: https://en.wikipedia.org/wiki/Spaced_repetition

If you don't actively review this material you're going to forget it. I created my own study guide for data structures/algorithms that I frequently review to prevent forgetting any concept. Every few days, or at least once a week, I'll take a blank sheet of paper and try to write down everything I possibly know about every fundamental data structure, including pseudocode and real code for operations such as searching/insertion/deletion. When I go through interviews I read my notes and do this active recall exercise at least once a day every day. Unfortunately there's no shortcut and you have to actively think about and code this material in order to remember it (if your day job doesn't involve knowing those things).

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton