睇嚟師兄有睇clean code呢本書
On the other hand, 香港人睇沙紙同有無charter, 有咪專業囉，但小弟認為態度最重要
我都仲識有人係呢一行打拼，無論大過或細過我嘅都有，要做一定有得做。只係如果想發達就唔好㨂呢行喇
有冇人係做左好耐programmer唔想做又轉唔到行？
羅生門
755 回覆
68 Like
3 Dislike
第 1 頁第 2 頁第 3 頁第 4 頁第 5 頁第 6 頁第 7 頁第 8 頁第 9 頁第 10 頁第 11 頁第 12 頁第 13 頁第 14 頁第 15 頁第 16 頁第 17 頁第 18 頁第 19 頁第 20 頁第 21 頁第 22 頁第 23 頁第 24 頁第 25 頁第 26 頁第 27 頁第 28 頁第 29 頁第 30 頁第 31 頁
有其他興趣就做其他嘢喇，自己唔鐘意嘅嘢做得好辛苦㗎
呢啲LeetCode問題嚟，有得刷
想問下寫WEB有咩安全野要學?
師兄做邊樣
係 唔好盲目見人話好景就做
我明你講咩
咁其實好多神人連大學都冇讀
咁點解要開學位 直接請中學生好過
咁其實好多神人連大學都冇讀
咁點解要開學位 直接請中學生好過
其實我覺得大學教育唔係教你知識，係教你尋找知識既方法；
同埋係入面係一個好好既訓練你點待人處事。
同你個人本身既compentence 係無關係。
同埋係入面係一個好好既訓練你點待人處事。
同你個人本身既compentence 係無關係。
其實香港大部分工種中學生夠做
日本唔少人都係讀完高中/短大(asso)就入社，佢地唔係咩神人
大學中退再入社都有
人地社會分得清楚，讀書還讀書，做野還做野
入左社就由頭train過，咩major中學定大學都一樣
香港人成日將學位同工作掛勾，好易將個scope縮到得返專科
大學唔係職業訓練所，係教你諗野開拓視野搞學術既地方
日本唔少人都係讀完高中/短大(asso)就入社，佢地唔係咩神人
大學中退再入社都有
人地社會分得清楚，讀書還讀書，做野還做野
入左社就由頭train過，咩major中學定大學都一樣
香港人成日將學位同工作掛勾，好易將個scope縮到得返專科
大學唔係職業訓練所，係教你諗野開拓視野搞學術既地方
巴打 可唔可以講下你咩學歷
文化唔同
日本大公司預你入嚟做一世
入嚟慢慢train梗係ok
香港除咗mt 個個頭幾年都係咁跳
(就算mt都好多跳嚟跳去)
啲公司邊想慢慢train人
日本大公司預你入嚟做一世
入嚟慢慢train梗係ok
香港除咗mt 個個頭幾年都係咁跳
(就算mt都好多跳嚟跳去)
啲公司邊想慢慢train人
你似乎好睇穿哂成個社會啵
其實正常既，識曬呢啲既人intern都賺到20k up，我識得一個
你golang玩backend？去到邊個程度，如果有大量business要scale up，你係點樣manage
，LM學野
，LM學野無呀，見內地啲人玩得咁高興咪搵嚟學下。話哂都出左十年，內地又大把projects上左production 。
咩程度我自己都都答唔上，但不竟寫左曲咁多年，要pick up唔難，但要寫得好organized 好似寫爪哇咁又未得。同埋寫左OO呢個paradigm 太耐，好多時習慣左polymorphism 唔慣composite，個mindset要改下。
scale up 依小弟禺見可以試下go modules，都幾易migrate到，新舊projects都可以好易。
BTW, v1.13 Error package 我都未得閒跟，我都係學習中，有興趣咪大家交流下，唔敢講有咩學到，但好過一個埋頭砌。
咩程度我自己都都答唔上，但不竟寫左曲咁多年，要pick up唔難，但要寫得好organized 好似寫爪哇咁又未得。同埋寫左OO呢個paradigm 太耐，好多時習慣左polymorphism 唔慣composite，個mindset要改下。
scale up 依小弟禺見可以試下go modules，都幾易migrate到，新舊projects都可以好易。
BTW, v1.13 Error package 我都未得閒跟，我都係學習中，有興趣咪大家交流下，唔敢講有咩學到，但好過一個埋頭砌。
其實我既意思係Scale up business logic，唔係scale up business。打漏左
。打漏左咁應該都答左，composite
https://www.zhihu.com/question/350929200/answer/864694828
同佢講返 寫homebrew 果個max howell 都唔識 invert binary tree la
leetcode easy level 黎
同佢講返 寫homebrew 果個max howell 都唔識 invert binary tree la
leetcode easy level 黎
其實出黎做野係唔係無咩機會用到algo
我都想知
除左做R&D會用到外
Software development 會唔會係做d low level既先會用到
做咁耐都用唔到 最多咪call library 知道哂situation 用邊隻data structure 都好似好夠
除左做R&D會用到外
Software development 會唔會係做d low level既先會用到
做咁耐都用唔到 最多咪call library 知道哂situation 用邊隻data structure 都好似好夠
考algo只係一種篩人嘅方式,同你之後做嘅嘢未必真係好息息相關
啲公司覺得用呢種方式起碼確保到false positive candidate比較少,而就算有Max Howell呢啲false negative都可以接受
詳情可以睇吓Cracking the Coding Interview呢本書
啲公司覺得用呢種方式起碼確保到false positive candidate比較少,而就算有Max Howell呢啲false negative都可以接受
詳情可以睇吓Cracking the Coding Interview呢本書
但個問題係做咗幾年野用唔到algo
轉工又問返Algo
分分鐘啱啱大學畢業嘅時候仲熟過依家
用作篩選但唔係問返工作要用到嘅嘢咁篩選黎 做咩
雖然我有聽講過外國都係咁做
不過個趨勢好似有啲變緊
轉工又問返Algo
分分鐘啱啱大學畢業嘅時候仲熟過依家
用作篩選但唔係問返工作要用到嘅嘢咁篩選黎 做咩
雖然我有聽講過外國都係咁做
不過個趨勢好似有啲變緊
我直接引返本書講既野啦:
Why?
This is one of the most common questions candidates have as they get started with this process. Why do things this way? After all,
1. Lots of great candidates don't do well in these sorts of interviews.
2. You could look up the answer if it did ever come up.
3. You rarely have to use data structures such as binary search trees in the real world. If you did need to, you could surely learn it.
4. Whiteboard coding is an artificial environment. You would never code on the whiteboard in the real world, obviously.
These complaints aren't without merit. In fact,l agree with all of them, at least in part.
At the same time, there is reason to do things this way for some-not all-positions. It's not important that you agree with this logic, but it is a good idea to understand why these questions are being asked. It helps offer a little insight into the interviewer's mindset.
False negatives are acceptable.
This is sad (and frustrating for candidates), but true.
From the company's perspective, it's actually acceptable that some good candidates are rejected. The company is out to build a great set of employees.They can accept that they miss out on some good people. They'd prefer not to, of course, as it raises their recruiting costs. It is an acceptable tradeoff, though, provided they can still hire enough good people.
They're far more concerned with false positives: people who do well in an interview but are not in fact very good.
Problem-solving skills are valuable.
If you're able to work through several hard problems (with some help, perhaps), you're probably pretty good at developing optimal algorithms. You're smart.
Smart people tend to do good things, and that's valuable at a company. It's not the only thing that matters, of course, but it is a really good thing.
Why?
This is one of the most common questions candidates have as they get started with this process. Why do things this way? After all,
1. Lots of great candidates don't do well in these sorts of interviews.
2. You could look up the answer if it did ever come up.
3. You rarely have to use data structures such as binary search trees in the real world. If you did need to, you could surely learn it.
4. Whiteboard coding is an artificial environment. You would never code on the whiteboard in the real world, obviously.
These complaints aren't without merit. In fact,l agree with all of them, at least in part.
At the same time, there is reason to do things this way for some-not all-positions. It's not important that you agree with this logic, but it is a good idea to understand why these questions are being asked. It helps offer a little insight into the interviewer's mindset.
False negatives are acceptable.
This is sad (and frustrating for candidates), but true.
From the company's perspective, it's actually acceptable that some good candidates are rejected. The company is out to build a great set of employees.They can accept that they miss out on some good people. They'd prefer not to, of course, as it raises their recruiting costs. It is an acceptable tradeoff, though, provided they can still hire enough good people.
They're far more concerned with false positives: people who do well in an interview but are not in fact very good.
Problem-solving skills are valuable.
If you're able to work through several hard problems (with some help, perhaps), you're probably pretty good at developing optimal algorithms. You're smart.
Smart people tend to do good things, and that's valuable at a company. It's not the only thing that matters, of course, but it is a really good thing.
Basic data structure and algorithm knowledge is useful.
Many interviewers would argue that basic computer science knowledge is, in fact, useful. Understanding trees, graphs, lists, sorting, and other knowledge does come up periodically. When it does, it's really valu- able.
Could you learn it as needed? Sure. But it's very difficult to know that you should use a binary search tree if you don't know of its existence. And if you do know of its existence, then you pretty much know the basics.
Other interviewers justify the reliance on data structures and algorithms by arguing that it's a good "proxy:' Even if the skills wouldn't be that hard to learn on their own, they say it's reasonably well-correlated with being a good developer. It means that you've either gone through a computer science program (in which case you've learned and retained a reasonably broad set of technical knowledge) or learned this stuff on your own. Either way, it's a good sign.
There's another reason why data structure and algorithm knowledge comes up: because it's hard to ask problem-solving questions that don't involve them. It turns out that the vast majority of problem-solving questions involve some of these basics. When enough candidates know these basics, it's easy to get into a pattern of asking questions with them.
Whiteboards let you focus on what matters.
It's absolutely true that you'd struggle with writing perfect code on a whiteboard. Fortunately, your inter- viewer doesn't expect that. Virtually everyone has some bugs or minor syntactical errors.
The nice thing about a whiteboard is that, in some ways, you can focus on the big picture. You don't have a compiler, so you don't need to make your code compile. You don't need to write the entire class definition and boilerplate code. You get to focus on the interesting, "meaty" parts of the code: the function that the question is really all about.
That's not to say that you should just write pseudocode or that correctness doesn't matter. Most inter- viewers aren't okay with pseudocode, and fewer errors are better.
Whiteboards also tend to encourage candidates to speak more and explain their thought process. When a candidate is given a computer, their communication drops substantially.
Many interviewers would argue that basic computer science knowledge is, in fact, useful. Understanding trees, graphs, lists, sorting, and other knowledge does come up periodically. When it does, it's really valu- able.
Could you learn it as needed? Sure. But it's very difficult to know that you should use a binary search tree if you don't know of its existence. And if you do know of its existence, then you pretty much know the basics.
Other interviewers justify the reliance on data structures and algorithms by arguing that it's a good "proxy:' Even if the skills wouldn't be that hard to learn on their own, they say it's reasonably well-correlated with being a good developer. It means that you've either gone through a computer science program (in which case you've learned and retained a reasonably broad set of technical knowledge) or learned this stuff on your own. Either way, it's a good sign.
There's another reason why data structure and algorithm knowledge comes up: because it's hard to ask problem-solving questions that don't involve them. It turns out that the vast majority of problem-solving questions involve some of these basics. When enough candidates know these basics, it's easy to get into a pattern of asking questions with them.
Whiteboards let you focus on what matters.
It's absolutely true that you'd struggle with writing perfect code on a whiteboard. Fortunately, your inter- viewer doesn't expect that. Virtually everyone has some bugs or minor syntactical errors.
The nice thing about a whiteboard is that, in some ways, you can focus on the big picture. You don't have a compiler, so you don't need to make your code compile. You don't need to write the entire class definition and boilerplate code. You get to focus on the interesting, "meaty" parts of the code: the function that the question is really all about.
That's not to say that you should just write pseudocode or that correctness doesn't matter. Most inter- viewers aren't okay with pseudocode, and fewer errors are better.
Whiteboards also tend to encourage candidates to speak more and explain their thought process. When a candidate is given a computer, their communication drops substantially.