"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.
i often just refer to it as waterboarding.
How to Pass a Programming Interview
131–140 of 570 posts
Re: How to Pass a Programming Interview
#132Another tip which I give: Interviewers vary widely in how much they care about whether your syntax is accurate, whether you handle invalid inputs, and whether you write unit tests. It's really useful to ask the interviewer whether they want you to worry about those things. If you handle invalid inputs for an interviewer who doesn't care about that, they're going to be a little annoyed by you going more slowly than ne…
You can always preempt the whiteboard issue by bringing a laptop along. "Hey, I'm a lot more comfortable writing code on a keyboard and with an IDE. Lets program this together in a text editor instead of a whiteboard".
Indeed, having the candidate use their laptop gives the interviewer a valuable signal, too: whether the candidate has a coding environment they are comfortable and fluent in. Are they stumbling on their editor, or is it an extension of their mind?
Re: How to Pass a Programming Interview
#133Earlier quoted context omitted.
I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.
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.
There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.
Re: How to Pass a Programming Interview
#134I hated this article. A good technical interview reveals an aptitude for programming or a lack of same, and can distinguish a true aptitude from an ability to fake it. I've been interviewing programmers for a very long time and I'm pretty good at avoiding "false positive" results with a few straightforward questions. If you have aptitude and talent, brush up on your algorithms and try to have fun with the interview.…
>I'm pretty good at avoiding "false positive" results
And you know that...how exactly?
Re: How to Pass a Programming Interview
#135It's always been strange to me that tech interviews tend to check for basic CS, rather than deep engineering. When was the last time you had to implement bsearch() in a real project?
It is widely believed that if you are able to do deep engineering you should also be able to get the basics right. It takes a lot of time evaluate a real world project and most of applicants would not agree to do one anyway, so basic CS is the easy approximation.
Yet it is certainly false that if you are able to get CS basics right, you will be any good at deep engineering.
Re: How to Pass a Programming Interview
#136Well, technical interview questions are why I've given up on pursuing a programming career path and I was shocked that employers were still giving out technical interview questions for a product manager role, it didn't matter if I was a software dev years ago. Rote method still trumps real world experience building real commercial software that people will pay you for according to a lot of interviewers....and I've heard about few managers hiring neophiles based on their 'algorithmic' performance on a whiteboard build shit on Node.js, panic when it's far more work necessary and pull the plug on their CMS (reinventing wheels) because PHP is 'slow'...what in the fuck did I just hear you want to rebuild a static CMS website in Node.js because you think it's going to give you wings?
well at least that has been my experience so far trying to get a job and I'm coming up dry every time. I technically have no work experience because I've been holed up writing a big data mining SaaS tool for a few years and since I was self employed it seems to mean jack all for credentials.
I don't know I'm in a bit of a jam. Starting a complex SaaS product from scratch that thousands of people have used is simply useless against a fucking sorting algorithm that will be used heavily on the actual product.
Like I feel like I'm living in a bizarro world sometimes...I have all this experience and knowledge in this one area, building shit and getting people to pay for it, and it's going to waste as I'm half heartedly applying for jobs I know I will not be able to pass the second round of interviews when the technical algorithm questions begin....I'm sure if I wanted to learn more about the different variety of sorting algorithm I would've fucking consulted stackoverflow already....come on man I just wanna solve real world problems with real world product experience not write fucking code on a whiteboard. I'd be happy to architect out an entire stack powering your product in to the future on a white board but fuck man if you want help on your sorting algorithm just google stackoverflow.
my 2 cents.
Re: How to Pass a Programming Interview
#137Earlier quoted context omitted.
You can always preempt the whiteboard issue by bringing a laptop along. "Hey, I'm a lot more comfortable writing code on a keyboard and with an IDE. Lets program this together in a text editor instead of a whiteboard".
As a candidate, I feel that it is fair to stand up for this as well. If the interviewer wants psuedocode, I'm happy to whiteboard it. But I've been whiteboarding before and had the interviewer say, "that code wouldn't compile, you're missing a bracket." So I said, "If you want code that compiles, bring in a laptop and I'd be happy to put it in to Visual Studio [it was a .NET position] and have it be syntactically cor…
"This organization uses whiteboards as their Code Editor?" - did not get the job.
Re: How to Pass a Programming Interview
#138Being 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…
Wouldn't the question about the moving average be a good one though? It should be quite obvious that you can calculate a moving average without remembering more than the current average and the window size. Given that, time and space complexity should be obvious. I think it would be a fine question to see if the interviewee has any idea what complexity means.
Or was it a more complicated moving average case (exponential etc) where the algorithm was given and you were asked to determine the complexity?
Re: How to Pass a Programming Interview
#139Being 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…
"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 "O of exx to the enn" but that doesn't stop them from fixing it.
So... seriously, what good is the question anyhow?
Re: How to Pass a Programming Interview
#140I hated this article. A good technical interview reveals an aptitude for programming or a lack of same, and can distinguish a true aptitude from an ability to fake it. I've been interviewing programmers for a very long time and I'm pretty good at avoiding "false positive" results with a few straightforward questions. If you have aptitude and talent, brush up on your algorithms and try to have fun with the interview.…
Care to mention these questions? Most companies are suffering HARD from false positives. I'm sure a lot of people would love to know what's working for you. Thanks!
>Most companies are suffering HARD from false positives
Are they really? I mean, maybe, just maybe, the expectations are too high for whatever basic CRUD app you're producing.
If "most" companies are overwhelmed with having hired bad programmers, how does any work get done? Where are all the good programmers?