After solving dozens of practice questions, I started to notice a strategy emerge for how I solve technical interview questions. This framework isn’t guaranteed to get you the job; however, the perspective will hopefully help in your practice regimen.
I take code reviews very seriously. It’s one of the crucial processes for ensuring the spread of knowledge transfer and best practices throughout a development team.
I’d like to share some of the books that I read over the past year or two that have been memorable. In general, the selections deal with programming, entrepreneurship, or finance.
For the last year (on and off), I’ve been working on PackageStats.io: an analytics service for NPM package authors. As an author of 60+ NPM packages, I found it extremely frustrating to gather a holistic understanding of the reach/impact of my packages – resorting to clicking through the 60+ package pages on NPM’s site. I built Package Stats to solve that problem – giving authors rich insights into their package ecosystems.
The work ethic that you have is likely a carryover from how you were in school.
Some of us might be labeled as procrastinators – not out of laziness, but out of a misalignment of goals.
In school, high leverage tasks (as teachers and the department viewed them) were tests, homework, and classwork. They assumed that you were in school with the goal of getting a degree. However, going to school is the norm. Not everyone goes because you necessarily want to. Some go because you need to (to get a job). As such, your goals in school won’t necessarily align with that of getting the degree.
In the workforce, it’s hard to interview for goal alignment (i.e. that the company’s goals align with the candidate’s goals). Hiring in tech is a bit desperate so we make offers to talented folks who have barely heard of our products. One solution could be to make sure that the candidate is passionate about your mission and product; unfortunately, that leaves you with an even smaller pool of candidates. If a candidate only want to join your company to “build cool shit,” you’ll need a strategy for alignment and readjustment.
Expecting the candidate to be aware of their misalignment is putting the company at risk. The candidate wants to achieve their goals – not yours.
One of the things that I’ve noticed for the past year is the difficulties that open source development introduces in creating a collaborative team. More specifically, folks who contribute to open source have a tendency to be talented, but need help breaking habits to make them better teammates.
When hiring or speaking about our colleagues, we should strive to avoid calling someone “junior.” We should, instead, call them “less experienced.”
When you join large projects and fix bugs or build features, you typically rely on senior (in terms of time at the company) engineers to say “don’t forget to test feature X (that you probably didn’t know existed).”
Being new, you have limited knowledge of the entire architecture. Our tools should help fill this gap in knowledge. Our tools should help us traverse and understand large application architectures: the primary reason why I built and continue to work on the Sublime Dependents plugin.
I recently implemented a new feature that allows you to better understand which features or pages would break with a change to a module by showing you which app entry points depend on that module. In this post, I’ll talk about some of the tools and performance considerations that went into building this feature.
I’ve been spending quite a bit of time working on Sublime Dependents: a free, Sublime Text 3 plugin that helps you navigate front-end codebases. The plugin was built for large, production codebases (originally built for use at Bēhance). As such, performance is a priority. In this post, I’ll talk about some performance optimizations (in the context of the plugin but applicable to other node-based, static-analysis tools); expanding on my original post on the tool.
I was in London in October speaking at the FullStack conference. I gave a talk on using static analysis to give build tools like Grunt, Gulp, and Broccoli the ability to figure out how to generate their own configuration files based on what we’re doing/using as we build front-end applications.
You can find the recording here: https://skillsmatter.com/skillscasts/5776-using-static-analysis-to-give-build-tools-a-brain
You may need to register for SkillsMatter to view the video. It’s free to create an account.
This talk was a more focused version of the talk that I gave in St. Louis earlier this year. Thanks to the SkillsMatter team and NearForm for putting on a great event with an impressive lineup.