Bad Interview Question: What is your greatest weakness?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/bad_interview_question_what_is_your_greatest_weakness.htm]

For technical interviews, I think "What is your greatest weakness" is one of the dumbest interview questions ever. It's like the recruiter thinks they're being so smart and sneaky ("ah ha, this unsuspecting candidate will reveal all their shortcomings as I judge them"), but it really misses the point.

 

Problems with this question:

• If the interview cannot determine your weaknesses from normal interview questions, are they really weaknesses? It is part of the recruiter's job to determine your weaknesses, and by directly asking you, they're essentially asking you to do their job for them.

• Most people aren't even aware of their biggest weakness, especially because human nature always sees ourselves in the best light possible.

• It's an abrasive question that puts the company in a bad light. People want to talk about their successes and how they'll add value, not their mistakes.

• Does the interviewer actually expect the candidate to tell the complete truth about their own flaws?

• To avoid ivory-tower syndrome, (in my opinion), recruiters should not ask behavioral questions that they themselves are not prepared to answer.

• It's a dead-end question that prompts the recruiter to pick the "least of the evils" - if you're just discussing your negative qualities, you're not going to look like a positive candidate.

• If I knew my weakness, I'd already be fixing them.

• It's very dull, and shows no creativity from the interviewer.

• This sort of question isn't going to impress a candidate. Often, the interview is really two ways, with many companies all trying to woo the star candidates.

Really lame replies:

• "I work too hard", or "I try to hard". --> anyone who has been around can see straight through this.

• "I do such a good job that it makes everyone else envious of how great I am."

• "I don't really have any flaws." --> everyone has limits, which is very different than saying that you do have shortcomings, but they occur mostly in other, unrelated fields, or long ago when you first got started.

• "I've never been in a position with enough influence to do any damage, so I'm not sure."

Possible good replies:

• Humor: "You know, you could get a really good answer for that if you just talked to my wife." (or husband/spouse/significant-other )

• Serious: "While I've made mistakes in other fields, like buying my first car, for years I've been putting most of my eggs into the software engineering basket precisely so I don't make huge costly mistakes anymore. But we can discuss my early car-buying experiences if you'd like."

• Confident: "Let's have an interview and you tell me."

• Change topic: "Here's how I've dealt with mistakes that the company has made, and turned them around to be profitable..."

• Pick a small, past event: "When I first got started, 10 years ago, I used VSS for source control. The default single-user lock model really messed up our multi-team project. Now I'm happy that we always use Subversion."

• Sarcasm: "My  biggest mistake ever - like single-handedly causing the stock market crash of 87 - I don't do those kinds of things anymore." (you'd need more charisma than I have to pull it off)

• Smart Aleck: (when you don't want the job) pick a topic that's way over the recruiter's head. I'm trying to think of an impressive example, but I'm sure the readers of this blog would just tell me how simple it was.

• Smart Aleck (when you don't want the job): "What would you consider a failure? Perhaps you can tell me some of your greatest failures so I know what kind of things you're looking for."

At Paylocity, I don't think I've ever asked a candidate this. Instead, I'll ask "what areas of development do you enjoy", or "what areas do you wish you had an opportunity to learn more about". The goal is not to trick people with dumb gotcha questions, but (for me) to figure out where their passion is. I prefer a positive approach of "what are you passionate about" as opposed to a negative approach of "what are your flaws". At Paylocity, we don't ask people to do what they're bad at, we ask them to do what they're good at - i.e. play to their strengths, not their weaknesses. Also, the interview should be an indicator of what the company is about, and what kind of company goes around asking their employees "what do you suck at most"?

 

Published book: A Crash Course in Reasoning

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/reason.htm]

Clear reasoning is essential for developers. So, I'm proud to have finished publishing a book "A Crash Course in Reasoning".

 

 

It's a fast read (170+ pages), in plain language. Really it's intended for high school and college students who are looking at basic reasoning skills (i.e. I have kids and I'd like them to eventually read it). However, developers may get a kick out of it too. It covers a broad spread of topics:

• Chapter 1: Introduction

• Chapter 2: Objective Reality

• Chapter 3: Premises

• Chapter 4: Logic

• Chapter 5: Epistemology

• Chapter 6: Communication

• Chapter 7: Psychology

• Chapter 8: Learning

• Chapter 9: Conclusion

Official abstract:

Using images, tables, and constant examples, this book provides a practical and plain-English introduction to reasoning. We start by emphasizing the importance of objective reality. We then explore the different types of premises (definitions, observations, given facts, assumptions, and opinions) that can be built on this rock-solid foundation. From those premises, we can make logical inferences (both deductive and inductive) to arrive at conclusions. We strengthen this process by explaining several epistemological issues. Once the reasoning is clear in our own head, then we can communicate it to others. As we deal with other people, we’ll also need to deal with the psychological aspects that people inevitably bring with them. Finally, thinking clearly for ourselves and with others, we’ll want to apply everything we’ve discussed to increasing our learning and problem solving abilities.

This page will contain updates for the book.

MVC troubleshooting: If the controller doesn't have a controller factory...

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/mvc_troubleshooting_if_the_controller_doesnt_have_a_contro.htm]

I was toying around with the MVC pattern, and I kept getting this error while doing a tutorial:

 

'TaskList.Controllers.HomeController'. If the controller doesn't have a controller factory, ensure that it has a parameterless public constructor.
 

I'm no MVC expert, so I had to poke around a little. Ultimately, what seemed to fix it was making the database connection key in web.config match the key in the auto-generated dbml code.

 

The dbml code was failing on this line (in a file like "*.designer.cs"):

public TaskListDataContext() :
base(global::System.Configuration.ConfigurationManager.ConnectionStrings["TaskListDBConnectionString"].ConnectionString,

mappingSource)
{
    OnCreated();
}

I had modiefied my web.config, so there was no ConnectionString setting for "TaskListDBConnectionString", so that returned null, hence it failed. I needed to update web.config to something like so:

 

   

    name="TaskListDBConnectionString"

    connectionString="your_connection_here"

    providerName="System.Data.SqlClient"/>

 

To troubleshoot, I started stubbing out things one at a time - making an empty solution, downloading the final code, comparing the differences, etc...

 

"I prefer my way of doing it to your way of not doing it"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/i_prefer_my_way_of_doing_it_to_your_way_of_not_doing_it.htm]

I once heard this quote - I forget the context or who said it - but I really like it. Software Engineering is full of second-guessers and Monday-morning quarterbacks. Many projects seem to have that pessimist who snubs the teams' attempt to do something because it's not as good as that "perfect past project" that they were on. There's something to be said for the developer who just gets it done - even if the code isn't the best.

More Xml Design Patterns

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/more_xml_design_patterns.htm]

 

