Delta File: Say You’re Welcome

When others treat you poorly, let it go. Forgive.

As you move on, break the incident down into behaviors–factual elements of the interaction. Commit to do better for when the roles are reversed.

Collect these entries in your own “Delta File:” a collection of the changes you want to be in the world.

My first entry:

When I hold the door open for someone and they look me in the eye and say, “Thank you!” I will not look away with a blank emotional affect and say, “Yep.” I will look back at them and say, “You’re welcome!”

“You’re welcome” takes almost no extra time. I know it feels much better to hear than a dismissive, “yep.”

Thank you, Mark

The idea of the Delta file came to me through Manager Tools podcasts. Mark Horstman has sprinkled references to keeping a “delta file” throughout the casts. For him, it is a list of things you plan on handling differently when you are a manager.

It Will Take Time

I’ve been trying to change my “yeps,” “uh-huhs,” and “no problems” into “you’re welcomes” for a few weeks now. It still comes out a bit forced.

In the mean time I notice that people saying “you’re welcome” does feel different. It feels better.

I’ll keep pushing through this awkwardness. After all, I used to hate to smile. Now I have smile lines. My first wrinkles.

You Will Have More Success

Any one habit aimed at putting others at ease can be argued with. You can’t reasonably argue with the fact that putting people at ease increases your success.

As I’ve learned more and more about the human side of work I am more and more astounded by how logical we aren’t.

Our rational capacity is bounded. Other people can ignore your antisocial habits, but it costs some of their reserves of rational behavior. You want them to find you easy to get along with so that your ideas get that much more attention.

Get Into Internships

[I Love It] One of my favorite parts of being a manager (and I didn’t anticipate this) is recruiting interns on university campuses. Being part of offering a great opportunity to students right when they need it is very rewarding.

[Good For Students] A good internship helps a student make a transition from a mostly individual success model to a team success model. I have seen some colleges do a good job encouraging groups to work together in school. Even for these students there is a difference between group projects in school and being part of a team that succeeds or fails all together.

[Good For Companies] Of course, people who employ interns tend to get a great deal. It isn’t uncommon for our interns to get rave reviews from their team mates and Product Owners. They’re enthusiastic and eager to achieve. You can pay them more than they are used to and still be very cost effective.

Recommendations: For Managers and Students Getting Into Internships.

All employement should result from a fit between the needs of an individual and the needs of the company. Keep this in mind and you should always find special satisfaction in searching for and finding that fit.

Internships often have a built in expiration date that makes them particularly useful for both students and new managers: both have an escape clause in case the fit wasn’t great.

In my experience, if the fit is there then internships are often extended. Again, this benefits both the company and the intern.

Even when the fit is there and the internship has to end you have made a new contact in your network.

To Managers:

  • 1. Recruit your own interns
  • 2. Require evidence that they will immediately contribute
  • 3. Polish your hiring skills by using them – A LOT
  • 4. Prepare to give plenty of supervision

To Candidates:

  • 5. Apply before you are ready
  • 6. Be honest and do your best
  • 7. If you’re hired plan to over-communicate

To Managers:

1. Recruit Your Own Interns

If you are going to have an intern then you should take part in the recruiting process. This gives you the best chance to find an intern that will fit well with your team.

I participate in a recruiting program for the entire company. We interview hundreds of interns for scores of slots. Each of us tries to represent a standard, uniform bar.

Still, it is very difficult for that bar to be uniform.

If you’re going to have an intern on your team then you should get out to the schools and do as much of the finding and interviewing as possible. It is impossible to know as much about a candidate from notes as you can by interviewing in person — no matter how robust the interviewing culture.

And many interviewing cultures are not that robust at all.

2. Require Evidence That They Will Immediately Contribute

Even the best intern will generally come to you with less experience and judgment than a senior hire. That doesn’t mean you can’t expect a lot.

Every year I find gems at the schools I visit who have amassed plenty of evidence that they can contribute on a team from day one. Sure, they will need time to settle in. There will be some adjustment to working on a team, and working at your place. But they will deliver value right away.

To prepare yourself to find these gems ask yourself what is the clearest sign of success for a junior member of your team. Now go about looking for those signs with the candidates you interview.

