The broken engineering interview process

Imagine yourself in an interview, sitting in front of 5-10 others of your field. Midway through, the group’s questions drift from the personal and work experiential to the assessing and cross-examining.  They ask you to step up to The Whiteboard, marker in hand, and prove what you know.  Never mind that you’re not fresh out of college and that you haven’t taken a formal test in some time. Gone are the days when a good professional portfolio and list of references, along with a teamwork-minded personality, can get you a job.

These days in the engineering industry, you have to take an impromptu public test to prove your aptitude. I think this interview process is faddish at best and broken at worst.

I had my first whiteboard interview at InVue a few years back. It was ridiculous and a bit demeaning. I failed miserably which hurt my ego for some time afterward. As someone who suffers from impostor syndrome, it wasn’t a good experience.  Did they not like me? They must have thought they wasted their money and time on me!

But the longer I work in the world of engineering, and the more confident I become in my capabilities, the more ludicrous I see the whiteboard interview. First, designing on one’s feet, in front of a room of one’s peers, is not how engineering is done.  It’s not how it’s ever been done. I’ll go one further: this model of engineering isn’t even good engineering.

Engineering is by definition of process of refinement. A design begins on a proverbial napkin, which moves to paper and screen, and finally to copper etched on fiberglass, or lines of code compiled to chip. These stages are meticulously reviewed by groups of other engineers over months, sometimes years… never in the course of an afternoon in front of a single whiteboard by a single candidate.

Put it another way: if a whiteboard interview ever produced a product in the real world, I’d never ever buy it. It would likely burst into flames and kill its user. Perhaps the notorious Note 7 debacle borrowed just such a design cycle?

And in time, I learned that I wasn’t alone in my disdain for this method of interviewing. There’s a great trend on Twitter where programmers are getting honest about their inadequacies in order to protest this style. I love every single one of them. They each, in their own way, help shatter the unrealistic glass conference room doors that are modern engineering interviews. They reveal themselves to be real designers, not necessarily gifted in quick, improvisational thinking.

So in their spirit, here’s my own tweet, the full story you can read here.

Ukrainian Outsourcing

I had the most bizarre confrontation last year in my gym locker room — a place that is supposed to be a bastion of privacy, comfort, sometimes camaraderie — from which I haven’t really recovered.

Charles is a jovial sort of guy.  He’s in his mid to late 50s.  He’s gregarious and extroverted, often seeking out quiet-type guys to chat up. I don’t doubt his sincerity and desire to connect with other men; in fact, it’s a quality of which I’m somewhat jealous, simply because it doesn’t come naturally to me.

This one fateful day, early on in Trump’s ascension up the Republican primary ladder, Charles zeroed in on me.  I was his next “project guy” and he was intent on getting to know me. He introduced himself, but I already knew his name from his many other encounters with similarly quiet-type dudes. I’ll be honest: I was dreading this day. The potential intersection of introverts with extroverts can leave the former with anxiety and the latter with anticipation. He had a bull’s-eye on me, while my eyes were firmly in my locker.

But he would not be denied. He invaded my personal space with determination, so I did my best to be cordial. He asked what I did, as most of these conversations start. I returned the question, and that’s when it all went surprisingly south.

Charles, it turns out, is the owner of an engineering company, specializing in cloud-based video streaming. Cool, I thought. This would be a great chance at professional networking, which can be difficult as an introvert. I asked him if his operation is headquartered locally, or if his engineers telecommute. The latter, he says… from Ukraine.

I think my reaction was mostly bewilderment. Fair enough, he outsources his tech labor. A lot of companies do. But it was his almost unapologetic reply that disturbed me. “Americans are just too much work, man!” he implored. He’s a “man” and “bro” type gym extrovert. Every guy is his brother at the gym, where the handshake is substituted with a fraternal knuckles punch.

But I’m an American. And I’m an engineer. I’m an American engineer, and I’m too much work for this employer. I couldn’t feel much more insecure.

He went on to explain that US software engineers basically are too expensive and that the Ukrainians don’t complain as much. A cheaper workforce is basically more grateful.

I countered to Charles that if I worked for him hypothetically, regardless of my talent and reciprocating cordiality, he’d fire me within minutes of showing up to work. Because I’m too expensive.

Charles just looked at me with his bootstrap intensity, a matter-of-fact pursed lip, and said nothing.

I was left with a bit of existential shock, realizing that some corners of the tech world were anything but “safe” for job security. I suppose this can never be the case when there exists regions with extremely cheap labor for sale.

That said, I can only hope that one day the Ukraine experiences its own middle-class resurgence. How does that happen? When it’s local industry exports its goods and not its people.

Until then, Charles and I won’t see eye to eye.

Mishandling errors

For the past 3 years, I’ve been working full-time as a software engineer.  This has been a substantial, if not calculated, change for me.  I’d been an hardware engineer for longer than I care to think about.

Perhaps the biggest, while subtlest difference between the two career paths that I didn’t see coming is this: determinism.  I simply love the relative absolute nature of software.  I’m sure some might argue me on that one.  But, you get my point.  For the most, the outputs of any software project can be clearly predicted; the inputs can be nicely quantized, packaged, and displayed in automated fashions.

