In (weak) Defense of Algorithmic Tech Interviews

Yesterday, I wrote about my preference for work simulation tech interviews. There was one place I worked where we did more algorithmic tech interviews. Here’s why

We were hiring almost exclusively people that had just graduated from a CS program. They were actually pretty good at these kinds of questions and didn’t really know much else we could ask them.
The company made an image processing toolkit. There was a lot of data-structure and algorithmic code. There were a lot of optimization tasks. You really did need to know big-O for your code because all images had millions of pixels.
All of our code was in C# and basically no one knew that already. So we hired people that could program in any language and needed questions that worked for anything.

So, the questions I asked were not too far removed from the kinds of problems we did need to solve, but they were technically algorithm/data-structure questions. At that job, with that codebase and with the strategy to hire new CS grads, I would do the same thing.

How to do a Work Simulation Tech Interview

I have written about how tech interviews are too much like auditions.

If you want to be in an orchestra, you need to audition. That makes sense because an audition is close to what the job actually is—a performance. This also makes sense for actors, comedians, dancers, etc.
A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

But, I do think there is value in seeing a candidate actually do the job you are hiring them to do, so what I have tried to do is to simulate work as much as possible.

Here is what I recommend:

Describe it as pair programming. Unlike performances, this is something programmers actually do. Tell them that they are driving, and that you will be a helpful pair. This means that if you correct something, that that isn’t bad—it’s expected. You should correct things you don’t care about (and let them find the things that you do care about). Set up an expectation that mistakes are are ok.
Start with working code, not a blank slate. Send them a small working project that is like your actual code. For me, that was a working iOS app with one screen (all code was in one file). Run the code and show them what it does. If you don’t require a specific language/framework, then this is harder, but perhaps you could prepare more than one. We had both Objective-C and Swift versions of the interview app when Swift was still new.
Tell them what to expect beforehand. Before the interview, tell them exactly what the interview is going to be. “I will send you a project that does XXX using (language, framework, etc), you need XXX to run it, and then we’re going to add small features and do other things to it.”
Ask a question that makes them read the code. The first question should be to do something extremely easy with the code that makes them have to read a good portion of it.
Set an expectation that the code they write is a first draft, not production. Tell the candidate that this is “interview code”, not real production code, and we don’t have time to do everything that they would do. But, ask them to tell you what they would do if they had more time. If you want to see them do it (i.e. it’s part of the interview), ask them to do it—otherwise, consider it done.
Answer any question that they would normally google. Tell them that you don’t expect them to have memorized everything, so if they would normally google something, to just ask you and you will tell them. This is just to speed things up.
Remember that coding is one-dimension of the candidate. Being able to code is important, but it’s not the only thing that will determine success at the job. Pay close attention to collaboration and preparation (since you told them what to expect) and other aspects you find important.
Don’t treat the coding interview as a gate. If you give a coding interview first and immediately reject people, then you are going to miss out on a lot of good candidates. Make the goal to rate them on a few dimensions and pass them if they could do the job. Then, later in the process, compare the candidates on all dimensions of the job that you tested.

The goal of the technical interview is to find out if the person can do the coding aspects of the job. So, to the extent that you are doing what the job requires, the better the interview is at answering that question.

So many choices, Part 2

Yesterday, I lamented that web development hadn’t come to any consensus on tooling. programming language, basic UI framework or anything else.

I was talking about front-end development, but it’s true on the back-end as well.

Here, I’m not so sure if we could ever get consensus. On the front-end everyone is running in a browser and ultimately has to provide HTML, CSS, and Javascript. I was hoping that would have driven the industry towards one obvious choice.

On the back-end, everyone has been using their tool of choice for decades, and using Javascript (via node) is a good choice now, but it’s not close to universal. And if you are only working on the backend there isn’t a requirement to know Javascript at all, so there are lots of teams that don’t care about matching languages.

For me, using one language on both the front-end and back-end is such a compelling benefit, that I’ve moved to node for anything new. In practice, I haven’t had much code sharing, but I am flipping back and forth so much while developing, that just having to have one language in my brain is reason enough.

And since I use GraphQL, again Apollo is an obvious choice.

Before this, I was using Django and Python for my backends, and I like working with an ORM for SQL data, so I decided on TypeORM. Here there seemed to be 1 or 2 other viable options as well. TypeORM can be DB engine agnostic (depending on what you use), so setting up an in-memory, sqlite version for unit testing is pretty easy.

With Apollo and TypeORM, TypeGraphQL is a nice addition. It lets me have a DSL that describes entities in one place that generates my DDL, queries and also encodes them for GQL/Apollo automatically. If you don’t do this, a lot of your GQL code isn’t going to be type-checked.

My backend is essentially just a DB with GQL in front of it right now, so there isn’t much else to decide. Since I use the same language as my front-end, I can use eslint, prettier, and jest here as well.

The one thing I miss from Django is the automatic admin console and user management. In the end, I do think my admin interface needs to be more custom, but it’s useful at the start until you get around to making a real one. I looked at AdminJS, but unfortunately I had already committed to some TypeORM choices that it couldn’t support. If I thought I’d be on AdminJS long-term, I might have backed out of those choices.

