We did this in Skype for awhile.
The common concern at the time was "what if the candidate cheats, getting someone else to do his/her takehome for them?"
The way we responded was by conducting the in-person interview at least partially around the takehome assignment:
* What made you choose this approach?
* Can you talk about the architecture of your solution?
* What do you think about the following alternative solution?
* Where do you see potential points of weakness in your solution?
Then it becomes pretty clear if the candidate wrote the code or not.
…ut hiring a senior engineer without any sense for their coding abilities, I’d suggest you provide a very short take-home assignment (which takes no more than an hour or two to complete). Most senior engineers should be able to find…
At a recent 1:1, a report who’s moving to a different manager asked me what the experience of switching managers is like, and what he should come to the first 1:1 with his new manager with.
The answer is the same for any new relationship, and consists of three parts, established in that order.
In this post I’d like to go through each of these three and explain a bit how they apply to a first-1:1 situation.
As a manager, one of the most common conflicts I see between employees is style vs. content. The sad thing about those is they’re almost always avoidable, but because people don’t practice the skill of separating style and content, or don’t even realize there is such a skill, conflicts rooted in miscommunications tend to escalate and result in poor workplace relationships.
What do I mean by style vs. content?
Content is the set of concepts / actions / requests you want to get across. The what.
Style is how you get them across.
People tend to react emotionally to style…
Going on tangents kills too.
I see this as a manager all the time, when dealing with ambiguous tasks, it’s all too easy to go off on a tangent that seems important at the time but, on further reflection, probably isn’t.
An inability to stay on task is one of the most common and most effective ways of stunting your career growth.
Here’s an easy way to stay on track. Ask yourself the following three questions first thing in the morning, after lunch, and at the end of your workday.
Note the question isn’t “What is my highest-priority…
Ever wondered why your partner doesn’t take you seriously when you’re upset? Or on the flip side, seems to blow their gasket for the tiniest of reasons?
Here’s an approach that might help you understand each other.
There are two kinds of people when it comes to reacting to pressure: bombs and kettles.
“Whatever,” you say, “there are a million personality types and infinite ways of dividing humanity into ‘two kinds of people.’”
This one is apt not for any great insights it offers into your psyche, but in how the two types interact with each other.
See, the problem…
You’re working with another org in coming up with a joint architecture for web-based applications. They want to use WebComponents, while you think React is the better way to go. They’re emotional about their choice, and don’t want to budge. How do you hold a rational discussion with these people?
The situation is a common cause of frustration and needless conflict. Now, I’m not saying that these types of issues are easily resolvable, and sometimes you’ll have to involve upper management and let them fight it out. …
One of the key challenges senior ICs and new managers struggle with is effective delegation. For some the idea of delegating something they could perfectly well do themselves just doesn’t make any sense. Others run themselves ragged trying to do everything on their own because they can’t bring themselves to trust their reports.
Or you have the managers who dive-bomb delegate, showing up at your office to drop a task on their report’s head, and disappear into the clouds like a cowardly kamikaze.
They aren’t being assholes. They are just bad at delegation.
One day I had an epiphany: delegation…
Dealing with Ambiguity is one of the core competencies Microsoft tests for in their interviews. It is the ability to approach complex, ambiguous problems in a systematic manner, and make sustained forward progress without getting lost in tangents.
Today I’d like to drill a little bit into this competency, explaining how it plays out in real-world scenarios, and a couple approaches to succeeding in highly ambiguous situations.
Moreover, I would like to show that ambiguity permeates every aspect of software engineering, and dealing with it effectively is the key component of career success.
Ever wondered what it’ll take to get you to the next level in your career? I’ve written several posts analyzing different facets of this question (links below), but today I want to talk about a diagram a manager at Microsoft drew for me at our first 1:1. I’ve used this diagram since, and it had never led me astray.
One of the common issues I find early-stage engineers facing is how to position themselves on a team in such a way as to be given work they’d enjoy doing. All too often folks feel stuck, feeling like code monkeys, just executing their manager’s vision.
So what do you do if the tasks your manager hands down to you aren’t interesting? What do you do when every day at work feels like a drag? You watch other engineers be given interesting, fun challenges and think “But what about me?”
Eugene Polonsky is a 24-year veteran in the IT field. When not writing about management, he runs a team at Adobe and works on his Nordic fantasy novel.