t********e
发帖数: 344 | 1 刚面的，觉得面官是一个senior的人，寒暄了5分钟就让design an airport shuttle
scheduling system。
我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
个classes和function signatures。
然后他要我walk through the scheduling process，之间也是好多的unclear
requirement， 我就不停的问+修改design。最后时间用完，就道别了……
请问大牛们，这样的设计题interviewer希望看到怎样的答案呢？主要是考察什么呢？ |
l***i
发帖数: 1309 | |
a********x
发帖数: 1502 | 3 看head first design pattern
【在 t********e 的大作中提到】
: 刚面的，觉得面官是一个senior的人，寒暄了5分钟就让design an airport shuttle
: scheduling system。
: 我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
: yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
: 个classes和function signatures。
: 然后他要我walk through the scheduling process，之间也是好多的unclear
: requirement， 我就不停的问+修改design。最后时间用完，就道别了……
: 请问大牛们，这样的设计题interviewer希望看到怎样的答案呢？主要是考察什么呢？
|
d**********x
发帖数: 4083 | 4 design pattern is design pattern...
shuttle
了几
呢？
【在 a********x 的大作中提到】
: 看head first design pattern
|
s***y
发帖数: 203 | |
t********e
发帖数: 344 | 6 嗯 是的 一小时 就这一道题 ……
【在 s***y 的大作中提到】
: 就一道设计题啊？
|
t********e
发帖数: 344 | 7 why?
【在 l***i 的大作中提到】
: 我每次看到别人说设计题就想quit
|
l****o
发帖数: 315 | 8 我觉得如果不是很熟练design pattern.临场突然要我说用什么pattern最合适.我肯定
不行.
我答题就按三步:
1.确定会有哪些class.
2.这些class之间的关系.
3.每个class里会有哪些方法.
这样一是自己理清思路,二是然面试官知道你怎么想,他才可以帮你改进. |
|
d**********x
发帖数: 4083 | 9 re.
而且design pattern不是design。。
【在 l****o 的大作中提到】
: 我觉得如果不是很熟练design pattern.临场突然要我说用什么pattern最合适.我肯定
: 不行.
: 我答题就按三步:
: 1.确定会有哪些class.
: 2.这些class之间的关系.
: 3.每个class里会有哪些方法.
: 这样一是自己理清思路,二是然面试官知道你怎么想,他才可以帮你改进.
|
A**u
发帖数: 2458 | 10 先分析，
找共同点，找变化，
再看什么设计模式好用，
再设计
一上来就些类，写函数，是不对的
【在 t********e 的大作中提到】
: 刚面的，觉得面官是一个senior的人，寒暄了5分钟就让design an airport shuttle
: scheduling system。
: 我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
: yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
: 个classes和function signatures。
: 然后他要我walk through the scheduling process，之间也是好多的unclear
: requirement， 我就不停的问+修改design。最后时间用完，就道别了……
: 请问大牛们，这样的设计题interviewer希望看到怎样的答案呢？主要是考察什么呢？
|
|
|
d**********x
发帖数: 4083 | 11 我更喜欢从 well-structured 代码开始 refactor to patterns。
一开始就用设计模式往上扣的话，可能会跑偏了。。
【在 A**u 的大作中提到】
: 先分析，
: 找共同点，找变化，
: 再看什么设计模式好用，
: 再设计
: 一上来就些类，写函数，是不对的
|
g**e
发帖数: 6127 | 12 NYC office? 这不是我给我老板的题嘛
【在 t********e 的大作中提到】
: 刚面的，觉得面官是一个senior的人，寒暄了5分钟就让design an airport shuttle
: scheduling system。
: 我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
: yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
: 个classes和function signatures。
: 然后他要我walk through the scheduling process，之间也是好多的unclear
: requirement， 我就不停的问+修改design。最后时间用完，就道别了……
: 请问大牛们，这样的设计题interviewer希望看到怎样的答案呢？主要是考察什么呢？
|
l****o
发帖数: 315 | 13 幕后终极BOSS现身了...
【在 g**e 的大作中提到】
: NYC office? 这不是我给我老板的题嘛
|
p*****2
发帖数: 21240 | 14 我觉得这种题恶心的是根本就不熟悉这种系统。面试官也不先给讲讲。 |
g**e
发帖数: 6127 | 15 其实就是个优化consumer/producer系统的问题，我在隔壁版提到过类似的题，换了个
问法。现实中应用广泛
【在 p*****2 的大作中提到】
: 我觉得这种题恶心的是根本就不熟悉这种系统。面试官也不先给讲讲。
|
p*****2
发帖数: 21240 | 16
所以像我这样用C的去你家就只能跪了。我根本就没用过design pattern。
【在 g**e 的大作中提到】
: 其实就是个优化consumer/producer系统的问题，我在隔壁版提到过类似的题，换了个
: 问法。现实中应用广泛
|
g**e
发帖数: 6127 | 17 这是设计题，不是design pattern.
设计题一大误区就是上来就搞class/interface class diagram
design跟design pattern完全不是一回事
了个
【在 p*****2 的大作中提到】
:
: 所以像我这样用C的去你家就只能跪了。我根本就没用过design pattern。
|
p*****2
发帖数: 21240 | 18
consumer/producer我从来没用过怎么整？
【在 g**e 的大作中提到】
: 这是设计题，不是design pattern.
: 设计题一大误区就是上来就搞class/interface class diagram
: design跟design pattern完全不是一回事
:
: 了个
|
c***n
发帖数: 28 | 19 这个scheduling system 的 goal 是什么？ shuttle不是每隔一段时间有一班吗？能
不能具体描述一下你的解释？
【在 p*****2 的大作中提到】
:
: consumer/producer我从来没用过怎么整？
|
p*****2
发帖数: 21240 | 20
我就是这个意思。我根本就不熟悉这个系统，面试管得先把需求解释清楚吧。
【在 c***n 的大作中提到】
: 这个scheduling system 的 goal 是什么？ shuttle不是每隔一段时间有一班吗？能
: 不能具体描述一下你的解释？
|
|
|
b***m
发帖数: 5987 | 21 难道上来就写class和interface不行？ |
t********e
发帖数: 344 | 22 不是 seattle的
【在 g**e 的大作中提到】
: NYC office? 这不是我给我老板的题嘛
|
t********e
发帖数: 344 | 23 嗯，我和面试官说了好几次： could you please specify the requirements more
clearly?
人家就是说you can go ahead with your understanding, we will check it later
汗啊~
【在 p*****2 的大作中提到】
:
: 我就是这个意思。我根本就不熟悉这个系统，面试管得先把需求解释清楚吧。
|
t********e
发帖数: 344 | 24 同问~
我看150里OO design部分就是让写classes啊
【在 b***m 的大作中提到】
: 难道上来就写class和interface不行？
|
d**********x
发帖数: 4083 | 25 好吧。你能问出这个问题说明你对软件开发流程还不是特别了解
理想世界里我们都以为需求是可以先定下来，然后程序员坐在那坑吃坑吃开发，然后软
件就出来了
实际上。。。
【在 t********e 的大作中提到】
: 嗯，我和面试官说了好几次： could you please specify the requirements more
: clearly?
: 人家就是说you can go ahead with your understanding, we will check it later
: 汗啊~
|
l*********8
发帖数: 4642 | 26 co-ask
【在 t********e 的大作中提到】
: 同问~
: 我看150里OO design部分就是让写classes啊
|
e***s
发帖数: 799 | 27 这个贴要跟进，请大牛解释一下这样的设计题如何下手啊～～～ |
p*****2
发帖数: 21240 | 28
感觉这种题只有A家出的来。我自己觉得莫名其妙。
我的分析是这样
我印象中我只有一次做机场的shuttle。好像是gate变动了，变到另外一个terminal了
。然后就座shuttle转过去了。除此之外，我啥也不知道。如果不告诉我需求，我砸
design呀？
【在 e***s 的大作中提到】
: 这个贴要跟进，请大牛解释一下这样的设计题如何下手啊～～～
|
p*****2
发帖数: 21240 | 29
这话说的。
【在 d**********x 的大作中提到】
: 好吧。你能问出这个问题说明你对软件开发流程还不是特别了解
: 理想世界里我们都以为需求是可以先定下来，然后程序员坐在那坑吃坑吃开发，然后软
: 件就出来了
: 实际上。。。
|
t********e
发帖数: 344 | 30 那面试官指望我怎样？
communication不也是面试的重点之一么……
【在 d**********x 的大作中提到】
: 好吧。你能问出这个问题说明你对软件开发流程还不是特别了解
: 理想世界里我们都以为需求是可以先定下来，然后程序员坐在那坑吃坑吃开发，然后软
: 件就出来了
: 实际上。。。
|
|
|
l***i
发帖数: 1309 | 31 软件开发也不是只有A一家在做把。开发的时候花上一个月搞requirement也不稀奇。面
世一共就30min干政事的时间，要搞这种题。。。
【在 d**********x 的大作中提到】
: 好吧。你能问出这个问题说明你对软件开发流程还不是特别了解
: 理想世界里我们都以为需求是可以先定下来，然后程序员坐在那坑吃坑吃开发，然后软
: 件就出来了
: 实际上。。。
|
d**********x
发帖数: 4083 | 32 对的
先声明不代表公司意见。
上次A到我学校去招人做presentation，说他们首先是用最快的速度做一个prototype，
然后再iterate开发，因为没有prototype，需求都是扯淡，客户也不知道要什么，开发
者也不知道在扯什么。
当然这可能和公司风格或者是组的风格有关系。
后软
【在 t********e 的大作中提到】
: 那面试官指望我怎样？
: communication不也是面试的重点之一么……
|
d**********x
发帖数: 4083 | 33 这是个哲学问题
requirement是不是就等于提问回答写文档，见仁见智。
【在 l***i 的大作中提到】
: 软件开发也不是只有A一家在做把。开发的时候花上一个月搞requirement也不稀奇。面
: 世一共就30min干政事的时间，要搞这种题。。。
|
p*****2
发帖数: 21240 | 34
连requirement都没有搞什么prototype?
【在 d**********x 的大作中提到】
: 对的
: 先声明不代表公司意见。
: 上次A到我学校去招人做presentation，说他们首先是用最快的速度做一个prototype，
: 然后再iterate开发，因为没有prototype，需求都是扯淡，客户也不知道要什么，开发
: 者也不知道在扯什么。
: 当然这可能和公司风格或者是组的风格有关系。
:
: 后软
|
d**********x
发帖数: 4083 | 35 有最基本的啊，想要在最开始的时候弄清所有需求是不现实的
有点能看见的东西，才有讨论的基础。因为客户常常也不知道自己究竟想要什么东西。
prototype，
开发
【在 p*****2 的大作中提到】
:
: 连requirement都没有搞什么prototype?
|
p*****2
发帖数: 21240 | 36
那你说吧。airport的人找你要做一个shuttle scheduling 的系统。你问问需求，他们
就说你先设计吧，然后我们再讨论。这个make sense吗？如果要是一个自己熟悉的领域
，当然可以自己先发挥一下。
【在 d**********x 的大作中提到】
: 有最基本的啊，想要在最开始的时候弄清所有需求是不现实的
: 有点能看见的东西，才有讨论的基础。因为客户常常也不知道自己究竟想要什么东西。
:
: prototype，
: 开发
|
d**********x
发帖数: 4083 | 37 "我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
个classes和function signatures。"
你觉得你说的和lz描述的一样吗？抬杠就没意思了。
【在 p*****2 的大作中提到】
:
: 那你说吧。airport的人找你要做一个shuttle scheduling 的系统。你问问需求，他们
: 就说你先设计吧，然后我们再讨论。这个make sense吗？如果要是一个自己熟悉的领域
: ，当然可以自己先发挥一下。
|
p*****2
发帖数: 21240 | 38
嗯。实际情况我也不清楚。
【在 d**********x 的大作中提到】
: "我先问了一些需求，他就挤牙膏一样问一点答一点，或者说you can decide by
: yourself first, we will then check it later。好吧，我就摸着石头过河，写了几
: 个classes和function signatures。"
: 你觉得你说的和lz描述的一样吗？抬杠就没意思了。
|
F**p
发帖数: 1046 | 39 if you don't know what is an airport shuttle scheduler, you need to ask the
basic function of it. Without knowing the object, how can you do the design? |
l*****s
发帖数: 279 | 40 I think the key is to find out the details of the requirements. Some points
to consider:
1. Assume there are N points to stop and Define routes (1 or multiple)
2. Define service time frame
3. Key goal: Maximize occupancy level for the fleet/Minimize # of shuttles
running at any given time
4. Constraint: Upper bound latency (for given time frames) |
|
|
b***m
发帖数: 5987 | 41 Hotel reservation system他们也偶尔考考，大家也可以讨论一下。 |
h*u
发帖数: 122 | |
p*****2
发帖数: 21240 | 43
先说说你的思路吧。
【在 b***m 的大作中提到】
: Hotel reservation system他们也偶尔考考，大家也可以讨论一下。
|
b***m
发帖数: 5987 | 44
我就抛砖引玉瞎说两句吧。首先声明我不是什么大牛，也不是正经科班毕业，只不过在
实践中自学了一些东西而已。
碰到这种题，我一般首先假设各种条件和情况，如果跟考官心里想的情况有差别，他会
指出的。具体的条件和情况是什么其实不重要，也不是考题的本质，合理就可以了。假
设的东西先从简单的开始，然后总结出大体需要的数据，以及如何对数据进行抽象，有
哪些可能的容器（class），有哪些可能的接口（interface）。在此基础上，开始自顶
向下地写大概的class框架，以及其中的核心数据结构和成员，再根据数据罗列接口的
名字，最后再丰富和完善接口的参数。在写这些具体的class和interface时，尽量考虑
以数据结构为驱动的导向思想，也就是说，在情况和条件变化的时候，无需对class和
interface做任何修改。
不知道大家一般都怎么做这类题？
【在 p*****2 的大作中提到】
:
: 先说说你的思路吧。
|
p*****2
发帖数: 21240 | 45
大牛不要谦虚了。具体到Hotel reservation system， 你是怎么用你的方法来分析的？
【在 b***m 的大作中提到】
:
: 我就抛砖引玉瞎说两句吧。首先声明我不是什么大牛，也不是正经科班毕业，只不过在
: 实践中自学了一些东西而已。
: 碰到这种题，我一般首先假设各种条件和情况，如果跟考官心里想的情况有差别，他会
: 指出的。具体的条件和情况是什么其实不重要，也不是考题的本质，合理就可以了。假
: 设的东西先从简单的开始，然后总结出大体需要的数据，以及如何对数据进行抽象，有
: 哪些可能的容器（class），有哪些可能的接口（interface）。在此基础上，开始自顶
: 向下地写大概的class框架，以及其中的核心数据结构和成员，再根据数据罗列接口的
: 名字，最后再丰富和完善接口的参数。在写这些具体的class和interface时，尽量考虑
: 以数据结构为驱动的导向思想，也就是说，在情况和条件变化的时候，无需对class和
|
b***m
发帖数: 5987 | 46
的？
真不是谦虚，离大牛还差得远。我的特点跟印度人有些像，比较能侃，但是科班基础不
够牢。
我们可以列出这个system需要的信息：酒店的数量（连锁？），酒店的地址（或者编号
），是否有会员以及级别，reservation的来源（网络？电话？），房间数，房间类型
（Queen？King？Suite？），客人数（以及姓名等资料），每个房间停留的天数，是否
有特别要求（晚来？早走？宠物？婴儿床？朝向？残疾人方便？抽烟？），付款方式（
现金？信用卡？积分？）……这些信息列出来基本就差不多了。
在这些信息基础上，抽象出数据类型和数据库表的定义（包括索引字段等等），然后大
概可以归纳出如下容器（class）：Hotel，Client，Room，Membership……他们之间大
部分是包含的关系，然后在定义出各个interface：Reserve，Extend，Payment，
Modify……
大概就是这么个意思吧。瞎写一通，见笑了。
【在 p*****2 的大作中提到】
:
: 大牛不要谦虚了。具体到Hotel reservation system， 你是怎么用你的方法来分析的？
|
p*****2
发帖数: 21240 | 47
看来你对开房还挺熟悉呀。我可想不了这么多。这个大概要写多久呀？
【在 b***m 的大作中提到】
:
: 的？
: 真不是谦虚，离大牛还差得远。我的特点跟印度人有些像，比较能侃，但是科班基础不
: 够牢。
: 我们可以列出这个system需要的信息：酒店的数量（连锁？），酒店的地址（或者编号
: ），是否有会员以及级别，reservation的来源（网络？电话？），房间数，房间类型
: （Queen？King？Suite？），客人数（以及姓名等资料），每个房间停留的天数，是否
: 有特别要求（晚来？早走？宠物？婴儿床？朝向？残疾人方便？抽烟？），付款方式（
: 现金？信用卡？积分？）……这些信息列出来基本就差不多了。
: 在这些信息基础上，抽象出数据类型和数据库表的定义（包括索引字段等等），然后大
|
t********e
发帖数: 344 | 48 谢谢大牛……
这些需要很多人生阅历吧……
【在 b***m 的大作中提到】
:
: 的？
: 真不是谦虚，离大牛还差得远。我的特点跟印度人有些像，比较能侃，但是科班基础不
: 够牢。
: 我们可以列出这个system需要的信息：酒店的数量（连锁？），酒店的地址（或者编号
: ），是否有会员以及级别，reservation的来源（网络？电话？），房间数，房间类型
: （Queen？King？Suite？），客人数（以及姓名等资料），每个房间停留的天数，是否
: 有特别要求（晚来？早走？宠物？婴儿床？朝向？残疾人方便？抽烟？），付款方式（
: 现金？信用卡？积分？）……这些信息列出来基本就差不多了。
: 在这些信息基础上，抽象出数据类型和数据库表的定义（包括索引字段等等），然后大
|
b***m
发帖数: 5987 | 49
没写多久吧，大概也许十几分钟。
【在 p*****2 的大作中提到】
:
: 看来你对开房还挺熟悉呀。我可想不了这么多。这个大概要写多久呀？
|
b***m
发帖数: 5987 | 50
俺就是出门玩得多，这些年挣的钱都贡献给航空公司、加油站和酒店了。
【在 t********e 的大作中提到】
: 谢谢大牛……
: 这些需要很多人生阅历吧……
|
|
|
t********e
发帖数: 344 | 51 读了一下这个MIT的hand-out,http://courses.csail.mit.edu/iap/interview/Hacking_a_Google_Interview_Handout_3.pdf
我猜interviewer可能还想考察可扩展性……
可以先define an abstract Scheduler class, 然后不同的preference, e.g.,
shortest-route, shortest-waiting-time, etc.可以再implement各自的方法
总之我没有能回答好，可能挂了 |
t********e
发帖数: 344 | 52 By the way, 我一直觉得航空公司的系统超级复杂，大牛有兴趣说说设计重点么
【在 b***m 的大作中提到】
:
: 俺就是出门玩得多，这些年挣的钱都贡献给航空公司、加油站和酒店了。
|
b***m
发帖数: 5987 | 53
你是说订票系统？
【在 t********e 的大作中提到】
: By the way, 我一直觉得航空公司的系统超级复杂，大牛有兴趣说说设计重点么
|
t********e
发帖数: 344 | 54 呃，好吧，就先说说订票
【在 b***m 的大作中提到】
:
: 你是说订票系统？
|
b***m
发帖数: 5987 | 55
纯属个人意见：
航空公司订票系统的核心应该是航段信息管理，具体展开说，就是以许多城市为点构成
的有向图，以及连接这许多点的线段（也即航班）。有向图在数据库中可以表现为一条
条与日期有关的记录，而航班的核心应该是舱位管理（每个舱位对应不同的价位，分别
售出多少，根据季节选择超售的比例）。航空公司一般只允许预订未来365天的机票，
大概就是因为这样可以维护一个合理数量的“未来数据库”。在这样的抽象基础上，我
觉得后面的设计相对就清晰和容易一些了。
大家都可以说说自己的看法，我觉得设计题没有必然的正确答案，合理性、易理解性、
可扩展性应该是最重要的。
【在 t********e 的大作中提到】
: 呃，好吧，就先说说订票
|
t********e
发帖数: 344 | 56 赞，谢谢
【在 b***m 的大作中提到】
:
: 纯属个人意见：
: 航空公司订票系统的核心应该是航段信息管理，具体展开说，就是以许多城市为点构成
: 的有向图，以及连接这许多点的线段（也即航班）。有向图在数据库中可以表现为一条
: 条与日期有关的记录，而航班的核心应该是舱位管理（每个舱位对应不同的价位，分别
: 售出多少，根据季节选择超售的比例）。航空公司一般只允许预订未来365天的机票，
: 大概就是因为这样可以维护一个合理数量的“未来数据库”。在这样的抽象基础上，我
: 觉得后面的设计相对就清晰和容易一些了。
: 大家都可以说说自己的看法，我觉得设计题没有必然的正确答案，合理性、易理解性、
: 可扩展性应该是最重要的。
|