You will probably have a different set of indicators than me. But for reference here are mine:

  1. Can they code?
  2. Can they disagree and commit?

I evaluate both questions by giving my candidates simple coding challenges that they have to solve with me during the interview. I spend some time on behavioral questions and asking a bit about their background. But the majority of the time is a coding audition.

This isn’t the same process I use for senior hires. I use it for interns, and I’ve had great success.

Of course, there are going to be candidates with great potential that can’t quite code yet. That’s OK. I hope they interview with me again in 6 months. If not, then that’s not the end of the world either. Not for me. Not for them.

3. Polish Your Hiring Skills By Using Them – A LOT

Recruiting interns I routinely interview 12 to 15 candidates a day.

I read a lot of resumes. I ask a lot of questions. I do a lot of probing. I do a lot of coaching.

I get a lot of practice seeing good and bad qualities in a lot of candidates. I have to make a lot of hire/no-hire recommendations. I have to take a lot of detailed notes so that I can support the other managers that are hiring from the same pool.

You meet a lot of people. You get a lot of first impressions. And you gather and process a lot of data on a relentless timeline.

This is good.

Most managers hire very infrequently. That makes it hard to have good hiring skills. And the skills you do have go to seed as you neglect to use them.

Go out and interview a lot. Hire a handful of interns a year. Get to see the results of your judgment again and again.

It’s good for you.

4. Prepare To Give Plenty Of Supervision

When you do bring an intern on board give them meaningful work and lot’s of guidance. Meet with them daily or delegate it to a sharp direct.

Mentoring an intern is a great way to grow a direct that is hoping to qualify for promotion.

Be prepared for the intern to under communicate his challenges. Keep an eye on their progress. Let them know they are making a valuable contribution.

As a manager, now is NOT the time to sit back and see what happens.

I remember that during my first internship I sometimes went several days between substantive discussions with my manager or team mates about what I was working on. I treated the workplace like a large and quiet library. Every door had an automatic “DO NOT DISTURB” sign in my mind.

That’s the way I had done homework. But that’s not the way you do team work. You might have to help your intern through that transition.

To Candidates:

My recommendations to managers (above) should be a helpful reference to candidates as well. In addition, here’s some advice just to you interns.

5. Apply Before You Are Ready

A lot of students that are preparing for a software career are detail oriented, perfection-seeking, high achievers. That’s good. You’re going to be great!

Unfortunately, this can lead you to delaying all sorts of things while you are making it right.

You need to realize that there is a big difference between school and work. And the only way to really prepare is to start working in your field.

Workshops can help. Coaching can help. Mentors can help.

But if you aren’t careful you will find that your careful preparation has left you unprepared. There is a difference between theory and practice that you can only begin to learn with practice.

Apply before you think you are ready. Give it a real go. Act as if you are ready. As a matter of fact, you might be!

If you get a good offer and you’re not sure whether to accept it, that’s a good problem to have. Much better than graduating with a 4.0 and not prepared to transition into a job.

6. Be Honest And Do Your Best

In the interview be honest about what you know and what you don’t know. We can tell when you’re making things up.

If you don’t know the answer to a question then you must start your answer with, “I don’t know.”

If you do know how to find the answer then give that answer after admitting that you don’t really know.

I’ve had many candidates say, “I don’t know for sure, but I believe it is something along the lines of…” and their answer was so good that they didn’t lose any points for not being absolutely sure.

7. Plan To Over-Communicate

