Technical interviews are not just about your knowledge and experience. They're about demonstrating specific pieces of your skillset in really suboptimal circumstances. That is, technical interviewing itself involves a whole set of skills needed to pass. Candidates often focus heavily on specific knowledge gaps when preparing, while some don't prepare at all if they feel confident in their knowledge. What they don't realize is candidates fail just as often for lack of practice as they do for actually lacking the engineering skills required. Here are six features of technical interviews that are addressed mostly, if not entirely, by practice – experience and knowledge aside.
On the surface, the recipe for agile in software development looks something like this: kanban boards, daily stand-ups, constant feedback loops, reports, collaborations, and team meetings. But in reality, you can't get results from just throwing those techniques into a bowl if they’re mixing with things like feature overload, too many project pivots, and ignoring the pains of legacy code.
Creating a workspace at home is vital for WFH engineering. Now I’m not talking about fancy keyboards and other incredibly tempting productivity gear. I’m talking about the holistic design of the entire workspace. In this piece, I discuss furniture, storage, and how to intentionally set up your space so you never find yourself in a state of resistance or frustration. And most importantly, I’ll discuss how you should use the space and how it should exist in the context of your entire home, which impacts your productivity in more ways than I ever imagined.
If you’re an engineer who works on UI, it's your duty to implement the vision of designers and product managers to the best of your ability. At the same time, you're not merely a cog in the machine. Sometimes, it makes sense to say
no — or at least offer insights and options that allow the product team to make more strategic decisions.
Big O notation in computer science is profoundly interesting. However, it doesn't have much application in software development, especially when modern languages and operating systems do a pretty good job of hand-holding as is. In fact, Big O's primary practical use these days is in trivia-style interview questions that ought to be abolished.
In today's WFH life, it's actually more possible to completely commit to time blocking, a system that can help you organize your day so as not to waste a single moment. And my method for doing it is especially great for seamlessly handling coding tasks right alongside the kind of administrative work or team communications surprises that try to pop in to disrupt your flow.
Sometimes, when a project is the right size and scope, it can make for a fun opportunity to try out a new framework on a stand-alone app. We recently had such an opportunity while working on Triplebyte’s new startup equity value calculator.
I recently shared my story on the lessons I learned from doing 60+ technical interviews in 30 days. In this article, I’ll get into more specifics of the various challenges and tests I encountered during this period – including a walkthrough of the trickiest design system question I nailed and the content of the introductory phone call I failed.
Whether it's tinkering with interfaces, interacting with APIs, writing our own rules and logic, and even a bit of booting things up into the cloud on the side — if you've been around long enough, there's a high chance that you've traversed through the different layers of “the stack.” Here's a way to chart out how your experiences and competencies tell exactly how full-stack you really are.