Earlier quoted context omitted.
i often just refer to it as waterboarding.
whiter boarding?
I just call it "whiteboarding".
Seems to convey the subjective experience quite aptly.
How to Pass a Programming Interview
191–200 of 570 posts
Re: How to Pass a Programming Interview
#192Is it weird that I find this entire blogpost eerily similar to PUA strategies? I think it ultimately boils down to confidence. To use the dating analogy, nothing drops the proverbial panties (or boxers, if you're into that sort of thing) faster than having confidence. Being physically attractive (i.e. fit and in shape) doesn't hurt either. Take my analysis with a grain of salt, though. I happen to be hilariously bad…
And your advice is eerily similar to the non-advice people give guys who aren't naturally good with women. "Just be yourself" or "Just be confident."
Those statements aren't advice they are platitudes. And some people, despite people who are naturally good not understanding, need actionable advice about what to do exactly.
Re: How to Pass a Programming Interview
#193Being 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…
> I much prefer "homework" projects
I helped a group within my organization with their hiring process recently, and we had pretty good success with assigning a short "take-home" exercise, vs. trying to haze them with a programming problem over a google hangout interview. A problem focusing on a small part of what that group does, but scoped to be doable with 1-2 hours of work.
Re: How to Pass a Programming Interview
#194Being 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…
Here's an idea (perhaps naive): why not add all the methods and give them optionally to the programmers. E.g.
- normal interview is mandatory (you need something to base your ideas on)
- portfolio is optional but when chosen it weighs heavily
- take home project is optional but when chosen it weighs heavily
- etc.
With 'weighs heavily' I mean that it influences the criteria for which those methods are good for.
The downside of this is that interviews are more unstandardised, which is a trade-off worth considering.
Re: How to Pass a Programming Interview
#195Earlier quoted context omitted.
Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.
This happened to a friend. He confirmed that pseudocode would be acceptable, but then as he was writing it out the interviewer got on him about not terminating lines with semicolons (I suppose the pseudocode looked C-ish). So yeah I'd say make this clear.
I wrote some Ruby in an interview. It was so terse, I had to explain to the interviewer (who favored Java) what the code did, and why it was linear instead of O(n^2). That was actually kind of fun.
Re: How to Pass a Programming Interview
#196Being 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…
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)
This entirely depends on the kind of product you are working on. When you get to a large scale with any programming project, optimizing computational resources will cut costs, and can often add value to the customer as well.
Re: How to Pass a Programming Interview
#197Earlier 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…
What if it isn't stupid code? What if it is straight forward and simple and looks correct but is just slow because it has to traverse a list instead of using a hash-table or some other data-structure. You can't get there by intermediate steps, you have to rip out the code that uses it and rewrite it with a hashmap. You can only do that if you know the space complexity and when a hash and a list is appropriate.
Re: How to Pass a Programming Interview
#198Earlier quoted context omitted.
Take out any of that old stuff. It's not necessary. Your resume should fit on one page, two at absolute most, and only include things that you would expect to be grilled on. If you are annoyed about being tested on something on your resume, take it out.
I see what you're getting at. I still think that in general, people who can't be bothered to read important documents, and instead just eyeball them for keywords (and start shooting off questions accordingly) -- aren't my cup of tea to work with, anyway.
I understand your point, it drives me crazy in interviews as well. But by the same token when I'm interviewing, I want to be able to grok someone's resume as quickly as possible - I don't want to see stuff that they themselves don't think is relevant.
Re: How to Pass a Programming Interview
#199> candidates who have worked at a top company or studied at a top school go on to pass interviews at a 30% higher rate than programmers who don’t have these credentials (for a given level of performance on our credential-blind screen). Welcome to Silicon Valley meritocracy. And it's much worse for founders seeking investment, where there are no hard skills to test at all. It's almost purely about being the same class…
Doesn't that support the fact that it is a meritocracy? Is it not reasonable to expect that top companies and top schools are more likely to employ people who have more applicable talent and skill?
At the end of the day, going to a top university or working at an impressive company is always going to be a huge and relevant signal. It's difficult to see a problem with that.
Re: How to Pass a Programming Interview
#200Being 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…
Honestly, I consider an instinct for complexity analysis the most important thing I learned in school, and the thing that I've gotten the most use out of. I don't know what case you're making here: are you saying that high-level architecture is so hard that choosing a map or a hashmap should be a coinflip, or the one you see first? Having had some criteria for making the choice makes my life a lot better when everybody is panicking because something is running like shit and no one understands why.