If you do get hired then plan to overcommunicate. (See point #4 above.)

This does NOT mean talk a lot. Everyone you are working with is going to be very busy.

When I say, “Over Communicate” this has more to do with frequency of communications than the size of those communications.

Be clear on what you are assigned to accomplish. Predict the progress you will make and communicate that to your supervisor. Let her know when you will be late. Let her know when you have delivered. Let her know when you are blocked.

Often your supervisor or team mates will say little when you communicate. This doesn’t mean it was wasted effort. Keep communicating your progress, deliveries, and blockers.

On your first few days it will probably be appropriate to communicate your status every few hours. By your second week you’ll probably be communicating status once a day. Don’t communicate less than once a day until asked to.


Internships can deliver great value to a company and rapid growth to a candidate. Invest in them and you can change someone’s life – even your own.

STAR Interview Tip

If an interviewer asks you a question like, “Tell me about a time when you evaluated a new technology to solve an old problem,” be sure to use the STAR Model to help yourself give a satisfying answer.

STAR stands for Situation, Task, Action, Result. It’s great for answering all sorts of questions about your past performance. (Google “STAR answer”.)

For example, an answer to that, “evaluating new technology,” question might sound like this:

Situation: “I was a junior developer at company X last year. We had a site for selling a product with a lot of options that could all be toggled on and off. This updated the product preview.”

Task: “We had to add some more options and I noticed that several relevant frameworks had become popular since we first wrote it. I thought one might be a better fit than our entirely custom code.”

Action: “Over a few days I used spare time to pick three frameworks. I implemented dummy options in all three. I took notes on which ones were easiest to use. I did simple performance tests of my examples and collected some online benchmark data. I picked the one I thought balanced performance and ease of use and presented a recommendation and my notes to my supervisor.”

Result: “My supervisor agreed with my pick but said it was a bad time to add a framework.  We wrote a story about adding the framework and prioritized it in the backlog.  After a couple of weeks we played the story and added the framework. It took some getting used to for a couple of team mates.  After a couple more weeks we agreed it had been a good move.”

I just timed myself giving that answer in a normal, unhurried tone. It takes less than a minute.

Don’t get into the weeds in your initial answer. Giving a STAR answer first and letting the interviewer probe for details allows you to focus on a complete and brief answer.

Behavioral Interviewing

By the way, that kind of interview question is from a “behavioral interview.” The premise of behavioral interviewing is that, while imperfect, past performance is the best indicator of future performance. (Google “behavioral interview”)

Rather than ask a brain teaser, or hypothetical question about what you might do in a situation, behavioral interviews ask you what you did do in a certain kind of situation.

If you are just getting into a certain job market (like web development) then still answer behavioral interview questions using your past experiences.  You may be asked, “How did you evaluate a new technology for an old problem?” and your answer doesn’t have to be about web development.

Bonus Tip: Put the “I” in Team

Remember that the interviewer is going to hire you and not your team. So make sure it is clear what your contribution was.

Also remember that you are being hired to work on a team. So don’t sound like a glory hound.

Learn to Do

What will more effectively convince a hiring manager that you can produce results for them? Should you focus on making products? Should you complete programming challenges?

Past results are the best evidence of future results. But it’s hard to beat solving a problem before the eyes of your interviewer. Here’s Raul’s question:

Candidate Question: Preparing For Interviews

Hi Tyler,

It’s me again! with another question. I’m interested in what you think.

So I’m deciding on where to put my free time, building something or practicing algorithms/DS problems, to get the better job/opportunities out there.

I believe that someone can learn how to build something in their normal job but in opposite, they need to study/practice specifically for algorithms/DS to be good at it.

Do managers think that a candidate should be expected to know how to build things just because they have worked before in a related field? and go straight to algorithms/DS questions because they want to see how the candidate thinks? or will they care about the candidate showing them what they have built and will not be very strict on your algorithmic/DS skills?

How does this work? what is you opinion? What is more impressive to you or for what do you look into a candidate when you hire him, that he has actually answered your algorithmic/DS questions or that he has built something?

For example: I had some coworkers that were really good at building whatever you liked but they did not know what Big O, BFS, DFS, Binary trees were etc…

So they clearly won’t be able to answer most technical questions on an interview but they are really good at building something.

Thanks for your time!


ManagerJS says…

Thank you for your question, Raul. Before I give my own answer, realize that there are many important abilities that you need in order to be an effective worker. Managers often call these competencies. Each job opening will have three to five competencies that the hiring manager considers essential.

In this case I’ll limit my comments to a vague technical competency.

Results Matter Most

In short: a manager hires a candidate because she believes they will produce results. More specifically, the right results in the environment of the company she is hiring for.

The future isn’t known yet. So a manager has to guess at what information will most reliably predict good future results.

Time and again the best predictor of future results has been shown to be past results.

While it might sink you when naïvely applied to the stock market it’s really the first rule in hiring.

Have a Portfolio

If you have a product you’ve created yourself, and it’s sharp, then put that in your portfolio. That’s one of the best bits of evidence that shows you really can produce future results.

Unfortunately, many people don’t have compelling products they’ve made in isolation. When they talk about past results it’s often difficult to tease out what exactly they did versus their team. (I’m sure you’ve been part of a team with some free riders.)

No matter how good a portfolio a person has I want first-hand testimony to add to my list of evidences. I have a short list of people I trust enough to give a recommendation that fills that need for me. If you don’t have that kind of referral then I’m going to want to see you work.

Be Prepared to Audition

When I give a candidate a sample problem and ask them to solve it with me I specifically do not want them to solve it from memory. If the solution comes too easily then I’ll give them another one. I need to see them think.

At the same time, I don’t want to see them think abstractly. I don’t use brain-teasers or riddles. I ask them to solve a realistic problem that lends itself to basic analysis and problem solving.

  • Do you think to restate the problem?
  • Do you seek to divide it into smaller problems?
  • Do you build up a solution using composition, looping, and branching logic?

These basic skills will be second nature to a developer that has really delivered solutions in the past.  They will be a challenge to a scripter that has mostly use the search, copy, mutate formula for hacking together solutions.

If you haven’t formal training in computer science, or your past projects have been monotonous, then you might want to beef up your problem solving skills with intentional practice solving programming challenges.

Do Both

Should you develop portfolio projects or should you solve algorithm problems?

  1. Have at least one solid portfolio project. Sharp and created (nearly) entirely by you.
  2. Be well practiced in learning new tools and finding novel applications. You might demonstrate these in one-off experiments in your portfolio.
  3. Know how to divide and conquer, recurse, and loop. (You can practice this a lot in programming challenges.)

In general I don’t hire you for the algorithms you’ve memorized but for the results you’ve produced with those algorithms. Tools (like algorithms) help you deliver. And you can’t use a tool you’ve never learned.

Be Likable

Here’s a gem from the February 20th edition of Mad, Sad, Glad from

This is a typical HBR article in that it’s long and academic.  The important part is that people would rather work with with someone who is incompetent than someone who is unlikable.  If you think that smarts are enough, refer to our very first podcast ‘Solution to a Stalled Technical Career‘.  Yes, HBR, we said it 10 years ago 🙂

2015-06-03 Unlikeable

What! I thought this was a meritocracy! Am I not hired for my mad skills?!

Well, yes. You are.

And contributing positively to a team is a skill. One the vast majority of us can’t succeed without.

Be likable.

Be a good, kind, and gracious person. People tend to like those.

No tricks. Don’t just gently imitate others like Andy Bernard from The Office. Trickery is icky and doomed to fail — if not professionally then ultimately in the shriveling of your soul.

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.

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 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

paper-code helps you interview

In addition to writing daily for this blog, I’ve been scraping together resources that web devs and their managers might benefit from during interviewing.  I made the ManagerJS GitHub organization to hold those documents and code.

Today I’m announcing the paper-code repository.  It will hold programming challenges you can sketch out with pen and paper during interviews. I routinely use these when interviewing intern candidates. Continue reading paper-code helps you interview

Would You Hire Me if I Didn’t Have a Degree

Any hiring manager has to decide how she feels about college degrees. Is it a must? Nice to have? Irrelevant? It comes up in conversation. You have to decide whether it influences your hiring decisions.

Applicants want to know, too. Should I stick it out in college? Should I change my degree from psychology to CS? (I know an intern now facing that kind of question.)

I interviewed an applicant a couple of weeks ago on a university campus and he wrote to ask me about college degrees.

Continue reading Would You Hire Me if I Didn’t Have a Degree

Your Resume: JavaScript is Not an Also-Ran

Somewhere Java managers are reviewing resumes. One says to the other:

This guy doesn’t look strong enough technically to be a back-end engineer. But hey! I notice he lists html, css, and JavaScript on his resume. Send him to Tyler. He’d probably be a good Web Developer.

There is so much wrong with this. I’ll just talk about the part you need to pay attention to as a job applicant: the web standards trifecta.

Continue reading Your Resume: JavaScript is Not an Also-Ran