4 ms·

I write lot of code, but I refuse to do coding at interview. For me its sign of dysfunctional company. But I do not mind to do pair coding, and fix an actual bu

by jkot 11y ago

I write lot of code, but I refuse to do coding at interview. For me its sign of dysfunctional company. But I do not mind to do pair coding, and fix an actual bug. There are more reasons, in short it takes me couple of hours/days to warm up and grasp the problem. And secondly I refuse to waste my time, on half arsed throw-away code, with zero results.

krat0sprakhar 11y ago
> And secondly I refuse to waste my time, on half arsed throw-away code, with zero results. That's a very wierd thing to say. Does that mean that each and every side-project that you do ends up being substantive? If writing few lines of code gets you a job at a good company where you can spend your time working on exciting problems how is that wasteful? I do program a lot too, and I typically don't mind writing code in an interview. The only thing that sets me off are stupid level-order binary-tree traversal questions which test nothing but rote-memorization skills.
- jkot 11y ago
  Most of my code is thrown away. But I like to finish stuff, so there is a chance I spend next weekend finishing/polishing the interview questions. It is great for career, but has to be managed. Also my job is to design database structures, and there is no such thing as simple problem. Even binary tree needs thousands LOC for tests, concurrent access, writes...
- sjg007 11y ago
  I mean you should know how the basic data structures work. Not necessarily for a web dev job but for a software engineering job. Data structure interview questions are a good small concrete problem to reason about. But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...
  - krat0sprakhar 11y ago
    > I mean you should know how the basic data structures work Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really test my understanding of the data structure. Recently in an interview I was asked a problem which eventually required using a binary-search-tree to improve the running time. This, I believe, is the right way to test but it requires the employer to spend more time designing interview questions rather than relying on a problem bank[0]. (which is a strong filter for good companies in itself) > But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc... This is true but this is really really hard to test. In the interviews that I've been giving, I've indeed been asked design questions. I assume soft skills are implicitly tested while speaking to the interviewer (to some extent, at least). But other factors, AFAIK are very hard to test. Also, I would argue that a candidate doesn't need to know everything coming in. Estimates, timelines etc can be learnt on the job. IMO, if somehow employers could find a way to reasonably trust that the code I have on my Github is indeed written by me then I think that should be strong indicator of my competence. Evaluating candidates who don't have any code in the open is a different matter altogether to which I have no solution. [0] - http://leetcode.com http://leetcode.com
jlarocco 11y ago
No offense, but I'm skeptical of responses like this. If you need a few hours or days to "warm up and grasp" an interview question like fizz buzz or card shuffling, then you're just not up to snuff. For every good developer offended by coding in an interview, there are 50 idiots who can't code, who are using that as an excuse to con their way into jobs they're not qualified for. IMO, it's an acceptable trade off. If you're that awesome you wouldn't be going through the usual interview process, anyway.
- Retric 11y ago
  I find people that quickly do fuzbuzz type problems to be worse on average. The only way you can validate your interview assumptions is to randomly higher people you would have passed on. You could compare how important you think X is vs. how predictive it was for on the job skills, but few people actually onboard enough people to get good data.
- vikiomega9 11y ago
  Sometimes I've noticed I just don't "get" the problem being posed. Either it's because of ESL or well I just don't focus very well sometimes. It takes me a bit to figure out what's being asked and at that point it's usually very easy for me to go think about the solution and assumptions and such. But it does happen.
seabee 11y ago
Unfortunately my bugs are typically too gnarly and need more context than a 1-2 hour interview allows, or I'd definitely incorporate them into interviews. In the best case, it's like free labour!
btilly 11y ago
Then I'm OK with not working with you. Even if you are exactly as you claim, MOST people who claim "I can code but don't care to demonstrate it during an interview" are actual disasters as co-workers. I've been there, done that, cleaned up the messes, and would prefer to pass on some good people to avoid that. And yes, you do have to pass on some good people. There are competent programmers who freeze up during interviews. You do what you can to make the interview as accommodating as possible, but some people can't show what they've got. However the opportunity cost of passing a good person by is far less than the damage from hiring a bad one. This leads to being risk adverse.
- odonnellryan 11y ago
  I guess people get scarred both ways. I've certainly been on 20+ hour interview processes that have left me with an awful offer at the end which I just could not take. Personally, I've never been a part of a company where the code test isn't: 1) Short (1 hour) 2) On their own time 3) A real problem (algorithms are OK in my mind as long as you help them with the core problem) I do not expect everyone to know every algorithm... I guess it is kinda weird if you do not know Dijkstra's algorithm, but I only think it is weird because the courses I took focused heavily on it and similar algorithms. But, do I want you to know all the same stuff I know? No, definitely not. I don't want 2 of me I want me and someone else that works well with me but ultimately has their own ideas.
