A Tale of Two Interview Loops

May 5, 2023 by Gabriel - Reading Time: 16 minutes

It was mainly the worst of times, when a comedy of errors left me on a prolonged job search, alternating between the spring of hope and the winter of despair. But there is lemonade to be made from the almost three dozen ~~lemons~~ interview loops I went through, and this article is that lemonade. Because, while astronomical amounts of money go into recruiting, and even though we live in the age of wisdom, most of the interviewing process is sorely broken at the majority of companies; and so we also live in the age of foolishness.

From my experience, most Big Tech companies more or less copy each other, and because they are giant ships that are impossible to turn quickly, change comes slowly. Many startups and smaller companies then look to the giants for inspiration, out of some combination of familiarity (because they used to work in Big Tech) or imitation (“we’re also Big Tech!”) or just assuming that anything Big Tech does must be good, because one hundred billion dollars can’t be wrong.

And so we end up with the typical tech interview loop:

Sourcing: usually from a referral, but could be a recruiter reaching out after a LinkedIn search or, rarely, actually responding to an unsolicited application
Recruiter screen: to do a sanity check and vet logistics (salary range and other expectations, like remote work)
A general aptitude screen: coding or system design or leadership chat or some combination, depending on the role
A panel, or “virtual on-site”: somewhere around 5 interviews scheduled all at once — but maybe not happening on the same day — with a mix of roles, from engineers to product managers to engineering managers to designers to QA
If that went well, a final interview, with a senior leader, and then an offer

Some variant of this describes almost all of the ones I’ve come across, but: the devil is absolutely in the details, and those details are the difference between a great process and a terrible one. So let’s look at two hypothetical loops at those extremes.

The Bad Loop

If you’re hiring, and elements of the bad loop sound like your company, please think about improving them. If you’re looking, and you run into one a little too close to this: I’m sorry.

Sourcing

The bad interview loop usually starts off badly from the beginning. It’s obvious they don’t invest in candidate experience up front, and it rarely gets better further down the process.

There are a few ways to screw up sourcing, and the most common is just never getting back to candidates. No rejection on merit, no timeout rejection, no insulting GIF — just silence. This happens a lot.

Marginally better are companies that do reply, but after way too long. The worst of these for me was a startup that got back to my application — which was a referral — after 47 days. They set up a recruiter screen for the next day, which went well, and then an interview with the VPE for the following week. Unfortunately, that got rescheduled for the next week… and again, for the next week, and then again for the next week, and when it got to the 4th time, I decided to bow out of the process. After 84 days total.

The third common way to turn people away at this step is to send clearly automated emails or LinkedIn messages that are supposed to sound tailored to you. Like the recruiter is channeling a horoscope writer.

Hi Gabriel,

Your profile looks great. It looks like you are thriving at Hillrom, so I know it is a long shot that you’ll be interested, but hope springs eternal!

[Recruiting company] has been retained to recruit an Embedded Systems Manager at [hiring company]. This person will lead the embedded systems team comprised of electrical and software engineers while also serving as a software lead on connected care and digital health projects.

I’d welcome the opportunity to talk with you. Please let me know if you are interested to learn more. Thanks in advance and I look forward to your response.
An actual email I got. I’ve never worked with embedded systems.

In short, the sourcing is bad if they:

Don’t value candidates, and
Don’t value the company’s image

Recruiter Screen

This step is actually pretty hard to do badly, but it generally involves the recruiter being out of their depth and/or not caring about their craft. I’ve spoken to both (a) recruiters who had no idea there was a difference between Java and Javascript, and (b) ones who did, but treated our conversation like the most annoying part of their day — like their Zoom background might as well have a giant “I’d rather be doing literally anything else” banner. And of course, the worst is (a) and (b) combined:

Recruiter: yeah hey, I’m in a rush, but this won’t take long

Me: okay…

Them: so I saw your resume, I don’t have it in front of me right now, but can you just answer a few questions?

Me: sure

Them: ok so this is a management role, you have 5+ years of experience managing, recruiting, and mentoring a team of diverse engineers?

Me, realizing they have, in fact, not seen my resume: yeah

Them: do you have 8 years of Java?

Me: uh… [trying hard to make it past the syntax errors] … yeah

Them: do you thrive in a fast-paced environment?

Me: sure

Them: can you speak good English?

Me: I think you said the quiet part out loud.

General Aptitude Screen

After the boilerplate kind of checks, comes the first true test of the candidate’s mettle: do they actually have a notion of how to do this job, or are they a complete fraud? For engineers, this is almost always a somewhat basic (sadly, often leetcode-y) technical interview. For managers, it’s one of three things:

A purely technical interview, because the thinking is managers should also know how to leetcode
A leadership interview
A bit of both

The bad versions of this are the ones that don’t test aptitude required for the job. We’re hiring a staff engineer for their background in designing APIs and scalable architectures, but first: let’s make sure they can figure out the trick to finding the longest palindromic substring. Because that’s the thing they’ll constantly trip over in their day-to-day job: figuring out solutions to neat little puzzles that can be done in 20 minutes.

And that’s really the crux of the problem, because this kind of exercise filters out a few kinds of traits that, in my experience, a lot of good engineers have:

Not performing well while being watched
Not having done algorithmic puzzles in years
Not particularly caring to spend dozens of hours preparing for interviews
Not having slept well the night before the interview

The arguments for leetcode interviews don’t hold water either:

It’s fair: everyone from the new bootcamp grad to the Sr. Fellow gets the same questions. Is that fair though? It’s fair for the new grad, because they have no work experience and it’s all they can be tested on. And early in their career, they should still remember this stuff. But it’s not fair to someone with a decade of experience that (correctly) hasn’t thought about sorting anything beyond typing my_list.sort() in almost exactly as long.
It shows motivation: the thinking is that if you’re willing to put in the hours to dust off long-forgotten skills, that means you’re a go-getter. Either that, or you have a ton of free time. Or are willing to work hard for 3 months so you can rest and vest.
It’s a great weeding-out tool: “here at Hooli, we get far too many yahoos applying and we need a simple and consistent way to halve the middle of the funnel.” This I can’t argue with. If you have too many applicants and just need an efficient way to politely send scores of them away, while making it look like meritocracy, then this loop design does in fact meet those requirements.

Panel

The next, and sometimes final step of the process tends to be an interview panel. It’s kind of like a death panel, except it’s very much real, and only decides your professional and financial future. It’s a holdover from the days of in-person interviews, which you can tell because it’s often called a “virtual on-site”.

Back in the before times, companies used to fly people over to their headquarters, even across country, for a gauntlet of interviews held over a full day. You’d talk to 3-7 people across ~4 interviews — because sometimes they’d double up, or you might even have several people in one interview. Like much in-office culture, most companies have lifted and shifted this process into the Internet, and now offer the same experience, but worse because it’s over Zoom. Also better though, because you don’t have to fly to every interview.

The idea of having several people interview a candidate is obviously fine. The problems here are more around how they’re structured, and how much freedom the candidate has to tailor this step so they can make a good impression. Because to a lot of people, if not most, this step is very stressful. Some would rather do it in one day and get it over with (even if they’d perform better otherwise) and some would rather split it into two or three days. Companies that don’t care, also don’t care about candidate’s preferences here.

