bug free 相当于默写课文 标点符号都要对 赞裸考。题目是要干嘛啊 meonline 发表于 2022-04-22 22:07
leetcode hard 题目能做出， 还能悲剧？ 估计是故意黑楼主的。 你说说是哪道题吧， 我可以评判一下。 leetcode 的难度有时也不那么一致的。 gokgs 发表于 2022-04-22 22:11
今天参加了一个面试，被考现场做题。对方出了一个题，我听他把题目要求巴拉巴拉描述完，又自己读了一遍题，还是没明白这题到底是要干啥？我就挺郁闷，问对方，让他给解释题目要求，来回几次才终于问清楚了，哦，这题是要干啥。搞明白了到底要干啥，好像也不难哦。 然后就做呗，十五分钟写完了，run一下，输出结果不对。然后我就根据结果，检查我写的代码，看出来刚才我写错的地方，有两三个小失误，改了过来，再run就对了。 面试完，我就拿题的关键字一搜，果然又是LC上的题，难度还是hard。这题就是hard？还是比较surprise的。 hard题我TM没见过，当场现读题现做，刷刷就能写出来还能做对，好像我的水平比我之前以为的还要高啊。 但面试估计又悲剧了，因为我没见过题，问来问去才问明白这题是啥意思，十有八九会被说communication有问题。还有写出来有bug，也会因为这个被挂，反正不抱啥希望了。 要是刷过题的话，communication那是好啊。看到题顿时就直接明白要干啥，半句废话都没有，直接开始干，这communication能力刚刚的哦。 我也不懂现在要求的bug free有什么意思。版上做马工的，你们平时工作中写代码，难道咣咣敲完之后，不要把自己写的代码run一下，看看跑的对不对，不对的话回来检查一下哪儿错了，改过来不就完了，多大点事？难道一般不是这样的吗。工作中真有人expect你把一堆代码咣咣敲完，就不用test不用debug，一个错误都没有就直接能拿去用？要Bug free，直接把答案一个字不差背下来，那倒是能bug free，我记得上小学的时候，语文老师要求背诵课文，检查默写，一个字不差默写下来就被老师表扬呢。 还有我也不明白，现在这么个搞法，题区分easy medium hard还有什么意义，如果expectation都是背答案的话，背起来难度不都是一样的？要说难度高低，那就是答案越长的难度就越高呗，跟题的难度无关，跟答案长短有关呗？ 现在这世界真是看不懂了。版上牛人多，给指点一下迷津吧。 小城往事 发表于 2022-04-22 22:05
存在就是合理的，你改变不了，那就适应 hunose 发表于 2022-04-22 22:22
怎么说呢，如果面试都做不到bug free，工作应该很差的。 别的不说，很多印度人面试技巧，有一个，就是纸上编程，还能做到面试题bug free，我们有时候嘲笑印度人，但有一大部分印度人面试准备非常充分的 minqidev 发表于 2022-04-22 22:29
回复 13楼的帖子 面试你连准备都不愿意了，雇主怎么能相信如果有工作给你，你会准备？ 题目都是LC上的了，准备和不准备，面试的人一眼就能看出来。其实题目只要知道是什么，稍微有经验的人，准备准备，是能够应付面试的 minqidev 发表于 2022-04-22 22:37
背题是不行的，题很多，而且面算法的目的并不是单纯把题做出来。更重要的是看分析问题解决问题的能力。 很多大厂面试都不能run的，得用脑子做dry run 。因为到了实际环境中，不是所有的情况都可以跑test，那些不能跑test的情况就只能依靠人了。bug free并不是说代码需要一次性写对，也是看是不是能捕捉到edge case，并且用dry run 把bug找出来。四五六 发表于 2022-04-23 12:39
再多说一句，hard的题能做出来也不一定就是过了。有些题暴力破解是不难的，可是如果加上时间复杂度和空间复杂度的要求，就难了。四五六 发表于 2022-04-23 12:44
熬一熬吧，熬到senior， LC的影响因子就小了。 ted.hanks 发表于 2022-04-23 12:47
面试官会给TC复杂度要求啊，谁暴力解来个O n方的解法，当场就会被喊你优化了 alexpeppers 发表于 2022-04-23 13:01
communication是说通过交流在resolve ambiguity 并不是说一下听懂题就是communication 好 又不是考英文阅读理解 verayao 发表于 2022-04-23 13:11
是的，大厂面试，没写出时空最优解，都不敢说自己过。 因为这是竞争择优录取，是 competition 而不是 qualification，问题是跟招工市场上的竞争对手比，你不知道竞争对手是不是写出时空最优解。 而大厂的录取率众所周知的低，好比百里挑一选系花的问题。刷题面试不是最好的办法，但是目前似乎可行的办法，虽然会有 false negatives。 tidewater 发表于 2022-04-23 12:54
的确是这样，我面试的时候，如果candidate的答案给得不够好而且还不能理解hint的话我不会把正确答案告诉对方，所以candidate面试完也许自我感觉很好，觉得自己都做出来了，其实可能离最优解还有距离。楼主连面试题目都看不懂的话大概率会fail，因为很多时候马公面试是考problem solving skills，而不光是coding skills，面试会看你有没有问正确的问题，解题思路是什么样的，能不能利用interviewer的hint来扩展解题思路p，而不光是最后有没有做出正确答案。至于code有bug，要看到底是不是比较严重的问题，不能以bug的数量作为唯一标准。 ILoveEcho 发表于 2022-04-23 14:25
据我的经验，你要是认为对方是因为不是bug free 才拒了你，大概率是你没认识到别的更大的错误。当然，个例会有的。 好多大厂根本不要求你代码能通过编译，更不用说运行了，二三线厂子可能会更強调程序能运行才行。 gokgs 发表于 2022-04-23 14:33
我面人coding的时候只要方向对能讲明白time／space complexity就给过了 fntan 发表于 2022-04-22 23:49
我觉得lz挺好的，该给过，题目看不懂就问，问到懂为止，总比不懂装懂自己瞎做的好吧？communication skillset不就是要求comunicate，提问题就是communicate么，code debugging也很正常，谁写的一遍就能run的，试行错误的纠正能力在日常过程中应该被evaluated心函 发表于 2022-04-23 12:25
确实，现在的面试很无语，招一堆只会刷题的就特别有用吗？很多基本的操作技术都不懂Monicaliu11 发表于 2022-04-23 12:29
只会刷题一百分，进来才是哑巴吃黄连 BestThingsGivenToMe 发表于 2022-04-23 18:13
这也是竞争，不是绝对的 bug free，而是同样去面试的一群人，bug 超过平均值，就肯定减分。 不要说 bug free 了，我朋友曾经有 interview 的 feedback 里，有一个 feedback 是 coding style 里变量名太短，不够 intuitive 。。。 其实那人平时的变量名太长，PR 有曾经被 review 这变量名也别太长了 。。。 纯属 interview 要拼速度，要边说边写 code，并且 online CodePad 的敲键盘 latency 比 local VSCode 长，外加 interview 时的 Bluetooth keyboard 的 latency 更长一些（可能跟同时用 Bluetooth 耳机等等有关？）。 顺便岔开提一句：VSCode SSH，在 latency 这点，相对于 ssh terminal 上跑 emacs，敲键盘的 latency 是个很大的进步。因为用 ssh remote file 而不是 terminal 字符的连接。当然，在 terminal 窗口没办法。但是 VScode integrated terminal，现在有 grayed text （也就是键已经敲进去，但 ssh round trip 还没有回来），也是一个很好的 feedback，避免影响敲键速度。 当然，后来那朋友根据 interview 的 explicit and implicit feedback，换成 wired mechanical keyboard ... problem solved :) 不过还是有好处的，interview feedback 其实帮助将来工作提高 productivity 。。。 有时候键盘鼠标还有 editor 的选择，加上 latency，确实可能潜移默化的影响 productivity，毕竟都是一边敲键盘一边还思考。 tidewater 发表于 2022-04-23 14:45
这个。。。其实不需要interview的feedback，显然是有线键盘更快，此外推荐ethernet连接，效果更显著 chairsky 发表于 2022-04-23 19:26
这才是明智。只是单纯会考题，和只是单纯用不想干最难的题来难考生，都是耍流氓 BestThingsGivenToMe 发表于 2022-04-23 18:02
说的有道理。 但这里的前提是，考官自己经常做题，并且跟考题的水平相对应。 否则的话，就好比华人版推妈看了数学竞赛的标准答案以后，面试 USAMO National 500 强 。。。 我这里不是板砖推妈，而是说面试和判卷的区别 。。。 图灵说了，马工面试本质上是图灵测试。 而实话实说，就算是当年 ACM-ICPC 级别的娃，也应该好久不刷竞赛了吧。否则是强迫症患者。 tidewater 发表于 2022-04-23 19:20
你说得没错，我在用一道interview问题之前会先自己做做看难度如何，而且一道问题用多了就比较清楚题目难度如何和candidate的相对水平如何。 讲到coding，如果有些syntax方面的typo，或者是一些小的corner case没有考虑到，我觉得可以接受，因为面试情况下本身就压力很大，有些小错误可以理解。楼上说的变量名太短对于工作时间比较长的candidate来说我会觉得是个red flag，但是如果对方解释一下说因为interview时间有限所以变量名简写，我会接受对方的解释。如果是一些基本的问题，比如说recursion没有base condition，或者该写helper function不写的情况，那也都是red flag。总而言之，是否推荐录取一个candidate，是看这个人的面试综合情况，而不是简单的是不是写出了bug free的code。如果碰到国人，在可上可下的情况下，我一般会给对方一个高一点的rating。 ILoveEcho 发表于 2022-04-23 20:01
然后就做呗，十五分钟写完了，run一下，输出结果不对。然后我就根据结果，检查我写的代码，看出来刚才我写错的地方，有两三个小失误，改了过来，再run就对了。
面试完，我就拿题的关键字一搜，果然又是LC上的题，难度还是hard。这题就是hard？还是比较surprise的。
hard题我TM没见过，当场现读题现做，刷刷就能写出来还能做对，好像我的水平比我之前以为的还要高啊。
但面试估计又悲剧了，因为我没见过题，问来问去才问明白这题是啥意思，十有八九会被说communication有问题。还有写出来有bug，也会因为这个被挂，反正不抱啥希望了。
要是刷过题的话，communication那是好啊。看到题顿时就直接明白要干啥，半句废话都没有，直接开始干，这communication能力刚刚的哦。
我也不懂现在要求的bug free有什么意思。版上做马工的，你们平时工作中写代码，难道咣咣敲完之后，不要把自己写的代码run一下，看看跑的对不对，不对的话回来检查一下哪儿错了，改过来不就完了，多大点事？难道一般不是这样的吗。工作中真有人expect你把一堆代码咣咣敲完，就不用test不用debug，一个错误都没有就直接能拿去用？要Bug free，直接把答案一个字不差背下来，那倒是能bug free，我记得上小学的时候，语文老师要求背诵课文，检查默写，一个字不差默写下来就被老师表扬呢。
还有我也不明白，现在这么个搞法，题区分easy medium hard还有什么意义，如果expectation都是背答案的话，背起来难度不都是一样的？要说难度高低，那就是答案越长的难度就越高呗，跟题的难度无关，跟答案长短有关呗？
现在这世界真是看不懂了。版上牛人多，给指点一下迷津吧。
真的哦，代码标点符号错一个，run出来都不对，都算有bug。要说起来，比小学背课文默写难多了，课文光把字默写对就行了，把那个地方的句号写出逗号也不至于扣分。
唉，不想说哪道题了。估计我遇到的恰好就是那种被归类为hard的题里面的相对最水的吧。
存在就是合理的，你改变不了，那就适应
是啊是啊，要不还能咋办呢，咱也就发帖牢骚两句，完事该干啥还得干啥。
别的不说，很多印度人面试技巧，有一个，就是纸上编程，还能做到面试题bug free，我们有时候嘲笑印度人，但有一大部分印度人面试准备非常充分的
他们这样准备过之后，被考准备过的题应该肯定没问题，但如果被考到没准备过的题，也一样能做到一遍bug free吗
面试你连准备都不愿意了，雇主怎么能相信如果有工作给你，你会准备？
题目都是LC上的了，准备和不准备，面试的人一眼就能看出来。其实题目只要知道是什么，稍微有经验的人，准备准备，是能够应付面试的
狗屁逻辑
全世界的面试，面试题都是造火箭，工作画UI， 不乐意，可以自己大公司不面试去招人，这就是为什么IT公司愿意要印度人的原因。有证书，面试题准备好，就是这么一回事
这位霸气侧漏得让我敬畏，觉得好厉害。
几家大厂面试确实很难通过。不行就多面试一些小厂，一旦有差不多的 offer 从了就好了。
我面人coding的时候只要方向对能讲明白time／space complexity就给过了
这个是相对的。周围进大厂的不多，有几个就是在家刷题半年的。刷题一月跟刷题半年就是不在同一起跑线上。
我个人不反对大厂的刷题面试模式。实践上而言，虽然很多朋友屡败屡战，过不了大厂刷题面试。但第一毕竟大厂给了面试机会，第二如果哪天真的找不到工作了，那刷题半年至少有条后路的可能性。
是的，大厂面试，没写出时空最优解，都不敢说自己过。
因为这是竞争择优录取，是 competition 而不是 qualification，问题是跟招工市场上的竞争对手比，你不知道竞争对手是不是写出时空最优解。
而大厂的录取率众所周知的低，好比百里挑一选系花的问题。刷题面试不是最好的办法，但是目前似乎可行的办法，虽然会有 false negatives。
面试官会给TC复杂度要求啊，谁暴力解来个O n方的解法，当场就会被喊你优化了
Senior 人家刷 system design 题，更是刷。
因为面试官也不一定有很多实际的 system design 的经验，system design 还分具体的 application domain。过面试都得刷。
问题是不知道是不是存在更优解。
Communicate the known 比 communicate the unknown 总是容易很多吧。相对比较而言的。
的确是这样，我面试的时候，如果candidate的答案给得不够好而且还不能理解hint的话我不会把正确答案告诉对方，所以candidate面试完也许自我感觉很好，觉得自己都做出来了，其实可能离最优解还有距离。楼主连面试题目都看不懂的话大概率会fail，因为很多时候马公面试是考problem solving skills，而不光是coding skills，面试会看你有没有问正确的问题，解题思路是什么样的，能不能利用interviewer的hint来扩展解题思路p，而不光是最后有没有做出正确答案。至于code有bug，要看到底是不是比较严重的问题，不能以bug的数量作为唯一标准。
好多大厂根本不要求你代码能通过编译，更不用说运行了，二三线厂子可能会更強调程序能运行才行。
除非你很senior, 哈哈
这些说的都有道理，但关键在于 competition 而不是 qualification，外加百里挑一，一般人很难知道自己是不是过了 coding 关。
或者用高中大学的学科竞赛比方，竞赛考完根本没法知道自己是不是过关。
你不知道阿，刷题还是很不容易的，经常刷了就忘了，哈哈
这也是竞争，不是绝对的 bug free，而是同样去面试的一群人，bug 超过平均值，就肯定减分。
不要说 bug free 了，我朋友曾经有 interview 的 feedback 里，有一个 feedback 是 coding style 里变量名太短，不够 intuitive 。。。 其实那人平时的变量名太长，PR 有曾经被 review 这变量名也别太长了 。。。 纯属 interview 要拼速度，要边说边写 code，并且 online CodePad 的敲键盘 latency 比 local VSCode 长，外加 interview 时的 Bluetooth keyboard 的 latency 更长一些（可能跟同时用 Bluetooth 耳机等等有关？）。
顺便岔开提一句：VSCode SSH，在 latency 这点，相对于 ssh terminal 上跑 emacs，敲键盘的 latency 是个很大的进步。因为用 ssh remote file 而不是 terminal 字符的连接。当然，在 terminal 窗口没办法。但是 VScode integrated terminal，现在有 grayed text （也就是键已经敲进去，但 ssh round trip 还没有回来），也是一个很好的 feedback，避免影响敲键速度。 当然，后来那朋友根据 interview 的 explicit and implicit feedback，换成 wired mechanical keyboard ... problem solved :)
不过还是有好处的，interview feedback 其实帮助将来工作提高 productivity 。。。 有时候键盘鼠标还有 editor 的选择，加上 latency，确实可能潜移默化的影响 productivity，毕竟都是一边敲键盘一边还思考。
这才是明智。只是单纯会考题，和只是单纯用不想干最难的题来难考生，都是耍流氓
说的好。不懂就问才是交通。工作中靠自己猜和一意孤行才是没有communication skills。
只会刷题一百分，进来才是哑巴吃黄连
大厂是 general interview，interview 的人大部分跟自己的组没啥关系吧。
说的有道理。
但这里的前提是，考官自己经常做题，并且跟考题的水平相对应。
否则的话，就好比华人版推妈看了数学竞赛的标准答案以后，面试 USAMO National 500 强 。。。 我这里不是板砖推妈，而是说面试和判卷的区别 。。。 图灵说了，马工面试本质上是图灵测试。
而实话实说，就算是当年 ACM-ICPC 级别的娃，也应该好久不刷竞赛了吧。否则是强迫症患者。
这个。。。其实不需要interview的feedback，显然是有线键盘更快，此外推荐ethernet连接，效果更显著
有线机械键盘肯定更快，但平时不一定自己意识到。另外 latency 是 add up 的，没超过一定 threshold 也不一定意识到。
有线 Ethernet 当然更快，但一般没这个必要。因为就算光缆上桌面，大部分人也还是过不了大厂面试，毕竟百里挑一。lol 。而平时上班根本不需要这么狠。No Z turn。
这个对大厂 general interview 根本不可行，因为大厂 general interview 的目标并不是 be nice，而是 screen，百里挑一的 screen。
所以大厂 interview，对大厂而言，还真是唯一可行方案，因为真正做到了在给定的 cost 限制下，足够好地百里挑一 screen。
你说得没错，我在用一道interview问题之前会先自己做做看难度如何，而且一道问题用多了就比较清楚题目难度如何和candidate的相对水平如何。
讲到coding，如果有些syntax方面的typo，或者是一些小的corner case没有考虑到，我觉得可以接受，因为面试情况下本身就压力很大，有些小错误可以理解。楼上说的变量名太短对于工作时间比较长的candidate来说我会觉得是个red flag，但是如果对方解释一下说因为interview时间有限所以变量名简写，我会接受对方的解释。如果是一些基本的问题，比如说recursion没有base condition，或者该写helper function不写的情况，那也都是red flag。总而言之，是否推荐录取一个candidate，是看这个人的面试综合情况，而不是简单的是不是写出了bug free的code。如果碰到国人，在可上可下的情况下，我一般会给对方一个高一点的rating。
但一见钟情这玩意儿，只能个人掌握，因为没有统一标准 。。。 而大厂不是为一个系花找一个系草，而是为一千个系花找一千个系草 。。。 而且为了提高面试效率，还得让北大系花，去面试裤子大系花的 candidate 男友 。。。
这样一来，就必须要有一个 screen 系草的客观标准 。。。比如是不是帅到能够戴进标准黄金比例面具。
当然插一句，著名大帅哥校草休格兰特同学，是不是能戴进标准黄金比例面具，不好说。
无轨电车开回来，而一旦有了黄金比例面具，那韩国整容医学界自然就乐开了花。
这是个两难推理，是无解的 。。。 我觉得唯一的解法，并不是要干预大厂的招人刷题面试标准。而是不能让大厂垄断，包括在人才市场上的垄断 。。。 这样小厂才能生存，而 Homebrew 的作者 和 WhatApps 的奠基人，才有机会感谢大厂面试不录取之恩 。。。 而小厂也可以根据自己具体情况，用不完全相同的面试录用标准。
LZ表现应对都挺好的。我要是考官就让你过
这个回到最后，还是在于百里挑一的 screen 的要求。
而这里百里挑一的入围资格，是有资格拿到大厂面试的。放在 National Percentiles 里，就是万里挑一。
而按照当年高中竞赛的比例，人群里万里挑一，已经是学科竞赛水平了。
前面调侃的例子，说的是学科竞赛题目的 non-routine nature 。。。 也就是说，就算是在讨论全真题，理论上，也是刷历年 IMO 考题，准备考明年 IMO 的思路，non-routine 。。。 而不是刷历年 IMO 考题，然后机考 IMO-ish 题库，属于 routine 。。。 当然扯远了。
不过说到底还是这个百里挑一、万里挑一的 screen 要求 。。。 我个人觉得目前的刷题系统是差不多最优化的方案，我不认为有更好的刷题面试方案 。。。 或者说，更重要的是保证反垄断法，而不是干预或者硬性要求大厂的刷题面试系统。
同理，也不能因为大厂的刷题面试系统有各种欠缺，就说这个系统不可行 。。。 当然，客观讨论欠缺是可以的。
从 constructive algorithm 的角度，只有拿得出另一个比刷题面试更好的系统（对于大厂而不是小厂而言），那才能说把大厂的刷题面试系统下线。
而事实而言，对于目前的情况，在有反垄断法的大前提下，大厂的刷题面试系统，目前而言，还是现实世界里最最可行的系统。
但另一方面，没刷进大厂的，基本都刷进了小厂 。。。 小厂也是厂不是？
如果没有刷题面试，那小厂也进不去，长期失业 。。。 那才是大问题。
其实你说的有一定道理。如果在别无选择的情况下，不花上几个月好好准备面试都不准备，确实没有理由相信会为工作而准备。
但现实世界中，很多人并不是别无选择。花几个月的时间刷题面试，并不是每一个人的最优选项。
况且还有发挥的问题，也不是说花上几个月时间准备之后，能够保证面试突围的。
现实世界很复杂。有点像多人囚徒困境问题。无法简单的一刀切 Nash 平衡点。