[deleted]
More whiteboard coding won’t build you a better team
31–40 of 46 posts
Re: More whiteboard coding won’t build you a better team
#32Asking how someone would go about solving a problem is a good question to ask but simply can't replace making sure the candidate can write code. Imagine hiring script-kiddies instead of actual hackers.
As an aside, did anyone else see the irony in the word "competent" being misspelled?
Re: More whiteboard coding won’t build you a better team
#33Earlier quoted context omitted.
> The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them. I'd argue that also belongs under the "best" list, because it told you exactly the level of the people you'd be working for/with.
Very true. In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my ba…
Well, you basically showed that you don't understand OOP. That may not be important to you, but the interviewer probably successfully found out what he was looking for.
The most important aspect of OOP is message passing, and in Java, message-passing is implemented via non-final methods. OOP is a model of computation, just as FP and imperative programming are, and certain jobs require that you understand that model of computation well.
Re: More whiteboard coding won’t build you a better team
#34Earlier quoted context omitted.
The question is: what is your tolerance for (a) false negatives and (b) false positives? Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not? Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why? In my experience whiteboard coding sessions feel adversarial, like a trap or a te…
I think this is the correct question to ask. in my experience, false positives in early ventures (research projects, startups, project partnerships, whatever) are the kiss of death. If you need a group of people to do work at high capacity, bringing someone who does not 'fit' in when the group is young will probably destroy it. existing high-capacity people will become angry, there is less fault tolerance in the qual…
I agree this is the right question, but for the opposite argument. False positives in early stage ventures, in my experience, can be quickly and actively remedied. I've seen people fired less than two weeks after being hired without a substantial impact on the rest of the team or the product. If you can do this, you have a lot more freedom to take risks with new hires.
In a larger organization, if you hire someone, you're stuck with them in almost all cases. So be picky.
Re: More whiteboard coding won’t build you a better team
#35"Competant [sic] developers, even those who don’t specialize in JS, should be able to answer this question in 5-6 minutes. Therefore, this is a quick filter." This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody kn…
I think it just means add memoization, I don't think there's anything javascript specific about it.
If you want to implement it in a general way you still need to know how javascript supports closures though.
Re: More whiteboard coding won’t build you a better team
#36I don't care about these tests. I have a very simple interview process - I ask you what you've done and we talk through it. I may even ask you about how you've solved some problems involved with whatever you were working on. I then jokingly ask you about an inner join or a fib sequence and laugh after a few seconds. Maybe it's because my I come from the family business of construction years ago, but I believe that it…
Man... I don't know what I'd do if an interviewer presented that situation up front and very directly. "We'll hire you fast, but we won't hesitate to let you go." I wouldn't be able to stop thinking of the bad news bears scenario where I quit my job, get hired, and fired at the new one within a couple months. I guess it depends how awesome the job is that I'm applying for and how (not) awesome the job is that I'm leaving.
Re: More whiteboard coding won’t build you a better team
#37Earlier quoted context omitted.
Very true. In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my ba…
Well, you basically showed that you don't understand OOP. That may not be important to you, but the interviewer probably successfully found out what he was looking for. The most important aspect of OOP is message passing, and in Java, message-passing is implemented via non-final methods. OOP is a model of computation, just as FP and imperative programming are, and certain jobs require that you understand that model o…
Well, if he eventually came up with the right solution, I would assume he understands OOP and overloading, as there usually isn't a way to just stop an interview and teach yourself core-foundations of a trade before answering questions.
I think the point was that, outside of specific cases, programming has many solutions. The fact that Paul gave two correct answers before getting to the 'right one' says that this was one of those cases.
Perhaps method overloading was not on the forefront of his mind that day.
A simple question of 'Why did you do it this way instead of using method overloading?' would've sufficed in figuring out whether or not they had a grasp on OOP and wouldn't have insulted the interviewee with open-ended questions where they were looking for one answer.
That would be the same as asking what is another way to write 49 and expecting only the squareroot of 2401.
Re: More whiteboard coding won’t build you a better team
#38"Competant [sic] developers, even those who don’t specialize in JS, should be able to answer this question in 5-6 minutes. Therefore, this is a quick filter." This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody kn…
I wonder if H1B hires have to go through this process. Does anyone go to India and ask people if they know how to cache an item in Javascript?
Re: More whiteboard coding won’t build you a better team
#39The key thing is that 'you don't want to hire people to write code'. Code is inventory, code has a cost, code-not-written is what you want (as much as possible). So you need to hire a developer who knows 'how not to code', 'when not to code', how to write as little code as possible (libraries, reuse and designing things that don't take much code, clean, concise, elegant, and well-structured). These sort of developers…
Even better, a developer that can take an existing code base and shrink it.
[deleted]
Re: More whiteboard coding won’t build you a better team
#40Earlier quoted context omitted.
Very true. In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my ba…
Well, you basically showed that you don't understand OOP. That may not be important to you, but the interviewer probably successfully found out what he was looking for. The most important aspect of OOP is message passing, and in Java, message-passing is implemented via non-final methods. OOP is a model of computation, just as FP and imperative programming are, and certain jobs require that you understand that model o…
But that highlights exactly the problem. He wasn't asked to demonstrate message passing in OOP, he was asked to implement Rock, Paper Scissors. There are numerous OOP-y solutions to that, but there's no way for him to know what they're actually looking for.