The more general problem though, that many companies are guilty of, is not adapting this step to the modern world. It’s not great for the company to sign up for more than ten people-hours of time (adding in the prep, write-up, and debrief time) just based on the one aptitude screen. Especially if it’s a low-signal one, like leetcode. Data is king here, but I would bet the panel pass rate at most quality companies is not that high, and so that adds up to a lot of waste all around: effort and stress for the candidate, plus time and energy for the interviewers.

The last thing to mention here is the companies not investing in quality tools, especially for the technical interviews: having the candidate write code in something like Google Docs instead of a purpose-built thing, like CoderPad or HackerRank. Same goes for whiteboarding, for like system design exercises. And using Microsoft Teams.

Final Interview

This step, mirroring the recruiter screen, tends to be more of a formality or sales tool. By now, the candidate has passed the panel gauntlet, and this final hurdle gives good candidates the opportunity meet with a senior leader in the organization, while also giving that leader the opportunity to meet with promising hires before the offer goes out.

Where this is done poorly, it’s either not done at all, or it’s a very rigorous interview. Not doing one at all can be fine, but — especially in a more talent-driven job market — having this step can sway a candidate with multiple options. It’s also great, from an organizational health perspective, for the most senior leader to either be part of the interview loop, or schedule a 1:1 shortly after the candidate starts; doing both is even better.

This interview should be real, of course, with questions that give the interviewer insight into the candidate; but if it’s too much more than formal, it can both put the candidate (who has already been through the gauntlet) off, while also causing an internal problem if the candidate fails a hard interview, after having already passed the panel. Can the more senior leader just override the panel? Because that doesn’t sound like a healthy org.

Surprise Step!

Sometimes, panels are split. Lots of soft thumbs up and down. And the job req has been open for months, so they don’t want to pass on a potentially good candidate. And so they decide to tack on another interview — or maybe repurpose the Final Interview above — in order to break the tie. This is a smell of a poor interview process. One that is not designed to produce strong yeses and nos. Or one that is, and has failed. Most well-run processes will explicitly forbid this, and for good reason: an 8th person won’t add that much value to the chorus.

The Good Loop

Now, for the fun one! Sorely few of the interview loops I’ve experienced have been good, but for the ones that have, it provided so much signal that it would’ve been worth taking a lower offer. A lot of the anxiety of committing to a role comes from the company’s culture, and a great culture usually comes out through the interview loop.

Sourcing

Great sourcing is genuine. Also the things I said earlier about valuing the candidate and the company’s image. But great places to work do it with care. The messages are personal, not form- or AI-generated. They show that the sourcer has actually read and understand your resume, as well the job description. And they make a good case for why they think you’d be a good fit and choose to go through their particular interview gauntlet.

But good sourcing is hard. To do this well, it obviously takes a lot more time, and therefore people, and therefore money. So it’s not a bad signal if a company is just okay at this. BUT, if the sourcing really is great, that’s great signal: it shows the company has committed actual dollars to candidate experience, because they care about attracting the best employees into a great environment.

Recruiter Screen

A great recruiter screen gives the candidate a positive glimpse into what the rest of the process will be like. The recruiter is prepared, understands what the candidate’s resume or LinkedIn says, and has good follow-up questions. The chat is friendly but organized and the run-down is provided up-front: “first I’ll give you an overview of the company, talk a little more about the role and give you a chance to ask questions, and then talk about your experience and how it might be a good fit.”

It’s mostly proforma, but value comes out of it: the recruiter gains more clarity than the resume provides, makes sure the logistics are lined up, and the candidate asks questions about the team/org, responsibilities, tech, etc that aren’t in the job description. Even if it turns out that something doesn’t line up, like salary expectations, everyone leaves feeling like it was a productive call.

General Aptitude Screen

An effective aptitude screen tests just that: how well this person is suited for this role. This means that the defining characteristics of the role have been thought through and distilled into discoverable skills; and then questions have been created which are good at discovering those skills. But an important piece of the puzzle is where the confidence comes from, that those questions illuminate the correct things. In most places, it’s just someone’s gut feeling.

We make social networks here at Hooli, so we need to make sure people understand Dijkstra’s algorithm. We’ll ask a question where the obvious solution is the algorithm, and pass people that either use it in the solution; or they mention it, have a good reason for not using it, and still come up with a good solution.
Hypothetical, but I’m sure someone somewhere has written interview questions like this.

Some problems with the above:

Do successful employees really need to understand Dijkstra? Is there a correlation between that and job performance? Is it important for this particular role and experience level?
To most candidates that are familiar with Dijkstra, is it obvious that it’s the right solution here? Does the wording and the problem statement lead them there? Or is it just obvious to the people that came up with the question?
Can the question actually be favorably solved in another way? Are we too narrowly targeting a particular way of thinking?

Good questions have been purposely designed all the way through. Their goal has been validated by data as being good predictors of employee performance. The questions themselves have been vetted by trying them out on actual people, getting their feedback, and looking at false positives and false negatives. Ideally, those people aren’t just employees — though this, of course, is difficult.

The above applies to questions asked as part of the panel below. The essence here is that a great aptitude test is effective at predicting job performance.

Panel

I’m not sure what percentage of rejections in the interview process are false negatives — meaning a perfectly good employee has been turned away — but I would bet a small amount of money that it’s significant. As in, more than a quarter. And I’d also bet that a lot of that has to do with the candidate being nervous. And I’m not alone.

Chris Parnin of NCSU has a great paper in ACM on the matter, pointing out two things we all already know, intuitively:

An estimated 40% of adults suffer from performance anxiety, and
The typical software interview “has an uncanny resemblance to the Trier social stress test“

For those of you who haven’t clicked on that link, that stress test was created to induce change in physiologically measurable stress markers, like heart rate, cortisol, and other things. The test makes those markers increase, in most people, anywhere from 30-700%. And how does it do that? It’s a simple, three part process:

You have 5 minutes to prepare a 5 minute presentation for a job interview
Ok, it’s time for the presentation, but: surprise! Your presentation materials have been taken away.
- Also, the judges will be silent and maintain only neutral expressions the whole time
Count down from 1022, by 13s. If you make a mistake, start again from 1022.

“Uncanny resemblance” indeed, right? It’s basically the same thing as software interview, which gives the candidate a complex problem — much more so than counting down by 13s — except they don’t even have time to prepare! And the typical interviewer is cold and silent. (As an aside, please don’t be that interviewer. Read my Art of Interviewing, if you are.)

What’s more is that he says “scientific evidence finds that women experience disproportionately more negative effects from test and performance”, and while I’m not saying that this is the only reason tech might be so heavily male-dominated, I wouldn’t be at all surprised if it turns out to be a big factor.

So what’s a company to do? The above paper has one suggestion — and I think it’s a special case of a more general solution — which is the “private interview”. That is, rather than give the candidate a problem and watch them solve it, give them the problem and go away, letting them solve it in private. When they ran this experiment, the results were undeniable:

In the public setting 61.5% of the participants failed the task compared with 36.3% in the private setting. […]