I love going to work.

Even on the tedious days of making error handling code, it’s still all fun.  Exception handling is one of those topics that is grossly underestimated.  It’s hard work, it’s time-consuming (and no one appreciates that investment), and it’s rewards are always deferred.

I’m reminded of all of those points when I witness — virtually everywhere in “real life” —  examples of horrendous error handling.

Case in point

While attempting to post a mobile deposit to my bank account, I got an error.  The transaction didn’t post, for whatever reason.  This was on my Android phone, from which I’ve made dozens of successful deposits in the past to the same bank with the same app.

Fair enough, errors happen.

But the error message I was greeted with was the following:

Not much help there, huh?

The point of error handling is twofold:

  1. Assist the user in resolving the problem
  2. Provide the developer with the conditions prior to the error from which to find a solution to the problem

From the above screenshot, there’s next to nothing for the bank’s engineering team to go on.  The tech support tips I got amounted to, “Have you tried uninstalling?”

It’s no wonder that most people’s relationship with software is terrible.  And I’m a software engineer (now)!

From iOS to Android, part 2: ecosystem shock

Last time, I talked about two key aspects of technology that tend to make loyal customers: platform ecosystem and user experience.

It was a natural transition from owning Macs for the better part of a decade to iPods and then finally iPhones.  Apple has done well to keep the user experience very fairly consistent between all the platforms.  That is probably their single greatest contribution to the technology world: coherent ecosystem.  In other words, the way you work on a Mac tends to be naturally the way you would work on an iPhone.  And that’s a good feature.  It makes for loyal customers.

So why, then, did I jump ship?

Continue reading “From iOS to Android, part 2: ecosystem shock”

online IDEs

I love IDEOne.  It’s a fully debuggable online compiler for a bunch of software languages.  And there’s no need installing a plugin to format source code correctly on my blog, when this service offers embeddable links.  Like this:

By the way, this isn’t compiling. Anyone have any pointers? See what I did there? Pointers?

The collision of Boxes

I’m a big fan of Dropbox.  I (and the rest of the internet) have been using it in free mode for quite some time.  I probably don’t need to tell you what it is 1.  What I particularly love about the cloud is that it kills two birds with one stone:

  1. Syncing your files painlessly between all your devices (computers, phones, tablets)
  2. In the process, giving you easy backup (by way of mirroring your data across multiple personal devices, as well as in the cloud)

And as the cloud storage market gets more crowded (Box.com, Microsoft’s OneDrive, Google’s Drive, Apple’s iCloud, etc.), the race to $0 makes for a pro-consumer landscape.

Continue reading “The collision of Boxes”

Bearable wearable

I’ve always loved following tech. The emergence of the wearables market has been a fascinating one: a convergence of small form factor, low power, and high performance electronics.  In particular, this market really couldn’t have happened without the smartphone industry blazing the trail, since wearables leverage multiple technologies like touch screens, accelerometers, compasses, and wireless interfaces.

And yet, I’ve been pretty reluctant to actually buy a wearable.  I’m a late adopter.  I’m also fairly inundated with enough tech already.  So having another device to sync, charge, socially link, and generally pay attention to, wasn’t a prospect I was eager to jump into.

Along comes Fitbit 1.  As cool as this thing is, I can’t take credit for becoming a user.  It was thrust onto me.  Forsooth, it was a gift.  But such a good one!

For all the other tardy adopters out there, allow me to fill you in: Fitbit is basically a pedometer.  A really fancy one.  It’s also a watch, a silent alarm, and a general purpose fitness tracker.  In fact, they call the watch-like wearable a “tracker.”

So what about this specific product made me change my mind about the market in general?

Form factor

I like that the Fitbit line of products are smaller than the smart watches.  I like its sleekness and space-aged contour.

Competition

The Fitbit works really well since it is a social device.  You can view your friends’ progress, which naturally engenders competition.

Meaningful Metrics

Take a look at the kind of data you can glean from it:

Fitbit dashboard
Fitbit dashboard

For people like me that like to quantize as much of their lives as possible, this device is very addicting!  In particular, the sleep efficiency data is worth the price tag alone.  I’ve had sleep issues in the past, and seeing my slumber numbers in vivid detail somehow helps me cope.

Silent Alarm

Dovetailing with the above, someone like me whose sleep hygiene isn’t the best can have difficult time rousing to an alarm.  But traditional alarms, being by nature audible, have collateral consequences to our partners in bed.  My wife has had very early and tandem wakeup times, since I get up quite early for work.

But no more!  The Fitbit has a vibration motor in its tiny little body.  And affixed to my wrist is the ideal place to wake me from deep sleep.  It’s almost uncanny how transformative this has been to both my waking problems and her sleep quality in the mornings.

In fact, I’m so excited about its alarm feature, I’m half tempted to pull the trigger on this sleep experiment: Polyphasic cycles.  Well, one thing at a time.  First, 10,000 steps per day, then sleep hacking.