Our current interview question is from this post. We use that between the phone interview and the actual interview to get a feel about a candidate abilities. You can learn a surprising amount of information from even small amount of code.

Note that one of the primary goals of such a question isn’t to tell you “You should really hire this candidate” but to tell you that “You really shouldn’t”.  To clarify, this is a “do it on your own, and you got the whole internet at your disposal” kind of question. Typically we give a week or so to answer this.

Sometimes we get a very clear signal from the code, like in the case of this code:

	// if only there was an O(1) way to do this...
	// Dictionary<string, long> dictionary
	var result = dictionary.Where(x => x.Key.Equals(key)).ToList();

view raw what.cs hosted with ❤ by GitHub

But I think the crowning glory was this code:

	// serialization of Dictionary<string, long> to file
	string serialize = JsonConvert.SerializeObject(dictionary);
	byte[] array = Encoding.UTF8.GetBytes(serialize);
	using (var txtWriter = new StreamWriter(path))
	{
	for (int i = 0; i < array.Length; i++)
	{
	txtWriter.WriteLine(array[i]);
	}
	}
	// read it back
	byte[] data = File.ReadAllLines(path).Select(byte.Parse).ToArray();
	using (StreamReader txtReader = new StreamReader(new MemoryStream(data)))
	{
	var serializer = new JsonSerializer();
	var result = serializer.Deserialize<Dictionary<string, long>>(
	new JsonTextReader(streamReader)
	);
	return result;
	}

view raw the.cs hosted with ❤ by GitHub

I picked two of the worst offenders, but there were more. Some things I can sort of let slide, and some things I’ll just say no to.