https://www.caltech.edu/about/legacy/awards-and-honors/nobel...
...also has to offer a whole course to prep for job interviews :-|
281–290 of 336 posts
https://www.caltech.edu/about/legacy/awards-and-honors/nobel...
...also has to offer a whole course to prep for job interviews :-|
My career path in tech so far has been junior engineer -> mid level -> senior -> tech lead. As I've progressed through that path, I have had literally no opportunities of applying the stuff I've learnt on HackerRank, save for a couple of interviews. At this point I'm convinced that the focus of those interviews was entirely wrong. Once you pass those tests and get hired, you will be dealing with tons of legacy code r…
The very act of extrapolating how a person would perform based on a brief snapshot in time seems flawed. It is unreasonable to task the interviewer with making a good decision with barely any data.
I used to think that a well calibrated question bank or interview style could be a reliable signal. But the moment you ask something specific is the moment you don’t ask everything else. A poor performing but good candidate’s strengths could lie in the latter category and a well performing but bad candidate’s strengths could be in the former.
There needs to be a reliable and credible way to learn about a persons strengths and weaknesses based on their track record.
I’d weight credible reference checks, previous projects and credentials more than their actual interview performance.
Tech interview discussions always seem to run the same course and hit the same points, so I'll repeat one of mine: What's wrong with the idea of turning the standard Leetcode algorithms interview into a license that only needs to be completed once, or maybe once every 5-8 years, similar to what physicians must undergo? Much more efficient than having to retake it with every single company during an interview cycle.
Earlier quoted context omitted.
> You are better off asking trivia questions Bet you most people would disagree with just trivia. > So does studying for leetcode for hours. You honestly do not have to do this to pass the LC interview. I didn't. Certainly not as much as a takehome test.
> You honestly do not have to do this to pass the LC interview. I didn't. You were able to prep for 2-4 hours and still pass LC interviews? I find this hard to believe given that I, and peers I know, took much longer to prep.
3 easy problems, 4 medium problems, and 3 hard problems.
It would make sense to count 2 additional hard problems that I worked on (with pencil and paper) but didn't submit a working solution for.
This is more than four hours of work, but it's much less work than people suggested was necessary. (For example, my recruiter strongly believed that candidates needed a minimum of 5 weeks to prepare for an interview.) I wasn't really able to make myself do more leetcode, because whenever I started working on it, what I really wanted to do was to write up proofs that the algorithms were correct, not to submit a solution to one and move on to the next one. (OK, it passed all the test cases, but what if that's just a coincidence?)
But writing up a formal proof can easily chew up most of your day, and it does nothing for you in terms of practicing getting the code out. So I found the whole process fairly demoralizing.
Earlier quoted context omitted.
By license I mean the current Leetcode interview process except you do it once and are good for at least five years. Obviously when candidates are interviewed there would still be technical questions asked, but perhaps those would be more domain-specific. The whole point is to avoid the redundancy of the existing interview process.
Yea, think of it less as a "government issued license allowing you to do software" and more of a certificate that says "I recently passed a level $LEVEL leetcode grind, you only need to test me for specialized skills or for a level greater than $LEVEL." If it actually worked and couldn't be gamed/cheated (good luck with that), it could reduce interviews to a simple check of domain knowledge not covered by the certifi…
I'd rather have candidates studying unit test design, debugging, security hardening, technical writing, localization, or pretty much anything else that comes up more often in practical development.
Earlier quoted context omitted.
Yeah, this is admittedly a problem. I don't have a great solution other than relentless education, which is... hard. Especially at scale. From a cultural side, some companies have a competency pillar that is supposed to embody the idea of being a "good person". In mine, we call it "Citizenship", it's tied to performance appraisal and interviewing is one way to develop that competency. As for code cleanliness, I've pa…
I guess the question is, what's the proportion either side? Is it 25% will do it properly, 75% don't? Am I too cynical about tech interviews, or too optimistic? I'd also add, for a couple of companies, Google's approach springs to mind. I think for places where, you know, they do search algorithms, knowing how to print the spanning tree of a graph is probably an important thing to know.
Personally I think there's a strong correlation between necessity and hiring quality (i.e. if teams really need the help, they typically engage candidates more meaningfully than the Google-style clinically impartial methodology)
So wait you are smart enough to get into caltech, smart enough to graduate with a degree in CS. And yet the curriculum on its own does not do a good job enough on its own to prepare you for getting a job? Very hard to graduate with a decent GPA in CS at caltech and not be able to thrive as an entry level engineer. If you got B’s in caltech CS I’d make you an offer for 200k+ without blinking or even asking you anythin…
Computer Science is not Software Engineering. A PhD does not translate to real world engineering skills. If you just go through a bachelors CS curriculum, designed to give a survey of all topics in academic computer science, that wouldn't make you a competent engineer. This is especially true now that through the internet, just about anyone with a laptop can get as good as they want at software engineering without ev…
OP is not comparing a caltech grad to someone who contributed to open source. OP is comparing caltech grads to someone who studied algorithm interviews.
I agree. Degrees and accreditation are sort of gateway policies to conduct deliberate filtering and maintain a class based social hierarchy. There is some merit as it does take a brutal level of hard work and intelligence to get into caltech.
However, algorithms are the exact same type of filter, both are pretty much divorced from any relationship to the job at hand.
Earlier quoted context omitted.
> I think it's impossible to nail these interviews without minimal prep. It's very specific, and every candidates are well-prepared, many of them have done 500+ leetcode questions before interviewing. It’s definitely possible. Mostly you’d want to learn your algorithms well in college and continue to exercise them in your work. The rest of the interview is a lot about how you present yourself, which is mostly along t…
> Mostly you’d want to learn your algorithms well in college and continue to exercise them in your work. The rest of the interview is a lot about how you present yourself, which is mostly along the lines of “work out the problems out loud and ask questions”. Not my experience. When I interviewed at Google for a senior position, I mostly had difficult questions with little interaction with the interviewer. Before my p…
Earlier quoted context omitted.
Why is it not embarrassing for Caltech’s admission department and algorithms courses?
The Caltech course on algorithms is probably focused more on mathematical proofs of correctness and runtime bounds, rather than the implementation details required to pass coding interviews