※ 引述《Lenora (:))》之铭言： : - 写完code一定要先test : 在白板上或纸上coding完 : 马上代值或是最基本的base case进去检查 : 好几次我都这样马上补行error handling的code : 在interviewer指出来之前 让他们看到你自己先检查并找到问题 : 其实有时候有加分的作用 : (不过当然一开始就写得很缜密是更强的啦) Programming Interview Exposed 里面提到的流程真的蛮有用的。 我觉得不仅是面试，平常的 coding 其实也用得到。简单把书上的 流程写一下，希望对後来的人有帮助： 简单来说看到题目的第一步是找简单的例子，然後从简单的例子推 出演算法。 我通常会边在白板上写出我想得到的简单例子，然後边解释每个例 子有什麽不同点。最後画一个流程图或者口头解释需要几个 for-loop (或 recursion) 去完成这个问题。 找简单例子是最重要的步骤，通常找得到一般的例子跟特例，问题 就算解出来了。所以真的不要遇到题目 (就算以前遇过一样或类似的题 目) 就想埋头干下去... 先想一下比较安全... 通常来讲，如果你自己都觉得想到的演算法效率很差(通常是n^2) 表示出问题了，不过没什麽好怕的，因为他们预期你第一个想到的是不 好的方法，所以就算没有第一步就想到最好的方法也不算失格 :) 接着就是 implement 了。Lenora 前一篇已经有讲过一些就不再赘 述。记得 implement 之前先问一下 interviewer 你的想法是不是对的 或者说你觉得这不是最好的方法不过你第一个想到这个方法。通常他们 会很乐意跟你说他们的想法。建议：他们通常是对的。 会建议就算你觉得有更好的方法，还是先听他们的话，是因为我觉 得他们有时候就是想要看你 implement现有的方法。除非你很快的想到 而且确定更好的方法，不然跟他们争辩是很危险的事。 (我也听过那种 直到最後都不确定 interviewer到底是不是对的的例子... 不过那算是 特例...) implement 完之後就是最上面 Lenora 写的检查。检查完之後就可 以跟 interviewer说你已经完成了，他会跟你说你已经完成了，或者也 有可能问你是不是可以更快 (即使已经不可能更快... 就，跟他解释为 何不可能更快就好)，或者你的方法不是最佳解，他们会在这个时候给 点提示。 补充一个我觉得要注意的地方，就是有些语言的语法真的要清楚。 比方说读字串进来要怎麽放 delimiter，stringstream很好用可是有时 候为了效率会直接要求你对字串做处理... etc 简单就是该语言的熟悉 度要够好。 还有平常如果很少用一些资料结构，记得面试前一定要再翻一下， 像是 hashtable要怎麽宣告怎麽使用之类的... 大概就是这样罗。希望所有CS的人找工作都能顺利。 :) (也祝非CS的人找工作顺利 ^^") --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 128.148.31.177 ※ 编辑: LINK 来自: 128.148.31.86 (12/03 05:31)