Interestingly, a post-hoc analysis revealed that in the public setting, no women (𝑛 = 5) successfully solved their task; however, in the private setting, all women (𝑛 = 4) successfully solved their task—even providing the most optimal solution in two cases. This may suggest that asking an interview candidate to publicly solve a problem and think-aloud can degrade problem-solving ability.
from “Does Stress Impact Technical Interview Performance?”, in Association of Computing Machinery

The private interview is a great idea, and an improvement on the “take home” challenge, which suffers from the fact that some people will spend an hour on it, and others will spend ten, with two friends helping. But, there are problems with it. One that the paper mentions is that some people were frustrated by not having access to the proctor, to ask clarifying questions and be kept from drifting. So it’s not a one-size-fits-all solution.

But what’s the philosophy behind the private interview? That most people get too stressed out by ~~a stress test~~ an interview, and doing it in private helps. Most people though: not all people. And that, I think is the key insight: what the paper calls “provide accessible alternatives”.

Great companies will tailor their process to help the candidate succeed. They will allow the panel to be split up over as many days as there are interviews. They will allow the candidate to pick the programming language. They will have a “live” option and a “take home” option — I have yet to see the “private interview” option, though it’s by far my favorite. They will train their interviewers to be kind, to be expressive, and to focus on the person, not the question.

In short, as with all good science, they will make sure they have adjusted the process to eliminate as many confounding factors as they can, in order to minimize false negatives and false positives, and give everyone a fair chance.

Final Interview

There’s not much left to say about the final interview other than that a good leader will leverage them to motivate a promising candidate. So instead, I’ll summarize the two loops:

bad: disinterested people going through the motions of a process that will usually produce some result
good: thoughtful, kind, well-trained people assessing how well this candidate might fit into this role

My Slack Tips, 2023 Edition

April 4, 2023 by Gabriel - Reading Time: 9 minutes

(This is a direct copy of the 2021 Edition, with the salient changes highlighted in green.)

You know those recipe websites filled mostly with the backstory of how they discovered this amazing cookie recipe that changes their lives, and what joy it brings their three free-spirited, yet precocious children every time they make the cookies? This is kind of like that, so scroll down to “The How” if you don’t care about “The Why”.

The Why

I love Cal Newport‘s ideas about deep work. He writes a lot about how to protect your time so that you focus for stretches measured in hours instead of minutes, with no distraction. For Joel Spolsky the same concept was “getting in the zone”:

We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.
from “Where do These People Get Their (Unoriginal) Ideas?“

Joel followed that up by explaining how task switching is bad, Jeff Atwood echoed him, Rands showed us how he kept distractions at bay and years later, after Slack arrived on the scene making this problem worse, how he used Slack. It being such an important topic — especially with the boom of remote work making Slack even more common — this is my version of that Rands article, with a few years of more Slacking under the belt.

For programmers, standard Slack policy should pretty simple, flowing out of the principle of guarding “the zone” fiercely:

Turn off all notifications, except for when you’re being specifically @ mentioned
Specific mentions aside, only read Slack during your downtime — between meetings or while your VM is rebooting or whatever.
Don’t feel like you have to read everything in all the channels. Start with your favorite channels, and go as far as your downtime will let you.

For engineering leaders though, especially manager- and architect-types, it’s not so simple. The broader your scope is in the organization, the more pertinent info you will learn via Slack discussions, and the more value there is in being in a lot of different channels, so you can glean stuff like team Aardvark being in trouble because they’ve been complaining about their infrastructure daily for a week; or you can quickly unblock Bob who can’t remember where the functional spec is for the login screen, or focus a search API design discussion between Carol and Dave, and then build rapport with the other foodies in #random-food.

At the bottom of it all, underneath all of the turtles, programming is about communication between people. The source code isn’t for the processor, but for other programmers. And every successful team is a well-oiled communication machine. The best teams are the ones that have shorthand and can finish each others sentences. You just know that a team like that — and full of smart people — is going to be off the charts with productivity.

So as an engineering leader, possibly the single most important job we have is to do everything in our power to facilitate effective communication. Which these days, includes being a Slack Jedi. But, we also need to get some actual tasks done, so we can’t let it take over the whole day (at least not every day), which means there’s a balance to be found. Below, is how I found that balance.

The How

I’ll caveat these 11 weird tricks with the fact that this is what works for me, in my situations so far, and while your mileage will probably vary, at least some of this might be helpful. So:

Tweak the in-app Slack notifications. The default notification settings inside Slack are mostly fine: it notifies you for DMs, mentions, and keywords. But I do make a few small changes:
- I usually add a few keywords, like my name, team names, or project codenames. I go into the notification settings of any “system down” or other emergency situation kind of channels and set them to get notified of all messages in those channels.
- I go into any channel in which I don’t want to miss conversations buried in threads, attached to messages I’ve already scrolled by, and check the “Get notified about all replies and show them in your Threads view” setting
  - This is kind of buried in the channel details, in the notification settings, in the “more notification options”. For channels you really care about, it’s the only way to deal with threads
Turn off all notification types from the OS, except for the badge icon. Not inside the app, but in the Notification settings of macOS/iOS/Windows/whatever, I have the Slack app set to not be allowed to make a sound, to never pop anything up, to never bounce anything — to never do anything at all, for any reason
- Except, on Apple OSes, to make the badge counter appear over the app icon
- In the macOS desktop Slack app specifically, in the “Notifications” section:
  - I uncheck the “Bounce Slack’s icon…” checkbox
  - If I’m in multiple workspaces, I also uncheck the “Show a badge…to indicate to activity” checkbox. Which keeps the badge icon from getting a red badge everytime someone says anything in any other workspace.
- That way, I can get in the zone when I need to, and won’t get distracted by Slack, but can still glance at it, once in a while, at opportune moments to make sure it doesn’t have 57 urgent messages for me.
Low barrier to enter channels. I’ll enter most channels as I come across them, because in the bad case, I don’t read them and in the worst case, I leave.
- Slackbot helpfully and periodically reminds you about channels you might wanna leave, also.
Low barrier to create channels. Whenever a topic starts getting enough airtime, or when there’s any other reason for it to have a dedicated channel, I create that channel. The more the merrier.
- You can go overboard, but as long as the reason for the channel is clear, go ahead and create it. You can always archive it later if it was a mistake.
- “But I’m in too many channels!”
  - Creating more channels is unlikely to result in more messages. The only difference will be that those same number of messages will be more organized! So more likely, you’re in too few channels now, and conversations are a hodge-podge, instead of narrowly topical
  - Channels are free and an organized Slack is a happy Slack, because it is way easier to find that important conversation about search API design if you know it happened in #dev-search.