Last month I mentioned some tips for structuring xml, which could be seen as the start of primitive Xml Design Patterns. Here are three more ideas.

 

Strongly-typed nodes

 

Say you have a node, which can have several different groups of attributes. For example, you're making a test automation DSL, and you need to assert that various conditions are met. You may have a basic assert, a correct-page assert, and a text-search assert:

The schema for this becomes messy - you'll have one node (Assert) with all possible attributes. Your interpreter will need to infer which action to take based on the current attributes. Validating the xml file also becomes error-prone. It's doable, but messy. Compare that to this:

.Page pageName="myPage.aspx" />

.Text textToFind="EmpId123" isRegex="false" isCaseSensitive="false" />

This approach has essentially three nodes: Assert, Assert.Page, and Assert.Text. This effectively gives you "strongly-typed nodes". Your interpreter instantly knows which type of node, and therefore what action it expects and how to validate its attributes. Your schema becomes simpler because each node type has only the relevant attributes. This isn't always the best approach, but it can be a good one in certain cases.

 

 

Serializing complex objects to attribute strings

 

You can serialize almost any object to Xml, but the question is what is the best way to do it? For example, you could serialize an array as a bunch of nodes:

   

        12

        35.5

        40

        9

   

However, this is somewhat bloated. A more concise way is to serialize it to a string, and then store the results in an attribute:

You could serialize an array as a CSV list: "1,2,3".

You could serialize a name-value pair: "name1=value1;name2=value2" (this is what MSBuild does)

You could even have a mini DSL, like the Silverlight path expressions: "M 10,100 C 10,300 300,-200 300,100".

 

The main thing this approach requires is an easy way to serialize and deserialize the object to a string. If you've got that, then this technique becomes very reasonable.

 

 

Abstract complex objects to inner content

 

Silverlight uses Xaml markup to describe the UI. Xaml allows a lot of style markup.

 

You can create a simple ellipse, shading the entire thing a solid blue.

Fill="Blue" />

However, you can also give it a more advanced two-color gradient shade by abstracting the "Fill" markup to the inner nodes of the ellipse. Specifying a single attribute is great when you can serialize all the necessary info to a single string, else you can leverage the more-powerful inner xml nodes (per a Jesse Liberty tutorial).

   
     
        
        
     
  

This allows the best of both worlds - the single-line common case, and the more advanced case.

LCNUG: Gorking the ASP.NET MVC Framework

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/lcnug_gorking_the_aspnet_mvc_framework.htm]

Yesterday, Derik Whittaker presented at the LCNUG about the MVC pattern. I had a last-minute family emergency come up, so I couldn't make it, but it looked good.

This is the fifth presentation at the LCNUG, almost half a year. It's been great to see the new group up and running.

Real life: the leaking window

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_the_leaking_window.htm]

House repairs provide a lot of good software analogies. Once during a big rain storm, our window started leaking. It was a newly installed window, and it had never leaked before. Well, obviously a leaky window can become a huge problem if left unfixed. So, I went out sometime later, sprayed the window with the hose to try to get an idea of where the leak is (I was not, and still am not, a house repair expert), and to my great frustration - the window did not leak. Of course I wanted to reproduce the problem, narrow it down to the exact cause, and then make a quick fix - just like I would in a software project. I didn't want to rebuild the whole thing.

So, here is a "critical feature bug" (the leaky window), which occurred in "production" (during the actual rainstorm), but I cannot reproduce in my "development environment" (sunny day with my spraying the window with a hose). It was a non-reproducible bug. However, I couldn't just ignore it or look the other way, I needed to ensure that it didn't happen again (given that it's my house, I need to take "ownership" of the "project"). It's the kind of thing that drives a software project mad.

In this case, I just 'blindly" resealed things - checked the siding, exterior frame, interior, etc... And the window never leaked since. If it does end up leaking again, then I'll probably need to call an expert, much like how some doomed software projects sometimes call in a star consultant to troubleshoot their obscure bugs.