Scott Hanselman

I received this question last week from a reader:

I've been a developer since 2005. I'm a solid developer with good experience. I've got a great opportunity for a new position coming up but I'm concerned about the tech interview. I seem to freeze like a deer in the headlights when asked to write code in front of people.

My resume is accurate and reflects my skills and experience but how do I prove I'm competent when I have this tendency to choke on tech questions when I'm put on the spot?

This is a great question. To level set, note that they aren't concerned that they don't have the skill. Their skills ARE up to the task. It's a case of anxiety around the live aspect of the tech interview

I would start with honesty. Talk to the hiring manager or the HR person. Offer to show them lots of code, your repos, examples. Offer to share more code than you'd ordinarily need to, as a way of making it clear you have nothing to hide. Everyone has something, be it anxiety, issues with public speaking, etc. Trying to hide an issue can make it worse.

Perhaps you could do a coding test where you *walk them through existing code* and explain. Explain to them that you have anxiety about whiteboard coding, BUT you want to make sure they get an accurate picture about your skill.

Also, practice! Talk to a friend and have them interview you and and have you code live. Folks don't ordinarily code live with an audience, so it's understandable why you might freeze or not perform at your best. If you don't do something often (like code live in front of an audience) then, darn it, do it often! Practice. 

Understand also that the interview may also want to see how you react under pressure. Do you get visibly angry? Wilt? Fall back on first principles? Denigrate yourself? Apologize? These reactions can be as important as your actual code. Usually interviewers are looking for thoughtfulness, analysis, patience, calm, and humility.

What do YOU think, Dear Reader? The comments on posts like this are usually better than my opinions!

* Photo by Kevin Dooley used under Creative Commons

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I had an interesting chat recently at a conference in the "hallway track." The hallway track is all the great conversations that happen in the hallway between sessions.

What drives your development processes? Are you a TDD house, where your tests drive development? Or, perhaps there's a chief architect who isn't a very nice person. We call this ADD - Asshole Driven Development. However, this chat was about FDD - Fear Driven Development.

Organizational Fear

Organization fear can have developers worried about making mistakes, breaking the build, or causing bugs that the organization increases focus on making paper, creating excessive process, and effectively standing in the way of writing code.

This "analysis paralysis" slows the entire project down. Every one is so afraid of the process that forward motion stops. There's a great post called "10 ways to lose a team" that covers many negative behaviors that can affect a team. Things like

• Forbidding one-on-one meetings
• Don't share information
• Implying that everyone can be replaced
• Micromanaging

All of these behaviors increase ambient fear and can cause a cloud of anxiety to loom over the organization.

Losing Your Job Fear

Other kind of Fear Driven Development is when an organization tries to get developers to stay far too late, work unreasonably hard, by implying that they'll lose their job at the sign of any problems with the project. Threatening jobs will never create a more productive team. It only perpetuates negative feelings and will always lead to people quitting. This also can cause management to believe that heroic effort is a common and acceptable part of the software development. An occasional "work push" is one thing, but if EVERY RELEASE cycle means a heroic effort at the cost of your personal relationships, you've got problems.

Fear of Changing Code

Another kind of Fear Driven Development is when your development organization (or your entire organization) is afraid of the code. Perhaps the code is older (legacy code) but more likely it's just not fully understood. It mostly works, but folks are afraid that a small change to the code could cost unpredictable side-effects. Fear of bug regressions - a closed/fixed bug coming back to life also stresses developers out.

Can you think of other flavors of Fear Driven Development?

* Photo by Stacy Brunner, used under Creative Commons

Sponsor: Many thanks to Aspose for sponsoring the blog feed this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

There's few things that get me too riled up when it comes to advice. I love hearing about other people's lives and their life systems. From the mundane and familiar, like how they pack their kids lunches, how they manage their finances, or how they manage their email.

The only thing to do with good advice is to pass it on. It is never of any use to oneself. - Oscar Wilde

We are an amalgamation of all the advice we've ever been given. The first 18 years of my life I was trapped in my parents' house and subjected to their "advice." Most of which turned out to be spot on. I am currently forcing my children to take my advice until their brains full form (which I suspect will happen in about 25 years).

A word to the wise ain't necessary - it's the stupid ones that need the advice. - Bill Cosby

I did a post yesterday called "Don't Check Your Email in the Morning." It's not that controversial, I think. However, it's been characterized as "The singular most life-changing productivity tip I've received" as well as "Simply terrible advice."

Come on. This is simply an issue of self-reflection. Look at your personal habits, your routine, and how you go about your day. Do you go about your workday on auto-pilot, or with a sense of intentionality?

Don't check email in the morning is a rule of thumb. The essential point is "Don't get caught up in the minutiae of unimportant morning email checking if you're unknowingly using email checking as an way to procrastinate."

