Well we can't read the interviewers' minds.... My initial guess: Build to the requirements at hand. Do these guys use the "agile" buzzword to describe themselves I wonder?
Is there something I could do better with my factory design?
myFactory.BuildCar(make, model, trimLevel, options). That factory instantiates a FordFactory, BmwFactory, etc. Each manufacturer-factory knows it's own models and associated trim levels. So there is some kind of "data set", a common structure with data specific to each manufacturer.
Car Meta Data
Off the top of my head...
A trim level is a standard set of features. And higher trim levels are supersets of lower ones. Then options are a-la carte choices outside of trim levels.
Next we need structure to hold that meta data. I imagine a CarModel class containing a collection of available trim levels and another of available options. Each manufacturer-factory has a "data set" of their specifics.
There must be some global stuff, especially so we can pass arguments to the factory. There will be "collections" - makes, models, trim, options. But what kind? Any expedient kind for now. And maybe even enums!
What matters is the API
API is evolving because we know almost nothing about what we're building at this point. But API is relatively stable and that allows the implementation to morph.
Our goal is not to achieve maximum design pattern density. What we know at this point is simple so design simply. But I was hinting at the abstract factory pattern above.
.net collection classes inform us about our likely API. "contains", "find", "add", "remove", etc. so I'll go with that.
Domain Specific Language, API, and Fungible Implementation
I tend to write custom collections - very DSL-ish - that contains a List or whatever. Maybe if I looked up ICollection real quick I might inherit that - but still encapsulate as I said. That way the actual type of collection can change at will and I totally control the API, I hide all the .net public methods, wrapped/exposed as needed in DSL custom methods.
In terms of DSL, individual manufacture factories is better than a single monolithic factory. It expresses the car-making domain better. It is not a question of "the single factory is simple enough." That's never the right answer. Well, never say never.
Is there something wrong with the approach of List of Feature for each car?
I do not know what "compare cars" is, but implementing IComparable is not it. As your code shows, it orders features. But off hand ranking (sorting essentially) makes no sense to me. Which is greater "leather seats" or "air conditioning"? Are "child locks" and "electric windows" equal?
Web sites I've been to compare things by selecting specific features and then filtering items that meet that selection.