731–740 of 851 posts
Earlier quoted context omitted.
unlucky! The buddha said we are promised two certain things in life: suffering and death. Everything else is a bonus.
Ben Franklin paraphrased: “the only things that are certain are death and taxes”.
Earlier quoted context omitted.
You're speaking as if you have experience with this but looking at your LinkedIn and previous comments, you have zero years professional software dev experience? Yet, you speak so authoritatively and decisively in this comment and your parent comment. The other people responding (including me) all have multiple years experience in actual software companies of all sizes.
I never claimed to work at a FAANG company, but I must have hit a nerve if people are going through the effort of looking at my LinkedIn profile and looking at more than the first page of my comments. Believe it or not, you don't need to have passed the tests or have software development experience to make the observation that people complaining about a process are the ones that don't perform well. I've written and g…
Actually you do.. It's one thing if you are upset about people questioning your credibility, but you are being disingenuous by making blanket statements with 0 credibility or evidence to back it up.
> only ever received complaints from students with C- grades or lower
I'm not sure what this has to do with anything being discussed. Are you implying that people with decades of experience being weeded out by these interviews somehow equate to C- grades?
By your definition, ideal0227 and mxcl are subpar.
Here're my points:
1. Supply candidate with a challenge that I built myself, tested with a co worker
2. Test should have many small goals and bugs: Get more data points on what they achieved, don't make it binary!
3. Challenge should include real bugs from when you built it. e.g. typos, wrong attribute names like 'innerHtml' instead of 'innerHTML', forgetting an import, etc.
4. Make results runnable / viewable (for front end work)
5. Explicitly tell candidate that Google is not just allowed, but expected
6. Allow candidate to ask questions so you're not dehumanizing them (but don't always give a straight answer)
7. Follow up with questions like "what do you think could be improved?"
8. If candidate spends more than 10 minutes on any of the challenges, allow them to skip it
Get as many data points as possible from an interview. Make it as close to real life as possible.
Earlier quoted context omitted.
Time pressure, foreign environments, and people watching/judging your work are all exactly the things that happen when you're developing stuff that hasn't been done. You run into problems. You find out that requirements or an API spec weren't perfectly written and have to deal with change. You have to work with other people, and they will judge you. Hard coding exercises with a time limit that have an answer that can…
You're speaking as if you have experience with this but looking at your LinkedIn and previous comments, you have zero years professional software dev experience? Yet, you speak so authoritatively and decisively in this comment and your parent comment. The other people responding (including me) all have multiple years experience in actual software companies of all sizes.
https://news.ycombinator.com/item?id=22334315 ("Looking through your LinkedIn/comments is low effort and confirmed my suspicions of you being whatever the inverse of Dunning–Kruger is") was even worse. Please don't post like that here, no matter how right you are or feel you are.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
When my classmates were preparing interview coding questions, I was working on a mini TCP implementation and a toy kernel. AWS rejected me since I failed to write prefect code to traverse a tree in level order. Google did not even give me an interview since I told the campus recruiter I have not prepared for the coding questions. Then I ended up with an internship at CoreOS and created etcd. I am glad that they did n…
So everyone got what they wanted? You did the project you wanted. AWS and Google got the code they wanted. Your friends for the jobs they wanted.
Depends, if he was still working in Big Tech Co, they could have potentially not open sourced it, they could have used his secret sauce to get better system performance compared to competitors.
Earlier quoted context omitted.
That’s a lie they tell employees to make them feel good about themselves. If they actually cared about keeping competent engineers away from competitors, their interview process would be tuned to look for engineering skills, not leetcode.
Straight from the horses mouth I once asked Gayle Lackman on quora: does their exist engineers who no matter how hard they study can NEVER make it through the google interview process? She said yes. She said that this is because Google optimizes their interviews for IQ. Not just raw knowledge.
Earlier quoted context omitted.
> Cynical answer though Honestly I don't think it's that cynical - it just makes sense. There are the people who can and will do that stuff - and do it happily - and they would presumably be the easiest to hire as junior devs. Google views it as a stepping stone towards their next product launch, and the programmers see it as a stepping stone to a more enjoyable job. And then the inventors and entrepreneurs create th…
> and typically both produce and earn more than they would've at the company. Eh, there's a lot of us who haven't done great financially but who have written a lot of open source code being run at bigcos. Being an entrepreneur requires another skill set altogether. One that I seem to lack, although I finally have come up with a solid idea in the last year that might get me somewhere whenever I'm ready to make the mov…
Earlier quoted context omitted.
Straight from the horses mouth I once asked Gayle Lackman on quora: does their exist engineers who no matter how hard they study can NEVER make it through the google interview process? She said yes. She said that this is because Google optimizes their interviews for IQ. Not just raw knowledge.
That’s incorrect. An interview process with true negatives doesn’t mean it isn’t loaded with tons of other false positives. Being good at leetcode has no relation to engineering skills, despite it being a skill in itself.
Not only are you incorrect, but you are completely off topic.
I am saying Gayle Lackman, the author of Cracking the coding interview and, in the past, one of the board members who decide on candidates in the google interview literally told me word for word that the interview optimizes for IQ. Meaning that there are tons of engineers who can spend a life time studying and never get into google because they are genetically not intelligent enough.
Understand?