Author: Tyler Peterson

Web Developer and a hiring manager at an established technology company on Utah's Silicon Slopes in Lehi.

Spot a Poorly Fitting Job

I recommend this quick read: 5 Signs it’s Time to Quit Your Job

Not a bad list. The quick version is to worry over

  1. a no-win environment
  2. no desire to think about work
  3. feeling unsafe to express yourself
  4. frequent Sunday night blues
  5. no more laughing at work

As Sallie Krawcheck mentions, your signs could be different. 

As a manager, you might want to keep these warning signs in mind when running one-on-ones with your employees.  You could ask questions to try and uncover burn-out or dissatisfaction early. For example, you might ask

  1. What is standing in the way of greater success for you?
  2. What are you passionate about? Does your passion find a voice at work?
  3. Do you feel safe taking risks and speaking out at work? We may not always agree, but I always want dialog to be open.
  4. What parts of your job do you look forward to?
  5. When was the last time work was particularly fun or rewarding for you?

As a manager, I hope I can talk about these things with my directs.

No worries. Just talk.  I want my directs to be happy. Life’s too short to hate your job.

I Can’t Accept Every Meeting

Some time last year I realized that if I scheduled every meeting I’m “supposed to” schedule, and accepted the standard meetings others are “supposed to” schedule it would add up to more than 40 hours in meetings every week. Up to this point I had been scheduling, accepting, and rejecting meetings in a one-off way.… Continue reading I Can’t Accept Every Meeting

Shrink Annual Performance Reviews

Adobe has abolished annual performance reviews in favor of more frequent, lighter-weight check-ins.  My company has annual reviews but since I became a manager it has been my goal to make those reviews a non-event. That is, I try to have weekly check-ins (one-on-ones) that bite off performance review a week at a time.  Read the article for Adobe’s take.

My own challenges:

  • It can be easy to be too zoomed in during weekly check-ups. So I’ve been adding monthly and quarterly triggers for higher level discussions.
  • In an agile development environment it can be hard to set long range goals.  Each developer is more or less committed to doing whatever comes next off of the backlog. Creating metrics that give concrete feedback while valuing all the important work being done is an enormous challenge. I’ve found that when you do hit on a good metric people are relieved to see the evidence of their good work being recognized.

Thank you to this week’s Mad Sad Glad from Manager Tools for the link.

You may not be able to abolish performance reviews, but if you’re a manager you can shrink them.

My Current Favorite Interview Problem Memoize

Just added memoize to my growing catalog of interview questions.

Summary of the Challenge

Part 1 is a discussion. Part 2 gets to the code. You can skip straight to 2 when time is short. This problem is particularly useful for gauging JavaScript familiarity since it takes advantage of functions as objects and closures.

There’s a lot of jargon in the question, but that’s not the point of this challenge. Make sure they understand the question. You might gauge how willing they are to ask questions, but only gently. Don’t put them on the defensive just by the wording of the question.

Part 1: You have a number of expensive pure functions. During the course of any given hour these functions are each called with a small number of inputs. Hour over hour the inputs vary dramatically. Describe how you could improve the performance of the system.

Candidate behaviors to look for: Caches the results and bypasses the expensive function calls when the answer is cached. Memoization. (See formal write up for details.)

Part 2: Write a higher order function (a function that takes a function and returns a function) that accepts a function of arity 1 and returns an identical, memoized function. (See formal write up for candidate template and example solution.)

Good At Differentiating Candidates

You will find that some candidates will solve the problem handily, refactor, then easily run through the examples. Other candidates might have to be coached more through the implementation, but should at least be able to step through the execution of the examples.

Brakes That Don’t Slow You Down

As an engineering student I was impressed by the intricate harmony of development processes. It was probably the same part of me that loved the uniformity and audacity that is xml. These days I use JSON 100 times more often than xml. I’ve similarly fallen out of love with process. But there’s still a grudging respect there. Like… Continue reading Brakes That Don’t Slow You Down

Two Common Release Plan Types

Two basic types of release plans that are widely used are scope-boxed release plans and time-boxed release plans. “In a scope-boxed plan the work that the team will do is defined in advance, but the release date (time) is uncertain. In a time-boxed plan the time and release date is defined in advance, but the specific work that people will… Continue reading Two Common Release Plan Types

WOTD: Poka-Yoke Means Mistake Proof

Your word of the day is poka-yoke: mistake-proof. Such as keying on network cables that ensures they can only be inserted correctly. From Wikipedia:

Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means “mistake-proofing”. A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means “fool-proofing” (or “idiot-proofing“) the name was changed to the milder poka-yoke.

http://en.wikipedia.org/wiki/Poka-yoke

To eliminate defects we embrace poka-yoke instead of blaming people.

Dumb, Costly Errors Should Be Hard To Make

Building computers for fun in the 1980’s I ruined at least one floppy drive because I plugged the controller cable in backwards.  Nowadays those kinds of screw-ups are much more difficult to make.

My favorite story about being committed to not blaming people comes from my father’s career. They had chemicals next to each other in identical vials that made it easy for him to mistakenly waste about $10,000 of material. (Double that figure when you adjust for inflation.)

When he hesitantly told his manager about it the guy said, “Well, we shouldn’t have made it so easy to make that mistake.”

Whole Root Challenge

Interviewed another candidate today.  A colleague used a challenge based on computing square roots.  It’s a very simple problem and still gives a quick feel for a candidate’s comfort with JavaScript and solving problems with code.

I’ve added it to the (tiny) suite of interview code challenges. See github.com/ManagerJS paper-code/whole-root. I hope you find this useful conducting interviews and preparing for interviews.

Here’s a copy of the challenge for your convenience:

Continue reading Whole Root Challenge

Thank you everyone for your interest and support during the first two month’s of this blog. With over 50 posts published I’m drawing down now.  I already take Sundays off to recharge. Since I’m a Scoutmaster and my troop meets on Wednesday nights I’m adding Wednesday to my blog-free days.

Next page