Maybe checking email every 5 min works for you. Perhaps that morning quick email sweet is essential to your business. Hey, more power to you. You check email 365 days a year. I wonder what would happen if you didn't check it in the morning for a day? Might be useful advice. Totally might not. You'll never know unless you try.

I like trying on shoes. But if the shoe pinches, I don't wear it.

Consider not checking your email in the morning, if you think it might help you. Enjoy the comments.

Related Links

• The Three Most Important Outlook Rules for Processing Mail
• Photo by Ben Grey used under CC

Sponsor: Many thanks to Aspose for sponsoring the blog feed this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

In my productivity talk "How to Scale Yourself and Get More Done Than You Thought Possible" I include a challenge to the listener. It's kind of insane, but it's actually proven very useful to me when I really need to get important work done.

Don't check your email in the morning.

Insane right? I believe that checking your email in the morning is the best way to time-travel to after lunch.

Why DO we check email first thing in the morning? Well, because something crucial might have happened overnight.

There's a few things wrong with that sentence, in my opinion. Words like "something" and "might" stick out. We check our email because of fear, a sense of disconnectedness, and (in some cases) a feeling of urgency addiction.

We often go to bed with our current project or work on our minds. It's THAT project that we should probably wake up and start working on. It's that project that we kind of left unfinished when we went to bed in the first place.

We SHOULD get up and start working on our project first thing. Instead we check our email, get sucked into it, answer a few, get stressed, answer a few more, threaten to delete the whole inbox, and then it's lunch time.

When I'm not really focused, sometimes the day just slips past me. I find my feet around 5pm when the day is winding down, not at 9am when it should be winding up.

If something really really important happened it won't be in your inbox. Your phone will be blowing up. Someone will be sitting in your seat when you show up at work. They will find you.

When they DO find you, you should be working. Go to work and resist the urge to check your email. Start working immediately, head down, sprinting. There's HOURS of time before lunch to be discovered.

Here's your homework. Go to work tomorrow and don't open email until afternoon. You might be staring at first, wondering what the heck you're supposed to do. Do that project. Write that code. Work on that book. Update that blog. Do literally ANYTHING except email.

When you open email for the first time after lunch, you'll have hours of amazing work already behind you and you'll feel amazing.

Try it.

Sponsor: Many thanks to Aspose for sponsoring the blog feed this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I've been working remotely now, from home, for over half a decade. I work in my home office, from cafes, from my tethered mobile, basically anywhere I can be productive and not feel like a phony.

Here's the thing, though. I have to go to meetings, and I spend 15 minutes of those meetings waiting for YOU (yes, you, there) to unmute your mic, setup your cam, mess around with your internet, and generally waste the remote worker's (yes, me, here) time.

UPDATE: I'm putting this over on GitHub for you to improve! https://github.com/shanselman/howtounmute.com

So, as a customer service to the internet, I present.

http://howtounmute.com

That domain points directly to this post. Please, tell your friends family and clients.

Why not include http://howtounmute.com as a link in your meetings?

Is your mic muted?

Using Skype?

See that circled icon? That's a muted microphone. Click to unmute.

Using Lync?

In Lync, this means your phone and mic are turned off.

Click the left one to unmute! Click the right one to turn on your cam! You can also use the "Win+F4" global hotkey to unmute Lync.

Using Google Hangouts?

The unmute button is at the top of the hangout.

Click the little Settings Gear to select your microphone and speakers from within Google Hangouts.

Using Some Weird old Adobe Flash-based Web Conferencing Thing?

Seriously, stop. What's wrong with you? Then, right click on the box where the app is running and click Settings...

You can select your Microphone and see the bar move on the right, indicating it can hear you.

Wait, did you select the right microphone globally?

Most apps let you select microphones within the app. You can also set your preferred mic globally.

Which mic am I using? Right click on the little speaker near the clock and select "Recording Devices."

Some machines have more than one microphone. Windows lets you set a "Default Communications Device" for calls like Skype, and this is different from the "Default Device" for regular audio apps like Audacity. Right click to set your default.

PRO TIP: Tap your microphone (or where you think it is) to confirm where you THINK it is. Watch the green bars move.

Applications can also select their individual preferred microphone. Here's Tools | Options in Skype. See how I can select where I want my audio output to go? And where I want my input to come from?

Got a Mac?

That's cool. Type "Sound" into Spotlight and open your settings. Note you can see your input volume, your preferred input devices and preferred output device.

Got a physical phone?

There is VERY likely a microphone mute button on the phone. Familiarize yourself with the phone's buttons and try this one.

Maybe you have a headset? Does it have a mute button? Maybe you bumped it.

Call to AUDIBLE ACTION

If you take 5 to 10 minutes NOW to make sure you know how to select your microphone and umute yourself, you will save remote workers everywhere 15 minutes for every 1 hour meeting.

Sponsor: Many thanks to Intersoft for sponsoring the feed this week! Enterprise cross-platform native apps development made painless with Intersoft Crosslight. Sounds too good to be true? See it for yourself and get started today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By