In any case, the choices on the back-end mostly depend on what language you choose. As an iOS developer, I never really had the option of using one language for the full stack—I usually want to make native apps and Swift isn’t ready for the server-side in my view. It’s nice to have this option, and would make me reconsider ReactNative if I need a mobile app for this project.

So many choices

Up until about March this year, I was primarily an iOS developer and had been for a while. But, this year I decided that the things I want to build would be best built on the web, and so I started to learn modern web development. I was struck by the lack of consensus about what that means.

My goal is to build a real web app, not just to learn. I already know HTML/CSS/JS going into this. If your goal is to get started or just to learn, I’d start with HTML/CSS/JS and maybe React or Vue and not worry too much about the rest yet.

Right now, I’d say, if you want to be an iOS developer, you download Xcode, write in Swift, use UIKit for the UI and standard components and libraries and you can build professional apps. There’s built-in support for most things that you need, and the Apple implementations are excellent. All of the apps I have worked on are not much more than this.

On the web, I’d say the one consensus choice is to use VSCode, but then it starts bifurcating quickly after that.

The default language of the web is Javascript, but you can use anything that transpiles to it. I have decided on Typescript, but I think Clojurescript is a reasonable choice. There are probably a few others.

At this point, you basically have nothing. The browser provides an HTML renderer, very basic components, and a limited library. You are going to need to add dependencies to do anything beyond the basics (you had to do this even to get Typescript).

The first choice I had to make was what UI framework to use. I chose React, but people I trust also use Vue. There are few others that seem reasonable, but React seemed a good fit for me. By the way, if you want to get started with React, I recommend Pure React, which is a book explains React in isolation.

It might be overkill, but I decided to use Redux to manage state. React has something built in now, but I like things that have been around a while.

I also needed a design system — something with ready-made components. I didn’t find anything that great, but chose Material-UI in the end as it seemed the best supported.

I wanted to like Microsoft’s Fluid, but I couldn’t get it to look right for me. I also could not get Ant to work at all (I’m a newb at this). Every big company seems to promote one of these — my old employer, Atlassian, has ADG, which looks ok. SalesForce has one too. But, they all seem to have a different idea about what a reasonable amount of markup is for default usage. Material-UI is usually a simple tag with a few attributes to get something on the screen — these other systems are way more complex. There is also a vibrant commercial market for components. I will probably revisit this after my MVP is done.

I decided on GraphQL as my API basis, and so I got another easy choice: Apollo. I also added GraphQL codegen because it can turn GQL into a Typescript API (with typechecking).

It doesn’t stop there. I have eslint, prettier, and jest as my code quality tools. I think those are default choices, but there were others. In iOS, code formatting and unit testing are built in.

And this is all just to get something minimal working. I have also had to add in some other components for specific features.

I have also checked in with people in my network that do this for a living, and I haven’t found two that have made the same choices. Except for VSCode — that does seem universal.

Tomorrow, I’ll talk about the backend, but there is no comparison with iOS, since you’d have to decide on this as well for a server backed app.

Socially acceptable cameras in AR

At some point, there’s going to be an AR device that looks exactly like glasses. I also hope that they don’t have cameras. If they have a camera, then they also need an indicator that it’s on. Walking around, for example, NYC with people wearing the glasses equivalent of 2000’s style iPod white earbuds is probably creepy. There’s no way around it if they also have lights and cameras.

But AR needs reality to augment, and a lot of reality is percieved visually. So, without a camera, these glasses will be a lot less useful. If we look at Apple’s AR features as a guide to how it feels about cameras, you can see that they are pro-camera. At WWDC 2021, they demoed a feature where you can orient yourself in a city by pointing your camera at the surrounding buildings. This would be very useful in a heads up display.

So, we will probably have the front-end of a camera to take in visual information. But, AR could still be very useful without ever producing a visual from the hardware.

One obvious (and currently available) representation is a depth map. Apple is testing out LIDAR on iPads and use a depth sensor on iPhones for face detection. The representation is a mesh, not an image, so it might be acceptable and is useful for a lot of AR.

Another thing they could do is pre-process the video feed into a given set of layers in a neural network. The first few layers in an image processor usually do some down-sampling and feature extraction. I’m not an expert, but if these things cannot be reversed back into the original image, they might be acceptable. In current feature detectors, you can retrieve some bits of images (see this), so there’s some work to do. But even if this is ok, it’s a big public education project to get it to be socially acceptable.

But Apple has shown some willingness to talk about its privacy protecting “provably cryptographically safe” technologies and open them up to third-parties for verification, so maybe they’d be willing to go this route to get a “camera” into their AR glasses.

Apple Fall 2021 Event Wishlist

I’ve done a bunch of WWDC wishlists (e.g. 2021, 2020, 2019), but I haven’t done one for the main hardware event, which is this Tuesday.

I’m sure that the iPhone, Apple Watch, and maybe even the iPad (or Macs) will get nice improvements, but I can’t think of anything more I’d want. I am on the iPhone upgrade program, so I’ll end up with a new phone regardless. And the trade-in value on watches usually makes updating a reasonable option.

