Tech Lead Tips

Imagine that your manager or project manager tells you they are considering making the background of a landing page a video instead of an image. They're about to hire a consultant to make that video. They want to know from you how difficult it would be to embed that video. What is your first reaction? Most engineers start thinking about the how right away, and then diligently provide a timeline estimate. This is a mistake. Your first instinct should always be to understand the why first. Is the goal to increase user engagement? What will the added latency of a video load do to engagement? Are you going to need additional technical effort to make sure that slower devices (e.g. mobile phones on 3G) aren't negatively impacted by that latency? Do they just want the page to feel more dynamic? Is there is a Javascript-only solution to this problem, that can be delivered in a few KB instead of a few MB? You can't fully understand how until you understand why In many cases, witho...

The importance of being earnest It's very important to ask good questions at the end of an interview, if given the opportunity. Many interviewers, consciously or not, will have their decisions affected by this part. Keep in mind that many interviewers will interview multiple candidates every week - I've had weeks where I interviewed more than 10 people. Anything you can do to stand out as a candidate as someone the interviewer would like to work with increases your chances of getting a "strong hire" recommendation. How personable, relatable, and engaged you are can really make the difference between a "hire" and "strong hire." Interviewers enjoy being asked good questions, which will make you a much more memorable candidate. You are interviewing the interviewer, too Keep in mind that an interviewer's job is not just to find out whether or not you are a good fit for the company; they also want to sell you on joining it. This is especially true o...

Every engineer should code review their own code before submitting it to others for code review. It's a valuable opportunity to look through the code you're about to ask your peers to accept and make any final changes. I do this every time I put up a pull request and it often results in changes. The key here is to try to put yourself in the shoes of your future code reviewer, who probably does not have the same context you had when making the change. There are a few questions I usually ask myself: Are my changes self-explanatory? I try to keep my PRs very short; short enough that they can be summarized with a single title. With few exceptions, I consider it an anti-pattern if I need a description for the PR. If that's the case, usually my PR has gotten large enough to be worth splitting or the context that would be in the description is significant enough to be worth documenting in the code itself. Future maintainers should not have to pull up my PR to understand the contex...

I recently changed jobs and one aspect I struggled with was figuring out how large of a company I wanted to work for. I had only worked for small companies (<100 SWEs), though I had a few years of exposure to what engineering work at Facebook was like through my consulting there. I did a lot of research into which would be best for me and wanted to share some of my findings here. Different sizes for different times in your career Different sizes yield different experiences. For a large company, you'll likely end up focused on a very narrow subject matter and learning that to much greater depth. For a smaller company, you'll likely get much more breadth of exposure but likely won't learn any of the technologies with as much depth. So if you're just starting out in your career and you go to a smaller company, you'll have a lot more you can put on your resume, but might not be able to answer more complex questions about those technologies. The same applies to role: ...