351–360 of 1001 posts
> One of the interviewer asked me to recite the algorithm for constructing a Convex Hull. > ... > we struggled together for an hour, with him frustrated that I couldn't remember the details of an algorithm I last had seen 6 years earlier and couldn't recite in 60 minutes what took our professor 180 minutes of lectures to cover, and me frustrated that would have taken me 30 seconds to look up.
That meant carefully controlling my emotions when their answers were bad, and having a smooth transition when the answer didn't come at all - a situation that typically causes tension. You have to essentially hand out the answer or transform the question into a trivial one so that the candidate can have a small win and relax. If you're not doing that, chances are you're screwing up the whole process by throwing the candidate off-rails after a simple non/bad answer.
That's why the interviewer has more control over the outcome (besides the scoring) as his / her bias will heavily reflect on the dynamic.
I've been interviewing SRE candidates for a long time. In theory, being able to make technical decisions under high pressure is integral to the job. But interview stress is very different than work stress. It doesn't seem to translate well. Some people do fine during the interview and then crack under real pressure, and some people it's the exact opposite. I've changed my interviewing to involve very little coding. I…
Granted, you need to be able to program. But being able to recall and implement particular algorithms from memory isn't particularly valuable to the job. I want problem solvers. People who have dealt with complicated problems and found solutions. Or at least know how to find them.
Earlier quoted context omitted.
Tech seems to be the only field that does these dumb types of interviews. Accounting, law, medicine etc seems to work well without these filters. Why are tech interviews so stupid?
So you're advocating a license to practice software development? Because the three fields you mention are all licensed.
It seems pretty obvious to me that this kind of interviews are simply there to assess how much you want to work for a certain company. As in: would you be willing to study for months, go through mock interviews, read books, test your skills etc. to have a shot at working for us? Even though the majority of that stuff will likely have zero impact on your day to day work? That's all there is, really. I've had no proble…
would you be willing to study for months, go through mock interviews, read books, test your skills etc. to have a shot at working for us The vast majority of people who work at FAANG type companies do not do any of this.
"Grinding leetcode" is a phrase for a reason!
> In short, the findings suggest that companies are missing out on really good programmers because those programmers aren’t good at writing on a whiteboard and explaining their work out loud while coding. In most of my programming jobs, explaining your work was most of the job and writing code was less important. The whiteboard environment is a bit unnatural but I don’t want to hire someone who gets the right answer…
I would definitely not want to work for you, I think there's something deeply ineffective when most of the job is explaining your code. I say that as someone who cares a lot about writing easy to read code and has no problem explaining it. Also, I'm very bad at solving a problem while being required to think out loud.
There’s a simple strategy for this, which works fairly well in both interviews and meetings. You give people time to focus and think about the problem and solving it, and don’t force people into discussions right away. It’s not a panacea but in practice it is very effective.
The reason why this is important in meetings, as someone running a meeting, if you don’t give people time to think, it will always be the same one or two voices in the room. This is why brainstorming sessions suck. The same thing applies when you are choosing who will take responsibilities—the same few people always speak up first.
The interesting thing is that Leetcode style problems encourage your code to go into the opposite direction that most production code should go. The game of Leetcode is to write the most consise, clever function that solves the problem in a tricky way. Thats exactly the kind of code I would flag in a review - sure it might be super efficient and elegant, but good luck maintaining it a few months later. I would way ra…
I like the data science interview process a lot more, though I'm biased enjoying the kind of work I do. It's somewhat common during a data science interview to be given the actual problem you would be working on if you took the job. Often times you're given multiple days as a take home or multiple interviews to go through it, because the problem is difficult enough it does take research to begin to hypothesize a poss…
So pay them. $400 for 10 hours of work is nothing for a company compared to the man hours spent on the hiring process. It also signifies to the developer that this company is serious about hiring them.
Something to think about, especially if you're involved in a startup...
Earlier quoted context omitted.
If not algorithms then what would you use to test a generic programmer? You would have to setup a custom panel based on each candidate. A person who has only worked for PHP would need a different panel from someone who has worked on C++ all his life. Algorithms is language and framework agnostic. It doesn't matter if you work in embedded or data science. It doesn't matter if you code in C or Python. The same question…
Programming in general is language and framework agnostic. Someone who can write an extensible and maintainable C++ application can most likely do the same in C#, Java, Rust etc. There's decades of best practices and knowledge around what makes good software and almost none of it is specific to a language. Most devs use a handful of algorithms in their entire career. And any algorithm they do use was probably adapted…
But what's the content they should be interviewed on? You say no to quicksort. How about date parsing? That shows you have to handle messy cases.
What do you want them to write if not algorithms? Maybe we have a different expectation of what "algorithm" means? The term is pretty generic, but I feel captures more of the cross language stuff.
Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.
Earlier quoted context omitted.
The small N is addressed by the authors. To acquire a larger N would mean recruiting more participants, which would require either compensation/extra credit or rely on people volunteering ~1 hour of their time. Likewise, collecting that data would require time and money. It is an time/resource issue with human research. You can require a small N and get some results or require a large N and not have enough funding to…
I'm curious as to what makes a good size of N. To me, N=10 would be do small, N=48 seems a little under what is should be, and N=100 seems sufficient, but I don't have a real basis for this (in fact, it's probably because of the original count that had me settle on a min and max of 10 and 100). Maybe a better question is: What are factors that studies consider, besides the logistics you rightly pointed out, in determ…