131–140 of 152 posts
Earlier quoted context omitted.
I am not disputing that it is possible to design serious, rigorous evaluations that somehow hinge on candidates not using their normal tools to answer programming questions. What I dispute is that anyone really does that. It is awfully easy to rationalize any hazing ritual with this sort of six- degrees- of- concurrency- and- formal- methods logic. But there's a simple observation to make about all these questions: t…
That's what I'm disagreeing with - some small but important parts of my work are, in fact, "reason through this code cause tools can't help you." As another example, I ask people to set up numerical/statistical algos without worrying about specific numpy details. I trust people to translate a log likelihood formula to python, but I want to see them actually derive that formula. This isn't some hazing ritual - it's im…
So if deriving log likelihood formula in high pressure, time limited situations, is a good proxy for the kind of work the candidate will be doing, by all means do it that way.
If on the other hand, they are more likely to be asked on the job, to go away for some time, think about the questions needing answers in a data set, design an algorithm to suss out those answers and then persuade their colleagues that it is correct, you should design your interview process to align with that.
Earlier quoted context omitted.
That's what I'm disagreeing with - some small but important parts of my work are, in fact, "reason through this code cause tools can't help you." As another example, I ask people to set up numerical/statistical algos without worrying about specific numpy details. I trust people to translate a log likelihood formula to python, but I want to see them actually derive that formula. This isn't some hazing ritual - it's im…
I don't think anyone is arguing that you shouldn't ask candidates to prove domain specific knowledge as part of the hiring process. The issue is that typically people use proxies for proving the candidates have the skills they need for a job, and you should design the proxies to be as close to the job as possible. So if deriving log likelihood formula in high pressure, time limited situations, is a good proxy for the…
We’ll ask you to solve some coding questions in a language and text editor of your choice. Feel free to bring your own laptop, or we’ll be happy to provide one. Notably, we ask candidates not to compile or run their code during this exercise, and not to refer to online resources. Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests! — but rather to see how you reason about your code and input cases. For that same reason, we won’t ding you for superficial syntax errors or misremembered function names. After leaving you to work through the questions on your own, we’ll sit down together and talk through your solutions (including any ideas you didn’t have time to commit to code).
In any case, all I'm disputing is the idea that formal reasoning about algorithms (without stressing function names and compilation) is a useless skill. We have tools that make it unnecessary for many entry level devs, but that doesn't mean everyone can ignore it.
Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!" I mean, it's bad enough to ask questions you…
> Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!" That's exactly how the top management cons…
When the goal is to get people that actually solve problems ymmv.
Btw. that is not a dig against management consultants. I honestly think the world needs bullshit.
Earlier quoted context omitted.
I agree with this sentiment wholeheartedly but bounds on balanced binary trees are worth knowing (like lookup, it's log n), since that fact is one of just two reasons you'd ordinarily ever use a tree. However, I will offer you some Interview Candidate Self Defense, which I'll repeat from something I yelled on Twitter a few weeks ago: If interviewers ask you about bounds for data structures, pick a fight with them ove…
If they say average case O(1), worst case O(n), hit them with them with O(log n / loglog n) with high probability from a simple balls-into-bins type argument.
Earlier quoted context omitted.
That's nice, but I have literally read interview feedback from very smart interviewers at multiple companies that vetoed candidates because "they didn't appear confident". This isn't something I'm making up: it's a real problem.
I think we can both agree that interviewing is overdue for a radical reboot. Silicon Valley, disrupt interviews, please! That said, there are places that don't interview the way you describe. I'm equally sure there are places that do (I vividly remember my Dropbox interview). My hope has always been that Darwin's Law will apply to such places over the long run, but instead I think what actually happens is that as the…
They did and that's the problem ;)
Earlier quoted context omitted.
If they say average case O(1), worst case O(n), hit them with them with O(log n / loglog n) with high probability from a simple balls-into-bins type argument.
Could you expand on the balls-into-bins argument here? It's not quite obvious to me, but I'd really like to understand.
https://en.wikipedia.org/wiki/Balls_into_bins
This reference from the wiki is good http://www14.in.tum.de/personen/raab/publ/balls.pdf
https://asana.com/eng/interview-guide
would be great to see a more detailed guide covering the concepts they like to see master of and problem solving skills they are looking for.
Earlier quoted context omitted.
>> Anyone can be a programmer. Anyone can be a doctor or lawyer too. I know what you mean, I think, but I don't know if I buy the distinction. There is a formal pass-the-bar testing event for lawyers. For nurses and I believe doctors there are boards. Same basic purpose AFAIK. They take these tests when they are just entering the profession. How meaningful are they years later, compared with the experience gained in…
"But a programmer with seven years of experience must prove that he or she knows what a binary tree does?" you'd be surprised at how many programmers with seven years experience have no freakin clue what a binary tree does! There is a reason fizzbuzz is phenomenal filter.
fizzbuzz does not filter for programmers capable of doing original, thoughtful work in a realistic work environment.
> “We want every candidate who comes into an interview with us to feel prepared and confident.” Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare. This seems like it could be i…
Hey -- I work at Asana. Great idea! Took a task to add more resources to learn from to the doc. > I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard. Hmm, the way we framed that is confusing. Thanks for the feedback! To be sure, our goal is to accurately assess what your day-to-day contributions would be like, and s…