101–110 of 223 posts
I would say 3 to 6 interviews of gradually increasing communication is a must. Otherwise you will end up misfiring a good portion of the time. If you can't do this, you should probably hire everyone on a temporary basis for a few months until you're sure they are going to fit.
At a job interview, after shaking hands, say to the interviewer "Before we start, I would like to ask you a question, would that be OK?" If s/he says "no", leave. If "yes", then ask "as part of your interview will you be asking me to solve tricky problems on the spot?" and if they respond "yes", then leave. You get to decide what to put up with in your life. You should be your biggest advocate.
Your reaction, and what you consider beneath you, is far more valuable in hiring than your performance.
On Friday I had a remote interview where I was asked to search for the value closest to X in a sorted 2D array (columns and rows are both sorted in increasing order). I came up with a trivial solution to find a specific value, but got tripped up modifying it to find an unknown value that could be higher or lower than the target. I have not heard back from the company. On Saturday/Sunday, I went to AngelHack SF and di…
I think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often work in freelance jobs at a considerable disadvantage.
Unless you are working at Google or Facebook where efficiency is super important, the interview questions that Silicon Valley companies ask often do a bad job of filtering out the right candidate.
I thought that your hack was very good. I think that you could turn it into a business if you wanted to.
Earlier quoted context omitted.
Not sure if that's really relevant. Unless you are applying for a job where time is money stock trading or some such I don't see how knowing a method you are writing is O(log N) rather then O(N2) is useful. Its something to keep in mind sure, but I would rather have the slower method integrated into the code base faster. Yes performance is a feature but realistically you can get away with some fairly awfully performi…
If you put an O(N^2) algorithm in production, you'll kill whatever relies on it. If that's our funnel, we're out of business. If its our DB, it'll go on fire. Not being able to reason about complexity is a no-hire for me.
To be sure, not being able to reason outside of the canon is a long-standing occupational hazard and trait of the humanities, so there could be something a little more pathological in perpetuating these interviewing techniques.
Earlier quoted context omitted.
I think it's a combination of both. He sounds ashamed to be a software developer to the extent that he doesn't want his daughter to know. What's up with that? It might not be the same as being a heart surgeon, but at least in the US software engineering is viewed very positively as a career, probably alongside chemical engineering and law (actually law is viewed fairly negatively by many these days).
Ever heard of a heart surgeon that can't pay his bills? Now have you heard of a developer that couldn't pay his bills? That's why he wouldn't want his daughter to know what he does.
On Friday I had a remote interview where I was asked to search for the value closest to X in a sorted 2D array (columns and rows are both sorted in increasing order). I came up with a trivial solution to find a specific value, but got tripped up modifying it to find an unknown value that could be higher or lower than the target. I have not heard back from the company. On Saturday/Sunday, I went to AngelHack SF and di…
I saw your hack at AngelHack SF. It was a great product and I was surprise that you did not get the grand prize. I think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often w…
I was told that the only reason I didn't win the grand prize was some of the judges didn't think I could have made the app by myself during the competition/I had cheated.
Honestly, I'm more flattered that they thought I was too good to win than I would have been if I had won. :)
Earlier quoted context omitted.
Not sure if that's really relevant. Unless you are applying for a job where time is money stock trading or some such I don't see how knowing a method you are writing is O(log N) rather then O(N2) is useful. Its something to keep in mind sure, but I would rather have the slower method integrated into the code base faster. Yes performance is a feature but realistically you can get away with some fairly awfully performi…
I find it comforting that a coworker isn't going to unknowingly hide lots of superlinear algorithms in the codebase that will blow up without warning when data sets get significantly larger than the test data. Sometimes you have to make a decision to just go with the inefficient solution, but I'd like it to be an informed decision if the codebase is one I have to work with and maintain in production.
Earlier quoted context omitted.
I saw your hack at AngelHack SF. It was a great product and I was surprise that you did not get the grand prize. I think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often w…
Thanks! I am still working on Coderang (the version I showed yesterday is up at http://coderang.com ), and I think I could definitely turn it into a business. I was told that the only reason I didn't win the grand prize was some of the judges didn't think I could have made the app by myself during the competition/I had cheated. Honestly, I'm more flattered that they thought I was too good to win than I would have bee…
Anecdotally I have come across developers that match the description the OP gives of himself. They read a lot of papers, they know a lot about the inner workings of many common and obscure programming languages. Many know and love development process theory and they contribute to open source projects. Here is the but: when push comes to shove, they can't deliver to production. I've seen many smart coders falling shor…
It sounds to me like the opposite of what you're saying: he's good at delivering to production, but he's not good at pet interview questions.