5 tips on how to prepare for an IT job interview. Some general, some practical.

And now for something completely different.

Having just dealt with a number of job interviews, from the job-seeker's point of view, I can testify with some certainty as to how to prepare for one such interview. I furthermore claim some success in this, in as much as I was offered 4 jobs from the 4 interviews, so I hope some of the below tips, which I made use of myself, will prove helpful to you, too.

Tip #1. Stake the place out. Apply the same dress code for your interview.

Why #1? Because a future boss is the more likely to approve of a potential candidate if she/he seems similiar in style to the future boss in question. Goes not for everyone, but for the majority of us we like the kind of people we ourselves are. And you can take advantage of that. I'm not suggesting you sit in your car outside the place for hours on end, a simple search on the Internet, presumerably their webpage or social page, will do.

Tip #2. Print out the job add and highlight relevant sentences on it.

Why #2? Because that will keep you focused on what your strategy will be, going into the interview. And it's essential you have one - it will set you apart from the others. Maybe you applied because the job add sounded really interesting, maybe you applied because you're in damn need of a job to pay your bills; whichever is the case, you can be sure you'll be asked the question "what makes this job interesting to you". And you're not to reply 'I need a job to pay my bills', so highlight relevant sentences that bring about the essense of the job add and form a strategy for answering that question, "why did you apply for this particular job" (they never seem to think that you're likely to have applied to several others, they want to hear about what makes them special to you). For example, let's say the job add mentions "must have an interest in front-end web development". You'll highlight that and make it your strategy-call: so your answer will be "because I'm going to dedicate my career to web development, it's the future I'm certain, and this company seems to be on target to be part of that future and want to be a part of that". Or something to that effect. Again, set up a strategy for what how you will present yourself and your talents. What's your 'thing', what do you have that makes you not just one in the crowd? How can you hook that up with the job add's requirements, with the company's requirements?

P.S. You don't really need to highlight one or more sentences, that's just what I myself do as I carry that printed-out job add with me to the interview, to glance at it and the lines I highlighted just a minute or so away from attending the interview.

Tip #3. Don't drink anything prior to the interview, especially coffee.

Why #3? Okay, this is a bit personal and certainly practical, it's because - if and only if you're like me - you're likely to be a bit nervous. That's a healthy thing, it will keep you on your toes, but - and, again, only if you're like me - you'll be wanting to take a pee every damn fifteen minutes, from being nervous. So if your interview is before 12 noon, and you think you can do without, it's best not to drink anything and not risk having two minutes to go before entering the room for that interview and be really needing to go to the bathroom.

Tip #4. Prepare a show and tell of something you've done (preferably in the technology that you're about to be hired for).

Why #4. Because, even if you haven't been asked to do a show and tell, this will keep you sharp and focused, right up to the second you enter the room. It will prepare you mentally if there's suddenly a coding-test in the required job-skills, that you weren't aware of. And it will make you feel like, and exude the persona of, one who comes prepared, and your body language will reflect that. It doesn't matter that you'll never actually do a show and tell. That's not the point. The point is going in there in a confident, well-prepared manner, and that's where the show and tell, disregarding its potential use, will help you.

Tip #5. Prepare for this question, "what are your good points and what are you bad points".

Why #5. Because these are classic questions that you're likely to be asked. And for a good reason, too, much can be interpreted from the answers. As is the case with tip #4, even if you'll never be asked it's good thing to have an answer ready, as it'll keep you focused on what you want to sell yourself by. With the "what are you not good at"-question, you'll try to direct the answer towards a moot point of sorts, so as to not put yourself in a less than favorable position. Don't give them some entry point they can start to dig into and create fuss about. Instead say something like "well, I'm not good at dealing with internal power-struggles and bickering" or maybe "I'm not good at dealing with an employer who's not supportive of my desire to keep myself updated in my field". That's a show-stopper right there, they're likely to talk about how that's not the case with their company and you in turn haven't actually declared any significant bad point about yourself.


The above is what works for me, and may not necessarily work for you, but I sure hope at least one or two of the points will help you, and best of luck to you. The main point of this post is this: It's vital you prepare for that interview. Don't just go in there thinking "I aced the resumé so now they want to talk, I can just wing that, it's just a chat". You spend (hopefully) time on the application, and you should spend time on the interview as well. Spend two-three hours on it, that'll suffice. Your posture will be the better for it.


Bonus tip #1. Take a shot of sugar before the interview. The sugar-rush will add 10% to your mental capabilities for a short duration, this has been a certified exam-tip for years.

Bonus tip #2. If they ask you, 'where do you see yourself in two years?' answer 'with this company', immediately and without hesitation. They want to hear their investment will still be there in two years' time so that's the answer you need to give.

Mocking session state in a asp.net mvc4 unit test using Moq

I recently spent more time than I'd liked to figure out how to mock session state within an ASP.NET MVC test project. So here's the solution to that one, so hopefully you won't spend as much time as I.

Important disclaimer: I was all over the dial to search for info, but most of what I dug up was related to asp.net mvc 3. This below solution works for me with ASP.NET MVC 4 and Moq as mocking framework.

Consider the following controller and single action-method:


public class HomeController : Controller
{
public HomeController()
{
// default constructor, usually you'd inject some repository or what not here, but for this example we'll keep it simple
}

public ViewResult TestMe()
{
System.Diagnostics.Debug.WriteLine(Session["selectedMonth"]);
System.Diagnostics.Debug.WriteLine(Session["selectedYear"]);
return View();
}
}


The action-method references the current httpcontext's Sesson collection. So if we instantiate a 'HomeController' and try to obtain a ViewResult when calling the action-method, our unit test will fail with a NullReferenceException.

So, since the action-method wants to know about the Session collection, which resides in the HttpContext for the request to the method, we need to provide a HttpContext object. The below unit test code creates a mock HttpContext object, hooks it up to a mock Session object and passes it the instantation of the controller - and the test will then pass, as now the action-method has a HttpContext to reach into and yank out the Session info.


[TestMethod]
public void TestActionMethod()
{
// create the mock http context
var fakeHttpContext = new Mock();

// create a mock session object and hook it up to the mock http context
var sessionMock = new HttpSessionMock {{"selectedYear", 2013}, {"selectedMonth", 10}};
var mockSessionState = new Mock();
fakeHttpContext.Setup(ctx => ctx.Session).Returns(sessionMock);

// ... and here's how to attach a http context identity, just in case you'll come to need that, too
var fakeIdentity = new GenericIdentity("mno@ucsj.dk");
var principal = new GenericPrincipal(fakeIdentity, null);
fakeHttpContext.Setup(t => t.User).Returns(principal);

// we'll need to hook our http context up to a controller context mock - because we can't provide our controller with the http context mock directly
var homeControllerMock = new Mock();
homeControllerMock.Setup(foo => foo.HttpContext).Returns(fakeHttpContext.Object);

// all set up, now we'll instantiate the controller and pass our controller context object into its 'controllerContext' property
var target = new HomeController()
{
ControllerContext = homeControllerMock.Object
};

// ... and the below call to the action method won't throw a nullReferenceException, because now it has a Session state to dig into
ViewResult result = target.TestMe();

// ... and so the test will pass
Assert.AreEqual(string.empty, result.ViewName);
}