- If you actively want to foster conversation in a channel, consider making it private. People feel safer talking in them, and the Slack stats I’ve seen bear out the fact that the large majority of messages happen in private channels or DMs.
Organize the channels in groups and make them disappear. You can create channel groups in the sidebar, order the groups however you want and for each group, show all the channels or just the unread ones. You can also order the channels within the group in different ways.
- I order them by priority within each group and show just the unread ones.
- My groups are about related topics, ordered by how important they are to my role: my team’s channels and DMs in the first group, various dev channels in the second, then management channels, field support, water cooler, etc
Embrace speed reading. The human brain is great at patterns, and you can quickly pick up the importance of a conversation from some key signals like what channel it’s in, who the participants are, how long the conversation goes for, key words being repeated, emojis being used, etc.
- In some channels, like ones about nascent projects or downtimes, I read every word carefully — but that’s very much the minority.
- For the majority, I scroll through at a good speed, slowing down only when my spidey sense tells me I’m speeding through something worthwhile. It works well — false negatives are rare.
Embrace emojis. Not only do they make conversations fun, but they also convey tone (which is super important) and, as reactions to messages, they serve as pithy replies that add value to the conversation without also adding volume to it.
- e.g., using a check mark to indicate that you read something without indicating judgement, or a dart that their message was right on the money, or an up arrow as an upvote — they’re small, very helpful gestures that significantly improve the conversation.
Use reminders. When I do go into Slack, I like to at least clear all my mentions that turn channels red. But sometimes I can’t actually service a message. Maybe that’s because it’s asking a question I have to research, and I’m in the middle of something. Or I want to make sure that I follow up on a conversation after my current meeting. Or someone wrote a 7 paragraph message and I’m between meetings and don’t have time to grok it. I use reminders for all of that.
- Most of my reminders are set on existing messages that I need to do something about
- Some of them, I create with the /remind command
- All of them, I snooze extensively until the time is right to work on them
- It’s important to note that this can go overboard and you can end up with 37 reminders you snooze every day because it’s turned into your to-do list. And Slack reminders are a terrible to-do list.
  - Only use reminders for things you need to do in the app
  - For general to-do items, port them to your to-do list app
Don’t use threads. It’s quite possibly the worst feature in Slack. Some people love them, but don’t be those people. Terrible UX aside, all threads are is a way to hide conversations for no good reason. If you want to read every word in a channel, and you’ve read them all, but then Ethan decides to start a thread off of someone’s message 50 messages up, guess what? You’ll never even know. Unless you have that setting from item 1.
- Some people use threads because they came too late upon a conversation that’s scrolled away, and want to continue it; there is a better way: share the message into the same channel, and that posts it at the bottom, with your comment attached.
- “But I don’t want to bother everyone in the channel with my thread”. The conversation either belongs in the channel, or it doesn’t. If it doesn’t, create another channel or group DM. But there’s no reason to hide it.
- If you just can’t get away from threads because of <reasons>, every so often, please do a courtesy checking of the “also send to #<channel>” box, so that people realize the conversation is still happening.
Nudge people toward the proper channels. Most people are trying to get their job done and aren’t so worried about keeping Slack organized, so when they start a conversation about lunch in #dev-breakfast, it’s probably because they didn’t even know #dev-lunch existed, or because they had been talking about brunch and it morphed into lunch.
- The point being that, as is generally the case, people don’t intend to break the rules and usually just make mistakes.
- I, as Slack Jedi, have to minimize the chance of mistakes by establishing good channel-naming conventions and keeping topics narrow, but when mistakes do happen, it’s not the end of the world, and an innocent mention that the lunch channel exists is normally the only thing that needs to be done.
- Be super nice and soft about it, because creating anxiety about the proper channels is kind of antithetical, since it then stifles communication.
Try to mark everything read by the end of the day. I don’t always clear my email inbox every day (or longer), but I almost always clear my channels, to give me peace of mind.
- On days filled with meetings, it’s harder, but I keep up with the @ mentions and high priority channels as I can, and then quickly scroll through the less important ones, just to make sure I’m not missing anything important.
- Yes, the Slack FOMO is strong with me, but the clearing doesn’t take long. I’m in dozens if not hundreds of channels, in a Slack with hundreds of people and — active conversations aside — I can clear a day’s worth of chatter in about a half hour, knowing then that I’m on top of things and won’t be surprised the next morning by Fiona with a “so what are we gonna do about that nasty database locking issue?”

So that’s how I stopped worrying and learned to love the Slack: by putting it in its corner and giving it attention on my terms — no more and no less attention than is beneficial.

Lessons Learned on the Job Search

February 11, 2022 by Gabriel - Reading Time: 13 minutes

I’m starting what I’m sure will be a great new job at an awesome company soon, but before I got that offer (and four other great ones), I was on the interview circuit for a few months. When I started looking, I figured that in this boiling job market (of mid-late 2021) it would take like around a month. For better or worse though, I hit a string of bad luck on what turned out to be an already overly-optimistic timeline: two hiring freezes (both at the offer stage in the interview loops) and a conflict of interest (after an offer).

I say “for better”, because this bad luck did come with a silver lining: it prolonged the process enough that I ended up in a lot of interviews: 79, over 34 interview loops. Which, on the one hand, was exhausting; but on the other hand, it gave me huge exposure to the current landscape of interview processes for engineering leadership at tech companies. I’ll write another article on how I think these processes can be improved, but this one is about how to deal with them — as a job seeker. Specifically, an engineering leader, such as management, or staff-level IC and higher.

This experience was so radically eye-opening for me, because aside from a random interview now and then, I’d never been exposed to it on this level. And in the pre-pandemic world, this gauntlet would’ve been impossible, due to the travel alone. My previous jobs came to me — which is a completely different dynamic — so I’m writing this to share what I’ve learned, mainly for others that are looking for a change, and are as unfamiliar with the landscape as I was.

The main takeaway: interviewing is a skill onto itself. It’s largely unrelated to the day-to-day of the job, it matters a great deal, and it’s absolutely something that can be learned. It’s like dating that way: the first few dates are crucial, and making a good impression is paramount, but the impressions you get on those early dates contain a lot of not only false signals — like being nervous or interested in everything your date loves — but also superfluous signals, that don’t matter a year into the relationship — like your favorite band.

And unfortunately, both dating and interviewing are optimized for charming (and good looking) people, who will always win out if everything else is equal. Fortunately, being a polished interviewee is a skill that I think most people can master with practice. Not unlike the premise of the movie Hitch. Because you could be the most amazing engineering leader in the world but, if you don’t interview well, no one will ever know that — aside from the people who’ve worked with you.

Before we get into the details, some more context: I interviewed with a wide range of companies, from Big Tech like Meta/Facebook and Amazon to smaller ones like like Etsy and Reddit, to startups at various stages. I applied for only remote roles, roughly evenly split between Engineering Manager (EM), Sr. EM, and Director — with a few senior IC roles added in — and all my interviews were remote, via Zoom or the like.

And I kept statistics.

But don’t worry, there’s a TL;DR section at the end that you can always skip to, if it gets too dry.

Anatomy of a Loop

Most companies have a 4±1 step process:

Screening call with an internal recruiter
- 30% of my interview loops skipped this step
A first round, which is generally a role-fit discussion with the hiring manager (HM)
- I consider this to be the first round of the loop
- For me, 76% of the 25 of these I had were just a casual discussion with the HM
- Of the remaining six:
  - four were a panel (two of which had technical components)
  - one was a coding challenge
  - one was a design challenge
A second round, consisting of one or more people, sometimes as a panel (meaning multiple interviewers are in the video call), sometimes as a string of video calls with individual interviewers. But all pre-scheduled together.
- Eight of the 13 I went through had a technical bent:
  - four included a technical chat
  - three design challenges
  - one coding challenge
