281–290 of 570 posts
Earlier quoted context omitted.
Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".
This is not how to find people you actually want to work with.
Not to have one at all!
This obviously doesn't apply to people just starting out, but I've found the easiest way to get a job is to have worked with someone at the company in a similar role. Many of the issues that interviews are designed to highlight (attitude, flexibility, stick-to-it-ivness, culture fit) simply are non issues if you have someone on the inside who has experience with you.
Earlier quoted context omitted.
Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".
This is not how to find people you actually want to work with.
Earlier quoted context omitted.
i often just refer to it as waterboarding.
Have you ever been waterboarded? Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.
Earlier quoted context omitted.
> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…
"Or had to find the O(x^n) and replace it with O(x^2)" The other thing that really seals the deal for me as an inferior interview question is that you don't need to have a clue what O(x^n) is to wrap some code in a simple time call, see that the code you think ought to run in microseconds is running in seconds, by visual inspection notice stupid nested loops, and fix it. Self-taught programmers may not be able to say…
Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…
> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…
"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.
Earlier quoted context omitted.
> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…
I've seen this plenty of times. I've worked both on a trading platform and a large website, and both times encountered many performance issues that were solved with a more appropriate algorithm or data structure. I've even seen this with a list as small as 10 items - a O(n^3) algorithm was making multiple network calls each time; changing it to O(N) alone made a huge improvement in speed.
But I think it's more telling if a programmer knows how to profile his program and find the performance bottlenecks, recognize them for what they are, then fix them appropriately than if they can recall a specific optimization for a specific use case on demand.
Earlier quoted context omitted.
> Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decision is a matter of balancing so many different points. You're right but if a candidate is going to spend hours or days working with your company I think it's the least they deserve. If there is a legitimate reason for not hiring them I'd like to think litigation would be r…
There is also a power imbalance that is exploited. You need a job a lot more than the hiring company needs a new recruit.
But you're right. I wonder what the statistics are for interviewing; are more people interviewing while they don't have a job or do have a job and are looking. I feel like it has to be the former like what you were suggesting but I haven't seen data either way (not even sure on the logistics on collecting that in a good, representative way).
The point of most job interviews is to weed out people who need to read articles like this one.