So, the main thing I’d hope for is something in AR. I’ve written about how I think AR could make apps more like games, and I do think that there’s space for a workout AR device. I would love to extend Sprint-o-Mat to make it feel like you’re in a race against the pace-runner. It would also be a good addition to Fitness+, which could extend to outdoor activities.

It feels inevitable that there will be something in AR eventually from Apple. I think one social issue is what to do about cameras on AR devices, which I will address tomorrow.

A Tale of Two Restarts

I injured my hamstring right before I was set to run a marathon this past June. I went to a few physical therapy sessions to see if I could do anything to salvage my training, but ultimately I decided to not do the marathon and greatly reduced my running volume so that I could heal.

And then I just stopped altogether.

I was traveling and my hamstring wasn’t getting better, and I just wanted to not think about it for a few weeks.

At the same time, I also stopped writing and podcasting.

By the time I got back, my hamstring felt great. I had lost a bit of fitness, and July in Florida is no time to train or run marathons, but I did settle back into my normal summer training regimen. I had restarted immediately without really trying that hard.

I did not restart writing. What was the difference?

For one, I’ve been running for a very long time, and I have gotten a lot out of it. I generally believe my health depends on me doing it. And, in the past three years, I have been doing it very consistently. Every run I do now seems to pay off immediately in self-esteem, weight maintenance, and feelings of fitness.

Although I’ve been writing over the same period, I have only gotten very consistent six months ago. And, although I have had successes, the benefits of continuing are not as clear. I have data that shows I am slimmer, faster, and more efficient. I don’t have anything like that for writing.

And, I legitimately hurt myself running in a way that rest would help. It was not an excuse. The work I needed to do was to rest. Perhaps that was the same with writing—maybe I needed a rest. That does feel like more of an excuse to me though.

I also have an app that I care about that can only be used if I run. My programmer identity forces me to run in order to program.

But, probably more importantly, I belong to a running group with a coach. It’s harder not to run than to run. There is some accountability there, but that’s not what helped me restart—it was my coach making a specific plan to restart that helped. She had been in my position many times and could help me through it.

So, what could I do to make sure I keep writing? I think two things are clear

Get a coach.
Have some kind of feedback mechanism.

My main issue is that I don’t really have a goal beyond just doing it to do it. I thought that would be enough, but I think I could use a little more.

I choose not to quit

THOSE WHO WOULD MAKE ART might well begin by reflecting on the fate of those who preceded them: most who began, quit.
– Bayles, David; Orland, Ted. Art & Fear [amazon affiliate link]

I began this year with the intention of writing here everyday and for 6 months or so, I found it easy.

And then, life got in the way.

In my case, it’s not bad news. I took some time off to travel in the COVID dip in June/July and got to see family and friends that I hadn’t seen in a year or more. And, I started getting interesting projects with deadlines and expectations. I don’t think it should have totally derailed me, but it did.

But, I’ve come back to some kind of equilibrium now. Or maybe it’s just the normal ebbs and flows of energy. I pride myself on having discipline and not needing motivation, but that only works most of the time. Not all of the time.

In any case, I choose not to quit.

Aim a Little Higher in your Whitepapers

I recently handed over my email to get a “whitepaper” that looked interesting from a company that had been recommended more than once as having an interesting product. I was kind of shocked at how shallow it was.

It was not just a crummy commercial — I think I would have preferred that though. I don’t mind being sold to if it’s done well.

I remember writing these kinds of things for Atalasoft, and it’s tough. I found one of my old ones that tried to teach imaging to prospective customers.

There are things in there that are simple, but my intent was to make the reader into a somewhat advanced user of imaging products with a deeper understanding. It’s kind of implied that our product could help them do these things, but they were free to try to do it themselves or use our competitors. I was betting that they’d give us a shot and we’d win on the merits.

I knew from talking to customers that these things were not obvious and not knowing them was making their use of our product limited. We could help them more, but they didn’t know what to ask for. The whitepaper was written to get leads, but I sent it to customers too when it was obvious it would help them.

As a test, put the first few pages up for free and see if you still get emails for the rest.

Outcome Story Templates

In yesterday’s post about Outcome Stories, I don’t think I quite got the story right.

I suggested changing the story from “As a writer, I want to publish posts, so I can share it with readers.” to “To get readers, a post must first be published.” I do think this does put more emphasis on the goal because it’s the first few words of the story.

But, it would be better if it were the subject of the sentence. The subject is what we’re talking about, and in my fix, we’re talking about the post, not the outcome.

So, tweaking it more, you could say “Getting readers requires that the post is published.” Maybe this is semantics. The more important thing is that the goal is early in the sentence, but if it can also be the subject, it will carry more weight.

But, if we go down this route, maybe we can develop a template around it

[Outcome] requires [the object] to [have a state]
[Outcome] requires [the persona] to [do an action] to [an object]
[Outcome] requires [the persona] to [do an action] to [an object] when [a trigger happens]

So, we end up with: “Getting readers requires the author to publish the post when they are done writing it.”

And again we’re clear that this is necessary, but not sufficient to accomplish the goal.