- Six of them were also panels:
  - one of the design challenges, and three technical chats
A third round, which is usually the opposite of the second: if they did a panel first, then this is not a panel; and vice-versa. If they have a technical screen and the second round was technical, then this won’t be; and vice-versa.
- 29% of my interview loops skipped this step
- Three of my five were panels, and one of those was technical
- The other two were informal chats with a CTO or VP
Hopefully, an offer
- Most of my interview loops skipped this step 🙂
- All five of the offers I got had a fairly consistent base, plus 10-20% bonus, but big variation on equity — not just in terms of value, but also type: from no equity to private options to public RSUs. Equity ended up being the deciding factor for me.

For me, the average time from resume submission to some kind of decision was 32 days, but the max was 93 days, and 18% took over 45 days. Most of this was just waiting a long time for the initial response, and then for the next steps to be scheduled, each of which generally took a week or two.

The average time from resume submission to some kind of response was 17 days, but the max was 70.

What Worked at Each Stage

Resume

As you can see above, this was the biggest rejection stage, by a Grand Canyon-sized margin. A full quarter of my resume submissions were rejected, but even more (39%) were ghosted, and I never heard anything about them. I put a lot of work on my resume — and it always helps for it to be short (one page, if possible, because no one has time to screen them), to include the buzz words you’re skilled with and interested in (to make it past recruiters), and to be visually attractive (you can find lots of great templates for Google Docs on Etsy, for under 5$) — but that’s not what made the difference, as I found:

It basically all hinged on referrals, which increased my chances of getting to a recruiter or hiring manager from 5% to a whopping 63%! That’s a 12x improvement, which is impossible to get any other way. I’m sure it helped that my resume looked sharp, but I’m also sure that even with my previous, plain and long-ish resume, the referral success rate would still be multiples of the cold application.

So if you’re looking for a job: tell everyone you know in the industry, and hopefully they know of an opening or know someone who does and even if they can’t vouch for you personally: if all they do is pass your resume along with a “this person might be good for this role”, that itself does wonders. Also, if you find a job posting you really like, try to find a recruiter or someone in your network from that company. If you don’t know anyone directly, look at 2nd connections on LinkedIn, and then ask your mutual connection to introduce you.

Ironically though, in spite of all of this, I ended up at one of the 3 companies in the bar graph above where I had no network connection. And for all three of those, I wrote a thoughtful message in the freespace of the application. Now, I also did that for probably at least a dozen others, so not a great success rate there, but: if you’re applying cold, it definitely helps to write the recruiter a note about why they should choose your resume out of the pile. None of my other cold applications made it out alive.

The other big category is getting recruited. Most of the ones that reached out to me were either Big Tech companies or startups I’d never heard of, and most of those were clearly automated messages. I entertained almost all of them, if for nothing other than the interview experience. And here, LinkedIn is key: using the appropriate phrasing and buzz words and highlighting the experience relevant for the kind of job you want. Recruiters use various tools to search through the hundreds of thousands of potential candidates, and a little SEO goes a long way.

Recruiter Screen

At this stage I did pretty well: 3 rejections out of 18 conversations, for a pass rate of 83%.

What the recruiter wants is to make sure you’re not going to embarass them. They’ve seen your resume and decided that based on your history and so forth, you’d probably be a good candidate. So all you really have to do is sound competent, back up your resume with your voice, and fit within the logistical parameters for compensation, location, time zone, etc.

Hiring Manager Screen

Of the 19 HM screens I was in, my pass rate was 68%, and I have to say that most of the rejections at this stage were surprising to me. I thought almost all of them went well, and in fact I had at least two of the HMs tell me they’d like to move me forward, only to get a Dear John email a few days later from the recruiter. I imagine they talked to someone they liked more the next day, but one of the more frustrating parts of the process is that rejection feedback is exceedingly rare. The unfortunate truth is that the overwhelming majority of companies do not provide feedback, largely for legal reasons.

But like the recruiter, the HM largely wants to make sure the person behind the resume is a solid candidate, that they seem personable and would fit on the team, and at least part of this conversation is them selling you on the job. They ask more poigniant questions than the recruiter obviously, and have more details around the position and what they’re looking for and have a better sense of how you’d succeed in the position, but largely this stage shouldn’t be hard, and if you don’t pass, you probably wouldn’t have fit in on the team anyway — not that you’re not qualified, but team dynamic is a real thing.

Behavioral Interview

The vast majority of leadership interviews I was in were what has become the norm the tech industry: storytelling. I can’t tell you how much PTSD I have over the phrase “tell me about a time when …”. The idea is that an experienced manager can (a) demonstrate that experience by recollecting tales from a storied career, and (b) knows to emphasize the parts that the interviewer wants them to emphasize. In the beginning of my job search, I would fail miserably at the second part with the mind-reading, because I didn’t realize there was a hidden agenda to the question.

So they would ask me to tell them about a time when I promoted someone, and I’d literally tell them about such a thing and move on. When in fact, they also wanted me to tell them about my philosophy (a.k.a framework) around promotions, and maybe even around career development in general, and emphasize how that’s an important part of a manager’s job, etc, etc. And because of that, my pass rate in the second round (where behavioral interviews would often take place) fell to 54%, and was my lowest. And that’s after I cracked the code. It helped when reviewers would nudge me in a certain direction, but that didn’t happen often, and certainly not with Big Tech, where the rubric is king.

If you’re interested in seeing examples of this tactic, watch some videos on ExponentTV (and paying for Exponent is probably a great return on investment as well) to get a better sense of the kind of answer interviewers are looking for. And make a list of stories you can cycle through quickly, on the spot. The answers are supposed to given in the STAR format. There are various lists out there, but here are some of the ones I actually got:

Tell me about a time when…

you had to manage someone out
you had to deal with a difficult employee
you had a disagreement with a peer
you promoted someone
your project was late
you failed
you dealt with a DEI issue
you motivated your team
you affected change without using authority
you were part of a large undertaking

One prevalent theme was essentially #6 above, and that was also something I wasn’t quite sure how to answer. It felt like the old joke to me, about the interviewer asking what the candidate’s greatest weakness is, who replies that he works too hard.

But the reason people ask this is twofold: first, because experience implies failure, since no one has a perfect batting average. And so the idea is that if you’re able to talk about a time you’ve failed, you’re more likely to be an experienced leader. Second, being able to talk about failure in a way that shows humility is important in that it demonstrates some good leadership qualities such as empathy, the ability to learn from mistakes, and the ability to turn things arounds.

And herein is why getting good at interviewing and storytelling is so important, because it’s not enough to merely have those qualities: you have to realize when you’re being subtly prompted to reveal them and to do so in a tactful way. But again: it’s definitely a skill that can be learned.

Technical Interview

Only 20% of my post-recruiter-screen interviews were rigorous technical ones, and I think about half of the loops had such a stage. So it’s definitely possible to get a job without running into one, but they’re very common in Big Tech.

Of my nine technical interviews, five were design questions — and one of those was a take-home exercise. Another two were presentations of a project I’d done in the past, and the last two were coding challenges.

