101–110 of 152 posts
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…
Earlier quoted context omitted.
I'm like 60% tongue in cheek, because the reality is, for every interviewer who will filter you for being too aggressive, two more will filter you for lack of confidence.
I have never once filtered someone for lacking confidence. I have never seen someone filtered for lack of confidence by any panel I've been on or any panel I was the hiring manager for. At this point in my career I have interviewed ~1000+ engineers. I think you're interviewing with the wrong people, or at the wrong places. Way too many people treat interviewing as a way of demonstrating intelligence via computer scie…
Earlier quoted context omitted.
I wish they (asana) listed down some of their real problems along with few possible solutions. A candidate can provide his solution or recommend one of their solutions. I think this approach can lead to a nice discussion where both parties can get to know each other.
Have you tried this? :) https://codefights.com/bots/botasana
Earlier quoted context omitted.
>> The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings. Phenomenally good advice. I wonder, and I don't mean this to be a loaded ques…
Don't know about the architect, or a lawyer, but doctors do get real-life questions... although probably not the ones with years of experience and more letters in the title than in the name. A bigger difference though is that lawyers and doctors have to pass an exam to practice their profession, which already excludes a lot of people. 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 the interim? My wife is a registered nurse working in cardiac critical care for seven years. If she interviews for a new job with that employment record behind her they aren't going to ask her what an aorta is, which is sort of the equivalent of what Asana is talking about doing here (and what everyone does, to be fair).
So you seem to be saying that a professional nurse, as an example, can be trusted to know the basics after seven years of work, because he or she was required to take a hard test on graduation. But a programmer with seven years of experience must prove that he or she knows what a binary tree does? It's also worth pointing out that lawyers can get people jailed or cause them to lose their property. Doctors and nurses can kill them. So can we, occasionally, but it's rare.
The most effective interviewing technique, as far as I am concerned is to send the candidate out for lunch with a few of your engineers and tell them to find out whether he knows what he's doing. You spend an hour talking software with some people and it's awful hard to fake knowing your stuff.
Earlier quoted context omitted.
I have never once filtered someone for lacking confidence. I have never seen someone filtered for lack of confidence by any panel I've been on or any panel I was the hiring manager for. At this point in my career I have interviewed ~1000+ engineers. I think you're interviewing with the wrong people, or at the wrong places. Way too many people treat interviewing as a way of demonstrating intelligence via computer scie…
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.
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 these organizations grow the interview process just ends up being a diluted version of the same BS, which translates into "lowering the bar." Nevermind that your bar was curvier than Lombard Street.
What really stood out was the pages of notes that the recruiter sent me before inviting me to apply again in a few months. I had just been through many on-site interviews at many companies, and no one came close to providing the level of feedback that Asana did. The document that I was sent can't have been too far off from the unedited notes that the interviewers shared with each other in their debrief. It really spoke to Asana's commitment to transparency and helping develop people - even those they didn't want to hire. I'm happy where I am now, but based on this experience, I would absolutely apply again in the future.
> 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. Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this…
I came looking for some new or interesting way of doing tech interviews, but it's the same typical SV bullshit. Lol: "Hashes, sets, heaps, binary trees, linked lists, all the usual suspects." Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. I'm a strong believer that there are two primary ways of testing someone's coding ability: 1) Open-source, or otherwise public,…
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…
In the case that all your keys have the same hash, right?
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 believe it's O(1), argue it's worst case O(n) In the case that all your keys have the same hash, right?
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…