Microsoft Interview Question for Software Engineer / Developers


Country: United States
Interview Type: Phone Interview




Comment hidden because of low score. Click to expand.
0
of 0 vote

There are three kinds of users: owner, renter, guest
behaviors:
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.

- Eidolon.C July 27, 2015 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

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.

- Kake December 04, 2015 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

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

- Anonymous November 30, 2016 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

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

- rsk November 30, 2016 | Flag Reply


Add a Comment
Name:

Writing Code? Surround your code with {{{ and }}} to preserve whitespace.

Books

is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.

Learn More

Videos

CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.

Learn More

Resume Review

Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.

Learn More

Mock Interviews

Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.

Learn More