One of the coding challenges consisted of two leetcode-type algorithmic/data structure questions. There’s nothing to be done about this except grinding on leetcode until that part of the brain that lay dormant since your CS college courses has sprung back awake. Yes, it has nothing to do with anything in a real job, but such is life.

For the presentations, I gave essentially the same one both times: passed one, failed the other.

The design questions generally ask you to design some kind of system you’ve likely dealt with before: a search engine, a messaging service, a URL shortener. Here, it’s important to start at a high level — the main components and connections — make sure you’ve covered enough there (and take hints in the form of questions from the interviewer) and then go a level lower and talk about technologies, protocols, tradeoffs, and so on. Anything to make the interviewer feel comfortable that you have the technical chops to design things. Again, Exponent has some great videos to give you an idea of what a good one looks like.

TL;DR

Interviewing processes are very broken at most companies, and as a job seeker, there’s not much you can do about it except refusing to take part in broken processes — such as live coding challenges — if you have the luxury of doing so. For many people though, especially in the new remote world of SF/NY salaries, this would mean walking away from a significant pay raise.

Otherwise, the things I wish I had known at the onset:

It will likely be a multi-month process, due to the speed at which most companies operate; I would prepare for roughly 3 months
The best thing to get your resume noticed is to make use of your network
When you do have to cold apply, writing a paragraph to the recruiter is worth the investment
A polished, short, beautiful resume is worth the investment
Optimizing your LinkedIn profile for recruiter searches is worth the investment
Feedback, about why you were rejected, is an endangered bald eagle: rare to come across and wondrous to behold
Practicing storytelling for the behavioral interview, and looking for the question behind the question, are both crucial
Practicing leetcode is needed for many interviews at Big Tech companies
Good PowerPoint skillz might come in handy
There are lots of mock interviews available to watch — both behavioral and design — and they help a lot

All of this can be boiled down to, as Patrick McKenzie put it, “becoming aware of how power operates (versus how virtue is generally described) and choosing to join it”. Like with many concepts in the tech world (microservices, cloud computing, Agile project management) this fairly narrow interview process has evolved and largely caught on, and being familiar with it is a shibboleth that’s as important as anything else in a job search, in the early-2020s tech world anyway.

My Slack Tips, 2021 edition

March 12, 2021 by Gabriel - Reading Time: 8 minutes

(There’s an updated version of this: My Slack Tips, 2023 Edition)

The Why

We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.
from “Where do These People Get Their (Unoriginal) Ideas?“

For programmers, standard Slack policy should pretty simple, flowing out of the principle of guarding “the zone” fiercely:

Turn off all notifications, except for when you’re being specifically @ mentioned
Specific mentions aside, only read Slack during your downtime — between meetings or while your VM is rebooting or whatever.
Don’t feel like you have to read everything in all the channels. Start with your favorite channels, and go as far as your downtime will let you.

The How

I’ll caveat these 11 weird tricks with the fact that this is what works for me, in my situations so far, and while your mileage will probably vary, at least some of this might be helpful. So:

Tweak the in-app Slack notifications. The default notification settings inside Slack are mostly fine: it notifies you for DMs, mentions, and keywords. But I do make a few small changes:
- I usually add a few keywords, like my name, team names, or project codenames
- I go into the notification settings of any “system down” or other emergency situation kind of channels and set them to get notified of all messages in those channels.
- In the macOS desktop Slack app specifically, in the “Notifications” section:
  - I uncheck the “Bounce Slack’s icon…” checkbox
  - If I’m in multiple workspaces, I also uncheck the “Show a badge…to indicate to activity” checkbox. Which keeps the badge icon from getting a red badge everytime someone says anything in any other workspace.
Turn off all notification types from the OS, except for the badge icon. Not inside the app, but in the Notification settings of macOS/iOS/Windows/whatever, I have the Slack app set to not be allowed to make a sound, to never pop anything up, to never bounce anything — to never do anything at all, for any reason, other than (on Apple OSes) make the badge counter appear over the app icon. That way, I can get in the zone when I need to, and won’t get distracted by Slack, but can still glance at it, once in a while, at opportune moments to make sure it doesn’t have 57 urgent messages for me.
Low barrier to enter channels. I’ll enter most channels as I come across them, because in the bad case, I don’t read them and in the worst case, I leave.
- Slackbot helpfully and periodically reminds you about channels you might wanna leave, also.
Low barrier to create channels. Whenever a topic starts getting enough airtime, or when there’s any other reason for it to have a dedicated channel, I create that channel. The more the merrier.
- You can go overboard, but as long as the reason for the channel is clear, go ahead and create it. You can always archive it later if it was a mistake.
- Channels are free and an organized Slack is a happy Slack, because it is way easier to find that important conversation about search API design if you know it happened in #dev-search.
- If you actively want to foster conversation in a channel, consider making it private. People feel safer talking in them, and the Slack stats I’ve seen bear out the fact that the large majority of messages happen in private channels or DMs.
Organize the channels in groups and make them disappear. This is a fairly new feature, I think from late 2020, but you can create channel groups in the sidebar, order the groups however you want and for each group, show all the channels or just the unread ones. You can also order the channels within the group in different ways.
- I order them by priority within each group and show just the unread ones.
- My groups are about related topics, ordered by how important they are to my role: my team’s channels and DMs in the first group, various dev channels in the second, then management channels, field support, water cooler, etc
Embrace speed reading. The human brain is great at patterns, and you can quickly pick up the importance of a conversation from some key signals like what channel it’s in, who the participants are, how long the conversation goes for, key words being repeated, emojis being used, etc.
- In some channels, like ones about nascent projects or downtimes, I read every word carefully — but that’s very much the minority.
- For the majority, I scroll through at a good speed, slowing down only when my spidey sense tells me I’m speeding through something worthwhile. It works well — false negatives are rare.
Embrace emojis. Not only do they make conversations fun, but they also convey tone (which is super important) and, as reactions to messages, they serve as pithy replies that add value to the conversation without also adding volume to it.
- e.g., using a check mark to indicate that you read something without indicating judgement, or a dart that their message was right on the money, or an up arrow as an upvote — they’re small, very helpful gestures that significantly improve the conversation.
Use reminders. When I do go into Slack, I like to at least clear all my mentions that turn channels red. But sometimes I can’t actually service a message. Maybe that’s because it’s asking a question I have to research, and I’m in the middle of something. Or I want to make sure that I follow up on a conversation after my current meeting. Or I got an action item in that meeting that I need to do tomorrow morning. I use reminders for all of that.
- Most of my reminders are set on existing messages that I need to do something about
- Some of them, I create with the /remind command
- All of them, I snooze extensively until the time is right to work on them
Don’t use threads. It’s quite possibly the worst feature in Slack. Some people love them, but don’t be those people. Terrible UX aside, all threads are is a way to hide conversations for no good reason. If you want to read every word in a channel, and you’ve read them all, but then Ethan decides to start a thread off of someone’s message 50 messages up, guess what? You’ll never even know.
- Some people use threads because they came too late upon a conversation that’s scrolled away, and want to continue it; there is a better way: share the message into the same channel, and that posts it at the bottom, with your comment attached.
- “But I don’t want to bother everyone in the channel with my thread”. The conversation either belongs in the channel, or it doesn’t. If it doesn’t, create another channel or group DM. But there’s no reason to hide it.
Nudge people toward the proper channels. Most people are trying to get their job done and aren’t so worried about keeping Slack organized, so when they start a conversation about lunch in #dev-breakfast, it’s probably because they didn’t even know #dev-lunch existed, or because they had been talking about brunch and it morphed into lunch.
- The point being that, as is generally the case, people don’t intend to break the rules and usually just make mistakes.
- I, as Slack Jedi, have to minimize the chance of mistakes by establishing good channel-naming conventions and keeping topics narrow, but when mistakes do happen, it’s not the end of the world, and an innocent mention that the lunch channel exists is normally the only thing that needs to be done.
- Be super nice and soft about it, because creating anxiety about the proper channels is kind of antithetical, since it then stifles communication.
Try to mark everything read by the end of the day. I don’t always clear my email inbox every day (or longer), but I almost always clear my channels, to give me peace of mind.
- On days filled with meetings, it’s harder, but I keep up with the @ mentions and high priority channels as I can, and then quickly scroll through the less important ones, just to make sure I’m not missing anything important.
- Yes, the Slack FOMO is strong with me, but the clearing doesn’t take long. I’m in dozens if not hundreds of channels, in a Slack with hundreds of people and — active conversations aside — I can clear a day’s worth of chatter in about a half hour, knowing then that I’m on top of things and won’t be surprised the next morning by Fiona with a “so what are we gonna do about that nasty database locking issue?”

