Earlier quoted context omitted.
Have you heard of Amazon's "LP" interviews? It seems to be a little bit like that. The challenge there is to tell a number of well-rehearsed stories.
I'm going through job interviews now (not with Amazon, but others). The whole thing feels like well-rehearsed regurgitation. Well, and a smidge of acting, obviously, because you don't want it to come off as well-rehearsed. But they know exactly what they want to hear and you're competing with other candidates who see the same writing on the wall and are doing their own rehearsals. I thought it was just the leetcode,…
Stop Interviewing with Leet Code
371–380 of 675 posts
Re: Stop Interviewing with Leet Code
#372I once failed a leet code graph problem because I solved it with a genetic algorithm. The problem wasn’t that I was incapable of solving the problem, it was the narrow view of possible solutions. The interviewer was looking for the CS101 solution. My biggest gripe with leetcode is they tend to filter diversity of thought.
Re: Stop Interviewing with Leet Code
#373Re: Stop Interviewing with Leet Code
#374All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measure…
Re: Stop Interviewing with Leet Code
#375Earlier quoted context omitted.
To me a real engineer is good at engineering, what you described sounds like a good HR manager.
I don't think HR is usually on that level. For example, suppose your team generates and shares some kind of data. You want to change the wire format. You could just go ahead and do it, letting the chips fall where they may, but I think that's bad engineering/engineering management. It'd be better to coordinate with the folks consuming the data. Can you make their migration easier? While you're making a breaking chang…
Terry Davis was a great engineer and he had the worst commutation skills you could imagine.
Re: Stop Interviewing with Leet Code
#376Every time this comes up, lots of people start with the assumption that coding problems have a large amount of false negatives. Because of this perceived "truth", I had the same worry when we started to implement a coding problem. Rather than guess, we decided to measure it: for the first six months, we used a wide filter (50% pass rate, actually like 65-80% of people who didn't cheat). What we found was that there w…
If the bar is "it looks alright and the person knows the language they're using," it's probably not generating a whole lot of false negatives. If the bar is "the candidate comes writes the optimal solution to a complex algorithmic problem in 45 minutes," then that's highly noisy and tends to filter for people who have done a very similar problem recently.
Unfortunately, too many interviewers use the latter bar for passing or failing candidates.
Re: Stop Interviewing with Leet Code
#377Earlier quoted context omitted.
Took me about 5 years to get even modestly proficient with medium-level leetcode questions. I'm a slow learner.
I never did a CS degree so much of the learning was decently useful but it also took me years
Re: Stop Interviewing with Leet Code
#378My favorite way to judge candidates now is by asking a “clean code” question. This doesn’t refer to Uncle’s Bob Clean Code, but to code that is simple, maintainable, and extensible. I give candidates a simple and slightly ambiguous problem statement, usually revolving around “write a library that does X”. I expect candidates to ask questions and clarify the ambiguities, then proceed to define the APIs and finally write the code. The implementation is straightforward, with no tricks or logical puzzles. Only use simple structures such as lists, hashmaps, and loops. Then I ask one or two follow-up questions for more requirements, such that they need to modify or extend their code. Depending on how this is organized this might be trivial or very complicated.
I feel this format is the closest to on-the-job work and gives me a good feeling of what it would be like to work with these people. Also has a lot of freedom and allows one to peek inside the candidate’s mindset. How do they deal with ambiguity? How do they approach API design? how do they handle incorrect values? Do they care about corner cases? It is also mostly devoid of what developers hate most e.g. trick questions and obscure algorithms.
Re: Stop Interviewing with Leet Code
#379Earlier quoted context omitted.
Google doesn't allow any code on laptops. Everything is done via web IDEs or ssh into a linux machine. So nobody is using brew to obtain dependencies.
You are factually wrong. Not only that, you're conflating several different processes and team rules. Many googlers use brew to install applications on their laptops. This not against policy. Other googlers work with code stored directly on their laptop. There may even be developers who are obtaining deps (for their own builds) from brew. The problem with the brew author is that he had every opportunity to make himse…
Re: Stop Interviewing with Leet Code
#380Algorithms should be not memorized but derived on the go from well known mathematical models.
This is what good schools like MIT used to teach.