Author Archives: andrei

9 months in Xbox Security Team

It’s been 9 months since I accepted and offer and joined Xbox Security Team.

It is important to acknowledge milestones in one’s career and now is an important developmental milestone in my career. Personally, I prefer to work on v1 projects and features and my choice was also largely influenced by an amazing product we recently announced – Xbox One.


Few things to mention about past nine months with Xbox:

  • security at Xbox is taken very seriously
  • people are very passionate about the product
  • team is highly professional about everything we do
  • there are a lot of hardcore gamers in their 20s and 30s
  • Xbox is the only team at Microsoft that has “Fun” in its mission statement and it is quite true – we get all new Xbox games upon release
  • Xbox team is moving really FAST!

Yes, we do move really fast and it’s especially true in Services team where I currently work. I also re-discovered SCRUM and can’t even think of moving back to shipping every one-two years. Running sprints can be challenging but much more rewarding. The feedback loop is just so much shorter and you see results right away and your features serve customers immediately. And yes, I did a lot of software design and coding in the past 9 months.

Go Xbox!

FxCop: suppressing Web.config errors and warnings

Recently I had an issue where I had to suppress certain errors coming out of ASP.NET configuration files. Since Web.config isn’t a code per se we need to use global suppression file to suppress errors coming out of config file.

The real problem was that the issues where reported not in the project where the file Web.config is located but from a different project in solution:

d:\BuildTest\Any CPU\Release\DeploymentDrop\Web.config(27): warning : CA3114 : Microsoft.Security.Web.Configuration : Always
enable custom errors to return generic error information. Set mode attribute to “On” in unit MyProject file d:\BuildTest\Any CPU\Release\DeploymentDrop\Web.config line 14 column 4 [D:\PathInTFS\MyProject\MyProject.csproj]

The issue was solved by adding GlobalSuppressions.cs to MyProject where there issue was showing up (not where Web.config lives!):

// This file is used by Code Analysis to maintain SuppressMessage 
// attributes that are applied to this project.
// Project-level suppressions either have no target or are given 
// a specific target and scoped to a namespace, type, member, etc.
// To add a suppression to this file, right-click the message in the 
// Code Analysis results, point to "Suppress Message", and click 
// "In Suppression File".
// You do not need to add suppressions to this file manually.

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Security.Web.Configuration", "CA3114:SetCustomErrorsModeToOn")]

Note that SuppressMessage above will suppress all CA3114 messages in the project.

Programming Interview Preparation: Whiteboard

In a month you will have programming interview at elite Big Co or rocket-ship startup. You are reading CLRS, Programming Interviews Exposed and even coded 20 problems. You are confident and things are going well. But wait, aren’t you expected to solve programming tasks on a whiteboard?  

In a month in your interview loop not only will you meet sharpest engineers, A+ players who consistently want to raise the bar and have no mercy towards B and C players, but your code will be scrutinized, you need to deliver solution under pressure and on time. On a whiteboard.

Whiteboard coding isn’t programming per se, it’s a sport. Every second counts, every line of code is important and you are required to show your best. Get ready, read on and you will walk on water during your coding session.

Of course, you need to practice. Practice a lot. Not alone, but with a real interviewer.

Stage 1: Get Familiar with Whiteboard. If you are lucky enough to have a competent friend or mentor – ask him or her to interview you at least twice a week. Do a mock interview on a whiteboard as often as possible. You first goal is to get a feel what it is like to have several whiteboard coding sessions a day. At this stage you need to become absolutely comfortable to code on a whiteboard, it should be just as easy as typing on a computer.

Stage 2: Become Fast Whiteboard Coder. I mean really fast whiteboard coder. When an interviewer asks you to solve the task which involves binary tree, you don’t want to ask too many questions. 30 seconds and binary tree node should be on the whiteboard. Not only you saved 10-15 minutes of interviewing time that you will use towards solution, but you also impressed the interviewer since past 5 candidates just started to warm up at this point.

Stage 3: Become a Whiteboard Master. We are not going to talk how to solve your task here – you are a rock star engineer, why do you need any help with that? At this point you are polishing your skills:

  • Buy thin markers and use them during interview. They will help save expensive whiteboard space and your code will be much easier to read. Remember to bring several markers to the interview, you may forget to put it back in your pocket if the interview was very intense!
  • Use whiteboard space wisely. Practice and make sure that your solution is not stretched all over whiteboard.
  • Time yourself. Make sure you really know how long it takes you to implement data structures, loops, error handling and standard solutions such as traversing linked list.

You will be much better off even if you will practice in complete solitude, but best results are achieved with a ruthless interviewer. Practice, don’t rush and you will succeed.

PowerShell: capturing output to log file and console

Recently I had to redirect full PowerShell session to both console and log file. Full means both stdout and stderr needs to be redirected. Working code is worth thousand words:


Stop-Transcript | out-null
$ErrorActionPreference = "Continue"

$OutputFileLocation = "C:\output.log"
Start-Transcript -path $OutputFileLocation -append

Write-Host "This will go into output.log"

# redirecting both STDOUT and STDERR (2>&1) to transcript:
robocopy.exe C:\ D:\ readme.txt 2>&1 | out-host



Line 11 deserves additional explanation. Due to a PowerShell bug 315875 output from native applications will not be captured. That being said, the workaround is to combine stdout and stderr and redirect it to a out-host.