So that’s how I stopped worrying and learned to love the Slack: by putting it in its corner and giving it attention on my terms — no more and no less attention than is beneficial.

Two More Annoying iOS 11 Bugs

December 23, 2017 by Gabriel - Reading Time: 3 minutes

So far, iOS 11 is maybe the buggiest release Apple has put out: it’s had eight updates to fix a bunch of issues, like the infamous A ⍰ bug, and while you’d think they’d have ironed most serious things out by now (11.2.1), I ran into two more, and verified them with Apple support on the phone.

I’m posting them here because I scoured the Internet for answers on them and got nowhere, which is why I resorted talking to Apple on the actual phone, and hopefully this will help you avoid doing the same thing. I’ll also update this post if and when they get fixed.

Bug the First: Edit and Share buttons are grayed out on some photos

This one is straightforward and super annoying and mind boggling: I can’t edit or share some small minority of photos. There seems to be no rhyme or reason as to which photos. The guy I talked to Apple couldn’t find the issue in their database, even though there’s at least one thread on it on discussions.apple.com (though it’s been erroneously closed).

Workaround: import the photo into an app that’ll let you re-save it. I used Camera+.

Bug the Second: On the first iCloud backup, you can’t choose what to (not) back up

Let’s say you have 5GB of Photos and you wanna do an iCloud backup of just the phone settings, because the photos are backed up already in some other way, and you got a new phone that you want to transfer your settings to. The settings themselves should be around 200MB.

Assuming you haven’t wasted money on iCloud and your limit is still 5GB, even if you have nothing in iCloud, when you turn on Backup it tells you there’s not enough space in iCloud, because it’s trying to upload your photos also.

Image result for ios 11 this iphone cannot be backed up because there is not enough icloud storage available

That’s it: you’re stuck. There is no way to get past this without buying more iCloud space.

In previous versions of iOS, you could switch off Photos, for instance, as well as iMessage and everything else, so you didn’t end up uploading the entire phone’s contents to the cloud. And you can still do this, on a backup-by-backup basis, but only — and this is the maddening part — if you already have a backup in iCloud.

Otherwise, there’s no way to control what goes up there or even see what the Next Backup Size will be.

Choosing what to back up was so easy in iOS 10, and I was so incredulous that it wasn’t in iOS 11, that I went to the Apple Store so they could show me what pathway I was missing. After that went nowhere, I brought it up with the guy on the phone, and he confirmed this is how things are now.

There’s a StackExchange question out about this, but the problem seems to be too nuanced to have made it onto Apple’s radar.

Workaround: use an iTunes backup to restore the settings onto the new phone.

I’ll update this post if and when these things get fixed.

Home Theater Setup 2016

January 18, 2017 by Gabriel - Reading Time: 10 minutes

I love big screens and I cannot lie. My first major purchase after I got my first professional job was a projector. My first major purchase after I got my first house was a new projector. And I got an even newer projector late in 2015. With it came a refresh of the whole setup.

This is now my third projection system, and after a lot of research, I feel like it’s the first that’s actually set up really well. The first projector wasn’t 1080p and I didn’t even have as much of a screen as a really uniform white wall, so… not a great setup. The second generation was a big improvement, but I didn’t do any calculations and so some people thought the screen was too big to watch from the couch. Either due to finally applying the maths, or because the third time’s a charm, this version 3.0 is very much on point, and so this post lays out what I did in excruciating detail, because good documentation is the cornerstone of process improvement.

TL;DR: I put an Epson PowerLite Home Cinema 5030UB on an OmniMount wall shelf 11′ away from a 110″ Elite Screens SK110XHW-E24. There’s VIZIO S5451w-C2 soundbar behind the screen, a Monoprice 40′ active HDMI cable going through the ceiling from an outlet to the soundbar, and another from the soundbar to the projector. Into the outlet, I usually plug in an AppleTV 4, but sometimes I plug in my PC. And because the soundbar is behind the screen, there’s a BAFX IR Repeater with the IR receiver on the screen housing, and the emitter behind it.

Total equipment cost in 2016 dollars: 3250$

Absolutely _not_ my home theater system

The Screen

I had to start with the screen because the projector needed to go into a family room attached to an open kitchen, which limited me to two walls of roughly the same size. The room itself is 11′ square, but in the direction that goes into the kitchen, the projector can go back as far as my wife would let me, which was about 15′, so that “it’s not actually in the kitchen, you know?”.

However, the bigger concern was brightness. The room is not very well light-controlled, and I need to be able to watch certain things — like football games — in the daytime. (The further back a projector is, the less bright it will be on the screen). We also have a TV facing out toward the kitchen, so putting the projector on the other wall would limit me to 11′ projection distance, but allow me to have both TV and projector running at the same time, as opposed to the screen covering the TV when it’s down. And you know what that means: simultaneous viewing of both NBC and CBS election coverage this past year. Oooooh yeah.

With the wall picked out, I calculated the screen size to buy: 11′ is 132″, and THX recommends screen sizes be 0.84 of the viewing distance, which works out to 110″ screen. (If you subtract the length of the projector itself, it works out more to like 100″, but I like screens being a bit on “bigly” side.)

For vertical placement there are two general guidelines:

A rule of thumb that the bottom third of the screen should be below the viewer’s eyes, which are generally at 38″ for a seated adult
That the top of the screen should be no more than 15 degrees above the viewer

For a 110″ screen, which has a height of 54″, the one-third that’s supposed to be below the viewer’s eyes is 18″. That leaves 36″ above the viewer’s eyes, and at an 11′ viewing distance, the top of that screen would be 15.3 degrees above the viewer, so that works out perfectly.

