381–390 of 547 posts
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,…
Just curious, what are some examples of better ways to measure general IQ and grit? You said they are questionable concepts, so how do _you_ interview people?
I don't, any more. I'm at a company that enforces a very rigid structure that I don't agree with, so I simply opt out. I pay for it every review cycle. Ironically, the rigidity of that structure is explicitly intended to reduce personal bias, which is a laudable goal, and I believe it succeeds. Unfortunately, I think it just replaces personal bias with systemic bias.
When I did interview, which was a lot at times when I was in a leadership role at a couple of startups, my favorite interview technique was to let the candidate lead and I'd follow. If I wanted to ask about algorithms, I'd ask about one they'd used in a project they'd worked on. How did it work? What were its strengths and pitfalls? What others were considered? What bugs were found in its implementation, or caused by its use? Besides flipping the control dynamic of the interview, it often led to more interesting conversations. Highly recommend.
> what are some examples of better ways to measure general IQ and grit
IQ has been under a shadow since _The Bell Curve_ and I'm not keen on letting it back out. ;) If one must measure it, I'd say measure it directly with simple challenges (e.g. memory or pattern completion) or puzzles ... but even those are apparently fraught with cultural baggage and of questionable relevance to a knowledge-heavy domain like programming.
As for grit, it's often readily apparent from someone's resume. Were they self-taught, worked through college, or took a free ride? Did they stay with companies and projects through hard times and get promoted "in the field" or were they always the first rat to abandon ship? It usually only takes a few questions to figure out whether someone's a coaster or a fighter. Funnily enough, the people with the most actual evidence of grit are the ones least likely to have spent their time studying specifically for the interview. They were busy actually doing stuff.
Earlier quoted context omitted.
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…
Takehomes: The minute you allow for them to ask for 2-3 hours of work. That's the moment that they'll ask for 40+hours of work for free (and call it 2-3 hours). Also they'll try to claim copyright on your work (with pay) and reject you outright.
Earlier quoted context omitted.
Takehomes: The minute you allow for them to ask for 2-3 hours of work. That's the moment that they'll ask for 40+hours of work for free (and call it 2-3 hours). Also they'll try to claim copyright on your work (with pay) and reject you outright.
I agree you have to be careful. However the takehomes I have had were a few hours of work paid at 50% of the hiring rate and that was where it ended. Great experience. There are companies out there doing this to make a great interview process and companies out there who want free work. It should become obvious which is which very quickly.
Earlier quoted context omitted.
Here's a thread on the same article that ended up being largely about dynamic programming :) https://lobste.rs/s/n8tyip/data_structures_algorithms_i_actu... I still say it is a bad interview question, but there were lots of interesting examples I learned about. - GCC splitting IA-64 instructions - Trellis quantization in lossy video encoding - Knuth-Plass line breaking algorithm (mentioned here too) - Some algorithms…
I tried to read the comment, but don't quite understand: what is the problem GCC is trying to solve there?
I think it could be one of those cases where if you had a more obvious representation you wouldn't need a clever algorithm, but there is probably some other reason (good or not) that instructions are represented that way
Early in my career, I interviewed at Google. One of the interviewer asked me to recite the algorithm for constructing a Convex Hull. Since I hadn't done anything related to convex hulls since my algorithms class as a sophomore in college (several years earlier), I couldn't remember all the details. At some point, I said, I know where in CLRS ( https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press... ) this is.…
Not to troll, but have you considered that you perhaps were not qualified for the job? There are people that can recite details of convex hull construction algorithms.
Earlier quoted context omitted.
I can see what you're saying (in good faith). I do think interview anxiety is a collocation of multiple factors. I don't think the correlation of anxiety to the listed categories are easily deconvolved from other factors -- it might seem like a common-sense correlation, especially if you start from certain priors, but it's a big assumption to make on average. (Only this past week I had experiences that challenged my…
I appreciate your willingness to continue this conversation in a constructive way. So let me ask you a question. You say the white-male interviewer power dynamic might affect your interview performance by 10% or less. (Personally I'd pick an even lower number, but then I'm a white male myself and also old enough that I've been senior to most of my interviewers for a while now.) Would a 10% difference in interview per…
Going back to whiteboarding: I don't like whiteboarding myself, but to be fair it does measure certain dimensions quickness-on-feet, memorization abilities, ability to exude presence, fluency in language, etc. While these are laudable abilities on their own, I agree they might not correlate with overall on-the-job performance (but it depends on the job).
I guess "job performance" is this amorphous latent variable y that is correlated with a bunch of direct predictors x which we can measure, u which we can't measure, so we use proxy variables z to stand-in for them: y = f(x, u, z).
The worry is that some candidates, who may be bad for the job, but just happen to be good at these proxy dimensions (or train for them) might get the job; on the flip side, we may exclude certain candidates who are potentially good for the job but perform badly at the proxy dimensions. Whiteboarding measures the proxy dimension z.
Edit: oh look, an article on HN's front page on this very issue:
Earlier quoted context omitted.
I think the point is that no one is being asked to derive a novel algorithm. It’s taken for granted that a person with enough experience will have an understanding of broad categories of algorithms and should be able to reason about the small changes to those algorithms that would be necessary for practical application.
Can you offhand write C++ code for a 2-3 Finger Tree, including the changes necessary to make it efficient in a strict language?
Open-mindedness goes a long way. Also typically our interview questions are set up in a way where it's expected you won't finish but try, which reveals a lot about personality and how problems are attacked.
Earlier quoted context omitted.
Yea I interview (and have sat on HC) at Google, and interviewers who ask these types of questions really frustrate me. If your question requires having previously memorized or being able to come up with some tricky algorithm on the fly in 45 minutes and code a solution using it , your question is probably bad. I get why they ask them - they're easy to ask, they're easy to score, and when your question inevitably gets…
My favorite question to ask in software engineering interviews is one that I believe to be un-burnable. > It's 2140 AD, New York is under water up to X feet high. Buildings have been retrofitted with to withstand the water. You are in charge of keeping your building dry. If water gets in and damages the foundation, a few thousand people die or become homeless. > Design a system that ensures that doesn't happen. How c…
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…
I'll get myself some down voting here... I kind of like asking questions about data structures and algorithms. I don't see them as simple black and white questions though. I see several values: 1) If you're a "computer science" degreed person, I expect basic understanding of basic algorithms and data structures. As for your basic job stuff, things like Java have multiple implementations of maps or hash tables you sho…
After a grueling interview process at Goldman Sachs, with 7+ technical interviews that required me to solve very specific questions on college-level Maths, Stats and Computer Science (admittedly, I was applying for a quant job position), I was eventually asked to interview candidates myself. While I did not feel entitled to change the current interviewing culture at the company by asking questions of a completely different nature from what I got asked in the first place, I conducted my interviews in a very similar way to what you described. By no means did I expect applicants to reach a definitive answer, but I instead worked on the problems with them to see how far their intelligence, creativity, curiosity and, most importantly, their ability to well communicate their thought process would take them.
Such interviews used to take a while hour of my time (which is a lot to afford when you work in a bank), but by the end of each I believed to confidently ascertain the candidate’s ability to thrive on our team. In retrospect, it has served me really well.
All in all, the problems posed (and the solutions given to them) might not carry as much weight in the final decision as the discussion held with the applicants. As long as the questions asked give them some material to work on, and DS and algorithms usually serve this purpose very well for us engineers and developers in general, one should be able to effectively select candidates given some time investment.