serge2k 11y ago
So less "dysfunctional company" and more "I'm not good at it so you suck!"

by jkot 11y ago

krat0sprakhar 11y ago

> And secondly I refuse to waste my time, on half arsed throw-away code, with zero results. That's a very wierd thing to say. Does that mean that each and every side-project that you do ends up being substantive? If writing few lines of code gets you a job at a good company where you can spend your time working on exciting problems how is that wasteful? I do program a lot too, and I typically don't mind writing code in an interview. The only thing that sets me off are stupid level-order binary-tree traversal questions which test nothing but rote-memorization skills.

jkot 11y ago
Most of my code is thrown away. But I like to finish stuff, so there is a chance I spend next weekend finishing/polishing the interview questions. It is great for career, but has to be managed. Also my job is to design database structures, and there is no such thing as simple problem. Even binary tree needs thousands LOC for tests, concurrent access, writes...
sjg007 11y ago
I mean you should know how the basic data structures work. Not necessarily for a web dev job but for a software engineering job. Data structure interview questions are a good small concrete problem to reason about. But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...
- krat0sprakhar 11y ago
  > I mean you should know how the basic data structures work Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really test my understanding of the data structure. Recently in an interview I was asked a problem which eventually required using a binary-search-tree to improve the running time. This, I believe, is the right way to test but it requires the employer to spend more time designing interview questions rather than relying on a problem bank[0]. (which is a strong filter for good companies in itself) > But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc... This is true but this is really really hard to test. In the interviews that I've been giving, I've indeed been asked design questions. I assume soft skills are implicitly tested while speaking to the interviewer (to some extent, at least). But other factors, AFAIK are very hard to test. Also, I would argue that a candidate doesn't need to know everything coming in. Estimates, timelines etc can be learnt on the job. IMO, if somehow employers could find a way to reasonably trust that the code I have on my Github is indeed written by me then I think that should be strong indicator of my competence. Evaluating candidates who don't have any code in the open is a different matter altogether to which I have no solution. [0] - http://leetcode.com http://leetcode.com

jlarocco 11y ago

No offense, but I'm skeptical of responses like this. If you need a few hours or days to "warm up and grasp" an interview question like fizz buzz or card shuffling, then you're just not up to snuff. For every good developer offended by coding in an interview, there are 50 idiots who can't code, who are using that as an excuse to con their way into jobs they're not qualified for. IMO, it's an acceptable trade off. If you're that awesome you wouldn't be going through the usual interview process, anyway.

Retric 11y ago
I find people that quickly do fuzbuzz type problems to be worse on average. The only way you can validate your interview assumptions is to randomly higher people you would have passed on. You could compare how important you think X is vs. how predictive it was for on the job skills, but few people actually onboard enough people to get good data.
vikiomega9 11y ago
Sometimes I've noticed I just don't "get" the problem being posed. Either it's because of ESL or well I just don't focus very well sometimes. It takes me a bit to figure out what's being asked and at that point it's usually very easy for me to go think about the solution and assumptions and such. But it does happen.

seabee 11y ago

Unfortunately my bugs are typically too gnarly and need more context than a 1-2 hour interview allows, or I'd definitely incorporate them into interviews. In the best case, it's like free labour!

btilly 11y ago

Then I'm OK with not working with you. Even if you are exactly as you claim, MOST people who claim "I can code but don't care to demonstrate it during an interview" are actual disasters as co-workers. I've been there, done that, cleaned up the messes, and would prefer to pass on some good people to avoid that. And yes, you do have to pass on some good people. There are competent programmers who freeze up during interviews. You do what you can to make the interview as accommodating as possible, but some people can't show what they've got. However the opportunity cost of passing a good person by is far less than the damage from hiring a bad one. This leads to being risk adverse.

odonnellryan 11y ago
I guess people get scarred both ways. I've certainly been on 20+ hour interview processes that have left me with an awful offer at the end which I just could not take. Personally, I've never been a part of a company where the code test isn't: 1) Short (1 hour) 2) On their own time 3) A real problem (algorithms are OK in my mind as long as you help them with the core problem) I do not expect everyone to know every algorithm... I guess it is kinda weird if you do not know Dijkstra's algorithm, but I only think it is weird because the courses I took focused heavily on it and similar algorithms. But, do I want you to know all the same stuff I know? No, definitely not. I don't want 2 of me I want me and someone else that works well with me but ultimately has their own ideas.

serge2k 11y ago

So less "dysfunctional company" and more "I'm not good at it so you suck!"