Screens generally have a 2″ black border all around, so that makes the entire screen 58″ tall, and brings the one-third that’s below the eyes to 20″. If the eyes are at 38″, that means the screen’s bottom edge is 18″ off the floor, and the top edge is 76″ off the floor. Unfortunately for me, there was a 96″ tall door frame on part of that wall, so I had to get a screen that had an additional 24″ of black border at the top, so I could essentially hang the housing up that much higher than where the actual white part of the screen needed to be.

With that added requirement, basically the only option I had was the the Elite Screens SK110XHW-E24 for 460$, which was a 110″ screen with 1.1 gain and 24″ drop. I’m not sure if I’d know a bad screen if I saw one, aside from obvious flaws, but I definitely don’t mind this one, and it goes up and down like a champ.

The Projector

Once I had the screen picked out, I started looking at the projectors rated highly on projectorcentral.com. Three stood out:

Sony VPL-HW40ES – 2500$, editor’s choice for 2014
- According to its calculator, for a 110″ screen with gain of 1.1, placing it at 16′ away would mean using a 1.07x zoom and the image brightness would be 20fL; 13’9″ for 22fL, 11’10” for 24fL
Panasonic PT-AE8000 – 1850$, editor’s choice for 2015
- According to its calculator, for a 110″ screen with gain of 1.1, placing it at 14’10” away would mean using a 1.47x zoom and the image brightness would be 20fL; 13’9″ for 22fL, 13’1″ for 24fL
Epson PowerLite Home Cinema 5030UB – 2300$, editor’s choice for 2013
1. According to its calculator, for a 110″ screen with gain of 1.1, placing it at 16’4″ away would mean using a 1.41x zoom and the image brightness would be 20fL; 15′ for 22fL, 13’9″ for 24fL

After some internal debate, as you may have read above, I went with the Epson, for a few reasons:

I liked the previous Epson PowerLite Home Cinema 6100 I had
It had the most reviews of any of these on Amazon (139 reviews, 4.5 stars)
Great zoom and brightness

I also looked at the 5030UBe, which has the interesting wireless HDMI feature, but apparently it has connectivity issues, especially with gaming, so it’s not worth the extra price tag if you can’t reliably use it.

The Speakers

One of the great problems with front projection systems — if not the greatest — is sound. The virtually universal advice is that you need to get a good receiver, run all sound through that, and just run an HDMI output from the receiver to the projector.

Well, I’m a minimalist, I only have two inputs for the big screen (Apple TV and my PC), I’m not an audiophile by any means (stock TV speakers sound great to me) and on a philosophical note, I absolutely will not buy yet another gadget to make up for the fact that projector manufacturers just can’t seem to bring themselves to make simple Audio Out ports be a thing on their devices.

Throw in the annoyance of running speaker wire, and when I saw a well-reviewed Vizio soundbar on sale, and it had wireless speakers, I bought it. It’s the 2014 model, so it was old when I got it, and not even available new anymore. But, I love it.

At first, in an effort to avoid a run of cabling, I tried to have HDMI only go to the projector and to get the audio to the soundbar via Bluetooth from my AppleTV and my PC. But while music worked fine, video absolutely did not: the last syllable to many words would get dropped out, and it was just unwatchable. So I regrouped and ran HDMI to the soundbar and then another HDMI cable from the soundbar to the projector. The soundbar picks off the audio and sends the video to the projector, which means I just have two HDMI cables running through the walls and ceiling and it works beautifully.

The subwoofer is wireless and hangs out hidden away in the TV stand. Two wires come out of the back of the stand and go behind the couch and up to the rear speakers.

The Accessories

HDMI

For the first leg, from outlet to soundbar, I needed a 40′ cable, which meant I needed an active one, that deals with attenuation over that long of a haul. Monoprice is where I usually get cables, and this was no exception: they have 40′ active HDMI cables for 35$ and after one year, I have zero complaints. But do note that they are unidirectional: you have to have the right end in the soundbar or projector. I got two of these, one for each leg.

Now, a word about installation: for my second generation system, I waited for a cool November day, ran the cables in the ceiling myself, and I have the scars to prove it. Literally: I sliced my knee on an exposed bracket in the attic to what seemed like the bone, and had to superglue it shut (to avoid going to the ER and having them do the same). For this third generation, I was going to repeat history. Then I realized that due to the position of the soundbar in the house, I couldn’t even figure out how to physically get a cable there, much less how to stay conscious for that long in the Florida heat, that in an attic, approaches Venus conditions. So I hired a professional home theater outfit and both cringed and thanked the seven gods while seeing what they went through. Worth every penny.

Infrared

Second, in an effort to make things look nice, I mounted the soundbar behind the screen. I already had to mount the screen housing about a foot off the wall, so that the screen would drop over a set of drapes, so I had clearance back there. And really, I had nowhere else to put the thing. To my great dismay though, on testing, I found out that with the screen down, the infrared from the soundbar remote control would only work if I walked over and pointed it behind the screen and up to the soundbar. Which really sucks to do when you’re trying to enjoy a movie but it gets loud enough to wake the baby — and the baby is literally the last person you want waking up when you’re trying to enjoy a movie.

To get around this, I bought a BAFX IR repeater for 28$. You stick a small IR receiver on the projector screen housing, plug that into a box that’s mounted and hidden behind the housing, and then plug in an IR emitter that points to the soundbar. Boom! You’re now a light bender.

This particular gadget is a little overkill for this purpose because it could control up to 8 devices and I just needed one, but I couldn’t find anything good for less money anyway.

The repeater is _not_ pretty

Future Improvements

So that’s it for now: pretty simple setup, great results, mostly thanks to the calculations and planning. But nothing’s ever perfect, so while I’m happy with version 3.0 of the Jiva Projection System, I’m definitely planning on upgrading to 3.1 and 3.2 when I “get the time”.

First, I’d really like to actually mount the rear speakers up on the wall someday. Right now, they’re just on the floor behind the couch. Honestly, this is because (again, I’m the opposite of an audiophile) I find them more distracting than anything. Whenever I hear a distinct “rear” sound, I don’t think “oh wow, how realistic”, but more “WTF was that noise?!”. Which means that a lot of the time, surround sound is just off. But, maybe it’s like beer and I just have to acquire a taste for it so I can hang with the cool kids.

Second, I really need to put a power outlet behind the projector. There’s an HDMI outlet there that the nice home theater people put in, but they weren’t licensed enough to run power behind the wall. So now there’s this power cord that just runs down the wall, that a toddler can and would definitely like to tug on. And yeah, I could just drill two holes in the drywall and run the power cable behind it, but that’s not up to fire code, and insurance is a bitch. So I’m currently trying to either work up to running high voltage wire myself, or getting an electrician to do it. And I really don’t want to do the latter, because while delegating is par for the course at work, actually doing stuff is what makes me wake up in the morning.

Third, I probably should get a fancy Harmony remote, because between the projector, soundbar, TV, cable box, Apple TV and homemade DVR, we literally have half a dozen remotes. But, 95% of the time, the Apple TV remote is the only one we use. And I just can’t bring myself to spend 150$ or more on something that’ll get used once a week and only very marginally improve my life. But, I’m keeping it on the backburner as a birthday wishlist item, for when I become the man who has everything, so that I don’t wake up to find myself entombed alive in a cemetery in Mexico.