181–190 of 679 posts
This was an interesting observation: > What I do know, however, is that for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them. I don't really hear much about training. I doubt it's because we don't do it, but maybe it's not an interesting topic for discussion.
Earlier quoted context omitted.
The roughest outline for hiring as far as I can follow it is start with 100 resumes, filter it down to 10 by picking ones that are nicely formatted, then filter down to 1 by interviewing. Each level of filtering should be structured so that it biases towards technical competence. It isn't really a licensure examination because, as you point out, the industry doesn't bother to put the resources in to make sure anythin…
Missed the step where they filter out anyone w/o a degree in CS from MIT/Stanford/Berkeley/UIUC/CMU.
Earlier quoted context omitted.
Yeah, but the variation can be good. If I had to imagine what the hypothetical licensing process would be, I imagine it would be something easy that admits tons of mediocre devs. Plus, would it come in different language/subfield flavors to account for different roles? One job would ask me to implement a custom allocator, and I'd pass; another would ask me how to add Frondle to Artifactory, and I'd fail miserably.
Actual engineering licenses in the US have kind of solved this. There’s the easy exam that pretty much everyone passes eh e they get their degree (the FE), and then there’s the hard one that not even everyone attempts after a couple years of experience (the PE). And within each level, you specify your discipline (civil, mechanical, etc) and then are required to have deeper knowledge of several subfields within that d…
Software is a craft discipline... it would be better organized as a guild with reputation at stake in concert with endorsements. But then you risk what is effectively nepotism and politics.
If you want a more efficient way to practice, I’ve been working on https://deriveit.org/coding/roadmap#note-215 . It’s LeetCode site that’s -organized intelligently -has simpler explanations than you find online We’re super proud of our content and just recently 2 people have landed Amazon with us. People actually feel ready for interviews with us. Give it a go :).
Earlier quoted context omitted.
As written this problem is impossible to solve. Proof: suppose there is only 1 infinite stream which is always descending. You will never find a lowest value, so you cannot rewrite the stream "in order".
it's not impossible to solve, but there are situations like that which make any solution not work, which was a follow up question
If the input is infinite and unordered and the task is to produce output in order, how do you know when it’s OK to start writing output?
What exactly is an alternative way to hire good candidates that any of you think is better than coding interviews?
Or you do a mock design exercise with them and hear them talk through their process. Are they going to use a relational DB or NoSQL? Do they need a queue or an event stream? What language do they want to use? Why?
Or worst case scenario you give them a take home exercise (compensate them!) and then for the follow up you talk with them about their code and the compromises they had to make.
Or hell, if they like white-boarding and want to do it, then go for it. But a lot of people (like me) have a tendency to lock up in those situations.
I refuse to do code tests. I don't mind doing a small 2-3 hour project that I will walk the interviewer through to explain my reasoning for doing things the way that I did, but I cannot code in front of someone. I can't even type correctly on my keyboard if someone is looking over my shoulder. I've never touched leetcode and I interviewed with Nvidia a few years ago for a position I was an absolute shoe in for, unfor…
I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…
I'm in ops and we've found that simple exercises are better at weeding people out than complex ones.
I know not everyone works with CSV necessarily, but there are dozens of libraries for a lot of languages. Even if focused on N being those supported in a given company/org. It should be less than an hour of work. Bonus points for any tests/automation, etc.
Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…
The conversation is the most important part of the interview, and the thinking (and communication) is the most important thing I'm trying to judge after basic skills.
Like you said, you can get a good sense within the first few lines of pseudocode if someone's at least competent at writing code. But that's just one motivation behind coding questions.
It's also very difficult to talk about code, algorithms, and solving problems without a concrete problem and concrete code in front of the candidate and interviewer. So both the question and the code the candidate writes are mainly context for the conversation where I try to see how the candidate thinks.
These kind of articles make me sad because I (and many other interviewers I've worked with) try to make it clear that this isn't a test - we don't care so much about being "right" or "wrong", and there shouldn't be any tricks of "a ha" moments.
We explain the goals and what we're looking for right up front. And I would hope most interviewers do the same, but I guess not. So there's this persistent myth among both interviewers and candidates that coding questions are about getting a right answer.
That's a shame because coding questions get such a bad rap, but I'm not really aware of a better options. Take-home problems and looking at GitHub are unfair to many people. A well-run technical interview should give lots of people a chance to succeed.
Earlier quoted context omitted.
What kind of job pay 400k? Even when I worked as C++ guru at BMW and was hired as very senior my before taxes compensation was 40k (year).
Perhaps they meant to say "studying for a few weeks to solve fun puzzles, after getting a CS degree from Stanford, moving to a city where a basic apartment costs $1 million, and getting 8-10 years FAANG experience, also like half that $400k is stock not cash" But no licensing!
Also you can get this pay outside the bay area, still in high cost of living areas, but for that pay it's really not an issue.