271–280 of 547 posts
In my experience at Amazon and Google we all referred to books and colleagues when working through algorithms.
Earlier quoted context omitted.
Unfortunately, those kinds of interviews also select for some other things that they shouldn't. * Youth. People who have very recently studied these things in school, and use the same languages as the interviewers, have an advantage. * Free time. People who have families (for example) might have less free time to study "Cracking the Code Interview" and such. * Absence of anxiety. This disadvantages women, minorities,…
> Resistance to anxiety. This disadvantages women, minorities, and people with psychological conditions that should be covered by ADA. I resemble some of those categories, and I don't know if I would feel comfortable making the leap to correlate them to a some inherent reduced level of resistance to anxiety. That seems like a generalization which I feel that, on an aggregate level, seems unsupportable by data. I thin…
Earlier quoted context omitted.
Unfortunately, those kinds of interviews also select for some other things that they shouldn't. * Youth. People who have very recently studied these things in school, and use the same languages as the interviewers, have an advantage. * Free time. People who have families (for example) might have less free time to study "Cracking the Code Interview" and such. * Absence of anxiety. This disadvantages women, minorities,…
> Resistance to anxiety. This disadvantages women, minorities, and people with psychological conditions that should be covered by ADA. I resemble some of those categories, and I don't know if I would feel comfortable making the leap to correlate them to a some inherent reduced level of resistance to anxiety. That seems like a generalization which I feel that, on an aggregate level, seems unsupportable by data. I thin…
Is any of that even controversial enough to require citation? How many Psychology or Sociology 101 textbooks should I cite? It's easy enough for those who don't feel this kind of anxiety themselves to brush it off, but for those who are less fortunate all those magnifiers can create an anxiety level that's quite debilitating.
Earlier quoted context omitted.
because if everyone is asking whatever they want there is no way to compare one candidate to another. Most companies require interviewers to pick a question from their internal 'question bank'
> because if everyone is asking whatever they want there is no way to compare one candidate to another. That's obviously not true.... > Most companies require interviewers to pick a question from their internal 'question bank' Again, having worked at some fairly big and respected companies, this has never been the case. I'm not interviewing for rote candidates. Everyone is different. Ergo, the questions are different…
https://leetcode.com/discuss/interview-experience?currentPag...
Please take a look at these. I recently interviewed at FB and I got 2 questions in phone screen that were from leetcode with FB tag.
> Everyone is different. Ergo, the questions are different.
Facebook is running interview factory, they just don't have time to customize interview for each candidate. Their own recruiter told me to practise questions from leetcode tagged with facebook.
I agree with you re your reasons for not using a 'question bank' but thats just not the realty.
Earlier quoted context omitted.
I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impres…
I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. Personally I'm way too anxious in interview settings to produce decent code. In interviews I find myself trying to get everything right first time, but in reality that's not how I work. I prefer to dev…
I've never been a big fan of giving code interviews, however when I have to give them, I'm far more interested in the candidate's thought process around how they understand the problem and what needs to be considered in building the solution.
I'm increasingly convinced that Algorithms-and-Data-Structure interviews are essentially being used as a proxy for: - General IQ. Can this person understand and apply complex ideas - Grit. Is this person hard-working enough to learn things that take time and effort It's the software equivalent of the NFL scouting combine. The goal is not to create a test that is similar to the day-to-day job. But rather, create a tes…
If you're working on a large scale project you wouldn't be implementing a specific algorithm by yourself anyway. You'd be discussing a specific problem and then discussing the pros and cons of different algorithms that you want to implement and implementing POCs in different algorithms. The interview is just to see if you can think and discuss in terms of algorithms and data structures.
1) one or two people in the discussion (interviewers) already know the perfect solution to the problem and are contributing as little as possible to the discussion.
2) the actual amount of allotted time to brainstorm a solution to the problem is realistically only ~10 minutes not the ~45 minutes you are allotted because of the time it takes to implement the solution with real code.
It would be nice if no one in the interview knew the answer to the problem before starting the discussion and this discussion would be pretty realistic aside from the lack of help from the interviewers. However, you cannot easily/fairly compare candidates with so many different questions.
Technical interviews would also be far more realistic if they allotted more time for problem solving but I imagine if the standard 45 minutes was bumped to over an hour, the only outcome is that more candidates would perform very well and that's not an outcome companies actually want unfortunately.
So why are firms that are hiring so obsessed with producing more and more arcane barriers to entry?
As I always comment when this topic comes up: this process makes some sense at Google (where I work) where the sheer number of applicants is massive and false-negatives are perfectly fine because the potential applicant pool is so large. But at smaller companies, who can't pay Google compensation and feed you gourmet food, blah blah blah? And where your job will be mainly writing some JavaScript to drive web pages? Really?
I work around embedded stuff and spend a lot of time in low-level code, and I _still_ don't get to spend a lot of time writing algorithm and data structure heavy code. I actually really enjoy doing that kind of work, but on my own time, at my desk, with my headphones on, and some books and resources to reference as I'm doing it. This is how engineering / authoring / writing is classically done, by the way. Calmly, often solitary, and with space to gather thoughts and do trial and error.
Why should I be selected or deselected based on my ability to perform this activity in front of people in a high pressure situation? Often someone 15 years younger than me, fresh out of a CS program, and with a pile of hubris that goes with that?
For what it's worth I'm self-educated, not a CS grad, but got into this because it's what I like to do and spent many years privately studying on my own to get here.
FWIW I just this morning turned down a potential job opportunity because this is the interview process they wanted.
Earlier quoted context omitted.
Making people write code on paper is just ridiculous - way outside of testing and checking reality - and your reasoning of >"because it shows that they know how to think about code" means nothing at worst, and at best indicates you'll only be happy to work with people who are replicas of yourself. Take home is the way to go, unless the position is some sort of public exhibitionist analogue developer position. The lea…
Take homes are usually very time consuming.
- Space partitioning such as octrees
- Finite-state machines
- Behaviour trees (I much prefer to state machines)
- Too many machine learning and deep learning algorithms to list
I have also had to come up with boutique solutions to a number of problems. Even though I have never failed to deliver a solution in the real world I doubt I would pass any sort of algorithm interview without significant study. I don't rote memorize things and only (quickly) learn what is relevant when it is required to solve a problem. Unfortunately I also do not know of any quick way to test for that sort of ability that would be suitable for an interview.
Earlier quoted context omitted.
We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…
12 years as a developer. Used recursion only once. Once. (but that specific time recursion was really a life saver)
When programming in Clojure I use recursion a LOT.