Since the persistence format is a file and you rule out text based formats what other choice than binary serialization do people have? sqllite?

I'm also wondering what other than first or last name can be ordered alphabetically?

Do perf considerations play any role? If not, this is trivially simple with the only tricky part of reading variable-length strings from binary files. But still: load file in memory and then iterate over loaded data to your heart's content. If performance considerations do play a role, though, it becomes a much more complex task and amounts to basically implementing a DBMS with indexes and such.

Are all text based formats rejected, including CSV and fixed-width?

BSON seems like the obvious choice :)

Would RavenDB be acceptable for the persistence?

Simon - I believe the fact that he specifically says XML and JSON have been ruled out is to see what kind of developer you are.

You blindly accepted the specification. I expect the kind of candidate Ayende is looking for, he wants you to ask him, question him and explain why XML and JSON would be the way to go

James, your probably right and I would have asked for an elaboration for that decision had I've been at an actual job interview. My question was more meant as a clarification as to what other types of storage he imagined would be suitable, maybe I had missed something or misunderstood the phrasing of the question.

Ok guys, submit your API :)

// Ryan

Do you ask here for an actual implementation or rather an overview of the work involved, decisions taken, etc.?

Here's my take. Viewed from the actual usage point. The internals are leftout. ;)

// Ryan

enum EntryType { Work, Cellphone, Home }

class PhoneEntry { public string FirstName {get;set} public string LastName {get;set} public EntryType EntryType {get;set} public string PhoneNumber {get;set} }

class PhoneEntryValidator { public bool IsValid(PhoneEntry entry); }

enum SortBy { FirstName, LastName, }

class PhoneBook { public PhoneBook(string phoneBookFilename);

public void Save(PhoneEntry entry); public void Delete(PhoneEntry entry);

public IEnumerable<PhoneEntry> Entries(SortBy sortBy); }

"text based format such as XML or Json has been ruled out" - that's not something I could easily accept. You can't really suggest an alternative without asking why.

API:Linq to XML calls

Use sql lite, it still uses a file!

Firebird Embedded, MS SQL Express, MS SQL Compact, SQL Lite, etc

I would be surprised if there isn't already a "good" library available for download out there. Out-of-context questions are always a little odd. -What is this going to be integrated into? -What is the business reason for disallowing certain formats? I've run into those in the "real world", where a manager simply dislikes Technology X because he read an article 18 months ago that gave him a bad impression, which sometimes cannot be overcome with logic. -When you say "phone bookS for users" do you mean a single user may have multiple phone books? Are those user-managed? Is storage an issue such that a single contact should never be stored twice?

I know I'm probably overthinking a plate of beans and this is simply an exercise where I should ignore the business/integration stuff, but I hate not knowing that other stuff.

Access!!

.WAB files! http://msdn.microsoft.com/en-us/library/ms629733.aspx http://contacts.codeplex.com/

That is a pretty nice idea. I am not sure if it can be applied to a company which does not have such an excessive amount of great applications available. It might cause good candidates to skip your company because it is too much (speculative) work.

Guys, give up on the text formats. The problem clearly states text-based formats are not acceptable. Does anyone here really think he's looking for someone who just knows how to invoke the SQLite driver?

He spells out the requirements for a basic database engine with indexing. It's a multifaceted problem that can expose a lot about a candidate in their solution. Are concerns separated logically? How is performance addressed against disk I/O? How is code correctness validated (e.g. testing)? To submit a project that just wraps another database is disingenuous. He's looking for people that can solve problems head-on, not just pass the buck.

Mike, yes off course but I will still always suggest the simplest possible solution first. That tells you a lot about a candidate too.

Excel, baby!

Is this a practical exersize where you want some code as the answer? or simply a detailed description of the proposed solution?

We all know that Ayende would like to see this built on RavenDB ;-)

We all know Ayende would like to see this built on RavenDB ;-)

Just make sure you don't make a mistake, or you will be the subject of a future blog post telling the world just how shit you are.

I'll use ESE (esent.dll) I had heard that @ayende uses it in Raven, so... ;)

hahaha bob +1 +1

Interesting mixed answers. Thanks for the hint Ayende, I'll use it in future interviews. :-)

Is using Munin (https://github.com/ravendb/raven.munin) an acceptable answer ;-)

Ayende, What did you want to heard? Enlighten us!

As much as I like writing code, my initial question would be "Can we use an existing system, rather than writing code that we'd then have to maintain?" and in this case, it's squarely in the sweet spot for an LDAP server which gives us a couple of well documented APIs for "free" (the LDAP protocol and the System.DirectoryServices namespace.) AD LDS or OpenLDAP, perhaps? If it turns out that the aim is specifically to see your code, rather than to see how you solve the problem more broadly, then I'd ask more specific questions and fire up an editor having considered these other options first :)

I'll hire Tim Wilde please. Most sensible answer by far.