若确认自己想去的公司会考 live coding,那总得练习。
就算不会,我个人认为多写一点也是好事。
笔者刚开始练习的状况十分惨烈,连最基本的 Easy 程度都常常写不出来。
恩,这样的我,或许应该要重新好好学一次资料结构和演算法,但为了赶紧面试,我还是边写边学了。
如果一开始状况不太优,推荐可以回去慢慢上演算法和资结走稳紮稳打路线。
不然第一次写题目,先不用要求自己太多。
我自己的要求是这样依序降低标准:
推荐一些资源,可以稍微翻翻选个顺眼的就好,反正重点是要做:
写得出来只是基本,这里列下 submit 过後我会做的事情:
这里不教学,请自行 Google 去复习
同样都是 O(N) 等级的 code,不同实作方式仍有很大的差异。有些人可以跑 20 ms,有些人写的要跑 100 ms,所以除了判断 big O,细节检讨是必须的。
在 Leetcode 上 submit 後会看到 runtime(ms) 和 memory(mb),以及其百分比,
先提醒这不怎麽准,Leetcode 的机器不太稳,有时候多 submit 几次可能会变慢变快几十 ms。
我觉得很有参考价值的是 Distribution 的图,可以获得的资讯有:
以分布图的情形配合百分比判断这题还需不需要多做优化
例如有时候 runtime 刚好落在多数人後面一点点,百分比可能看起来就很惨烈,但这时候可能可以归咎於机器的误差。
分布图前端的人的 code sample
看一下跑比较快的人怎麽写的、跑比较慢的人又都怎麽写的?
Solution 官方解有时候可能被锁起来要付费才能观看。
大家可能比较喜欢直接去讨论区看 optimal solution。
但我觉得需要认真弄懂不同想法怎麽来的,以及不同解法的特点。
是注重时间复杂度?还是空间换时间?有没有变动原来的 Tree node?
毕竟一个问题丢过来时,会依据状况有各种不同的需求,符合需求的解法才是真正的 optimal solution。
一开始以弄熟语言特性、语言的 Syntax,以及基础资料结构的题型为主。
开始熟悉後,或是本来就很熟悉的话,
接着建议不要用题型来分类,而是随便挑个顺眼的题目来做,
真的做不出来就照上面步骤依序降低标准,
要能训练出看到问题,去分析可能的 approach,并实际写 code 的能力。
毕竟不管是面试时还是未来实际写程序,是不会告诉你这次要用 dp 还是 greedy 解的。
我曾经和很多夥伴们一起写过题目,真的看过不按 run 只按 submit 的人XD
对一开始的我来说,因为程度关系很难自行想到各种 edge cases,
所以蛮常是 submit 後才发现某个 case 过不了,再去做修正。
但每次 submit 失败,应该要好好在脑袋跑过一次流程,确认自己的逻辑是哪里有问题,而不是照着那个特例 case 去更改 code。
请参考 Cracking the coding interview 6th Edition p.66 关於 Test 的技巧
大概写 Leetcode 注意的点就这样,
比我写得好的人大有人在,比我懂面试的人大有人在,
有空一定要翻个书爬个文,汲取一下前人智慧。
就算一开始再怎麽菜,只要保持谦逊,
把写 Leetcode 变成有成就感的事情并持续进步,
时间是最好的投资。
明天进 String~
Case01 跟 Day06、Day08 范例差不多,重点差异如下: Controller 於 Ge...
现在的企业会使用一些管理系统来管理人力等资源,而这些管理系统通常都会有所谓的 权限设计 (Permi...
昨天练习了Cross site scripting 今天来讲讲由Google提供来协助开发人员 一个...
.net core web api 可以和任何前端Client端技术或框架(javascript ,...
bubble sort的概念就是像泡泡一样 ,越大的数字会渐渐的往右边浮 比较相邻的元素 ,两两比...