Microsoft Interview Question
Software Engineer / DevelopersCountry: United States
Interview Type: Phone Interview
Eidolon, I think the very aspect of this 2 sided AirBnB like marketplace is to remove the middleman "renter" persona in your types of user. There would only be 2. Other than that your bang on.
1. Complexities to manage are fake uploaders/ bots which disrupt the experience.
2. Also, building a solid experience for both sides of the marketplace is a challenge.
3. You would have to build in a good pricing model also to incentivize both parties, while making your cut.
4. Getting 2 parties to communicate and close on your site so making fullname and contact details anonymized until money is paid.
5. Managing stay aspect so no last minute snags
6. Payout has to be escrowed and managed etc.
I relate this problem basically to a 'Mediator design pattern' type of model. I see three peer entities that inter-communicate : 'Owner', 'Tenant', 'Property'
So assuming we don't deal with millions of users/big data scenario here, we can may be use RDBMS for entire data storage. So backend design would be primarily three tables 'Owner', 'Property' and 'Tenant/guest'
An owner can have multiple properties, a tenant can be looking for multiple properties etc can be managed using key constraints.
Coming to Middle-tier design, an Interface called 'User' that is extended by both 'Owner' and 'Tenant'. 'User' has few contracts to adhere to such has 'Registration No, 'Type of user', 'Contact details' etc that owner and tenant can then full-fill during 'registration' process.
Then the third concrete class being 'property' . Has property Id, Name, location, type, price, owner, last updated, photos etc.
Fourth is the 'controller' (vis-a-vis Mediator) that manages following functions primarily
- Registering both parties
- Searching properties based on given criteria (location, type, availability date range, price, popularity, last updated etc)
- Requesting info (of owner, of property, of guest etc) here some info should be confidential
- Making/receiving payment
- Some AI stuff such has listing out 'relevant' ones based on location for instance, 'highly rated', 'other similar properties', 'deals' etc. This i kept apart from the basic search (2nd function) that 'Mediator would perform because this would be largely performed on aggregate level (i.e irrespective of user type, prop type etc)
Lastly UI layer could be ..at simple , four distinct pages. One for registration, one of search and pick and one for payment.
Reg aspects to consider, 'Kake' above considered it overall i guess. Only thing i want to add here is , when a property with given criteria cant be searched /unavailable then should the system show a nearest ones (like a loop) or just say not found, broaden your search ? . I often find this tricky with real-time sites. So thought worth considering.
Please let me know
I relate this problem basically to a 'Mediator design pattern' type of model. I see three peer entities that inter-communicate : 'Owner', 'Tenant', 'Property'
So assuming we don't deal with millions of users/big data scenario here, we can may be use RDBMS for entire data storage. So backend design would be primarily three tables 'Owner', 'Property' and 'Tenant/guest'
An owner can have multiple properties, a tenant can be looking for multiple properties etc can be managed using key constraints.
Coming to Middle-tier design, an Interface called 'User' that is extended by both 'Owner' and 'Tenant'. 'User' has few contracts to adhere to such has 'Registration No, 'Type of user', 'Contact details' etc that owner and tenant can then full-fill during 'registration' process.
Then the third concrete class being 'property' . Has property Id, Name, location, type, price, owner, last updated, photos etc.
Fourth is the 'controller' (vis-a-vis Mediator) that manages following functions primarily
- Registering both parties
- Searching properties based on given criteria (location, type, availability date range, price, popularity, last updated etc)
- Requesting info (of owner, of property, of guest etc) here some info should be confidential
- Making/receiving payment
- Some AI stuff such has listing out 'relevant' ones based on location for instance, 'highly rated', 'other similar properties', 'deals' etc. This i kept apart from the basic search (2nd function) that 'Mediator would perform because this would be largely performed on aggregate level (i.e irrespective of user type, prop type etc)
Lastly UI layer could be ..at simple , four distinct pages. One for registration, one of search and pick and one for payment.
Reg aspects to consider, 'Kake' above considered it overall i guess. Only thing i want to add here is , when a property with given criteria cant be searched /unavailable then should the system show a nearest ones (like a loop) or just say not found, broaden your search ? . I often find this tricky with real-time sites. So thought worth considering.
Please let me know
There are three kinds of users: owner, renter, guest
- Eidolon.C July 27, 2015behaviors:
owner: identify; upload items, manage items (including item description, duration, rent and deposit); receipt return
renter: identify; search items, request for items, pay to vrbo(including rent and deposit), receipt item, return
guest: search items.
Sort of like that. To design a system we should analysis the roles and the requirements, correct me if I'm wrong or inform me if you have any better ideas, thanks.