The only remaining limitation is that stderr will be interpreted by PowerShell as error (and rightly so!) and thus printed out in red. While it is a little annoying, your output log doesn’t have colors 🙂


Programming Interview Preparation: Books

I am frequently asked how to prepare for a technical interview at top software companies in the US. Having been on both sides of programming interviews, I can say that one of the keys to successful interview is to start preparation early and have focus.

Maintaining focus during preparation is difficult as there literally thousands of programming problems to solve. However, I will keep the list of must-read books short as they will prepare you for 99% of all programming interviews. Here are the books per area:

Programming Interviews


Computer Architecture

Software Design

Ideally you would read all of them and complete most tasks, but if you are on a really tight schedule, both books from Programming Interviews category will get you started and the rest can be used as a reference.

Good luck and raise the bar!

Interviewing your interviewer

| Software Developer: best job in America

By and large, it’s true. Every year job ratings are published and positions in the software industry are at the top. As software engineers, we became desensitized to issues that professionals in other industries have: high stress, immoral behavior, risk to life, etc.

We tend to live in a tech bubble and take for granted the following attributes of a job that other workers can only dream about:

  • interesting and challenging work
  • ability to learn and grow every day
  • smart colleagues
  • fast-growing industry and stable employment
  • great pay and benefits
  • flexible work hours

Us software engineers are spoiled due to a competition for talent, tech industry growth and opportunity to build the Next Big Thing. But how do you choose a proper team and the right opportunity?

First, you need to get a critical mass of interviews. When you have 5-6 teams or companies that would like to interview you, and you think you can work for them, that’s a good start.

Second, you need to prepare for the Technical Interview, including coding on whiteboard and the ability to create solid designs in a matter of minutes.

There are plenty of books that cover the first and second steps above. However, very rarely do you see another aspect of interviewing that’s just as important as the first two. Ready?

Third, you need to prepare to Interview your Interviewer.

Wait, aren’t you supposed to be answering all their questions and make a solid impression of the next Alan Turing or at least John Carmack? Yes, but in the 5-10 minutes that you have to ask questions you need to excel at getting insider information.

You need to come to the interview prepared with knowledge of the company/team. Personal connections, Linked and Glassdoor will help.

During the interview, when you are finally allowed to ask questions, you need to cut through new-hire brochure BS and, like a cold-blooded KGB agent, get all the information there is about position, team and company. You need to ask right questions and observe the behavior of the interviewer.

Good Signs:

  • interviewers look genuinely happy and you feel good vibe
  • interviewers are laughing
  • interviewer are asking smart questions and focus on the right things
  • interviewers are not afraid to answer your questions
  • interviewers are not afraid to say “I don’t know”
  • hiring manager is answering your questions without any fear or doubt and is generally confident

Red Flags:

  • hiring manager is not answering your questions and instead talks about something not related
  • hiring manager constantly interrupts you
  • you get the impression that interviewer is arrogant, and it is orders of magnitude worse if you feel that several interviewers were arrogant
  • hiring manager/interviewer is not enthusiastic about the project
  • team members don’t show excitement about the work

Very rarely have I seen teams with arrogant and/or incompatible people delivering great results. They maybe 2nd, 3rd but they will never be Number 1. Over time, personality conflicts will prevail. According to Harvard Business School professor Noam Wasserman, and author of the famous book “The Founder’s Dilemmas”, 65% of start-ups fail due to people factor and interpersonal relationships.

One last piece of advice If you are interviewing for a small company: make sure you interview all team members, especially if it’s a young company. Otherwise you may find yourself disagreeing with a co-founder who “was sick” on the day of your interview.

Good luck with interviews!

Move Fast and Break Things

When back in 2006 I started to work on UIQ 3.0 and Symbian OS 9.x, I was impressed with the architecture and design of Symbian. Coming from a fast-moving mobile app-development company to work on Operating System that was powering 80% of world’s smartphones at that time was an exciting challenge. What struck me first day that everything that UIQ and Symbian did they did in the right way. Everything you read in books and blogs, articles and white papers was applied at Symbian: Symbian OS was object-oriented from the ground up and had vast sophisticated hierarchy of classes with awesome documentation, development tools were mature and powerful, every aspect of software development process was also done in a right way – we used Agile/SCRUM, great source control system (Perforce) and bug tracking  software (Serena). Every feature was properly designed, reviewed, implemented and tested. When we fixed bugs – we looked at the spec and only then talked to PM/Architect. And yes, specs were actually up-to date (mostly). Every code check-in was core reviewed, had accompanying Unit Tests and automated testing suite was executed (STEAM). However, in early 2007 iPhone came out and it became clear that Symbian will soon become obsolete unless major changes will be done.


Copyright Alex Kolesnikov

So why did Symbian and UIQ failed during transition to capacitive multi-touch screens? As with any major disaster (think collapse of USSR) there are many reasons that lead to a quick demise, but I think the most obvious and biggest reason of failure in case of Symbian was that it could not embrace change fast enough. Going even further, I believe that the fact that Symbian engineers, architects and management were used to near-perfect release cycles and great engineering systems, they were all reluctant to embrace the change. Why would you change a great engineering infrastructure? Great engineering culture that was working so far? Being used to a predictable and solid engineering practices inhibited change.

Move fast and break things. Adopt or die. Adopt chaotic, hectic world of Web 2.0 and cloud, when you ship or rather launch every week. Symbian, good bye!