Earlier quoted context omitted.
Usually the candidate pays all of it.
This is highly unusual (if not unheard of). A company would have to be pretty damn unique in order to justify having candidates pay for their own travel + lodging.
Why we don't hire programmers based on puzzles and tricks
401–410 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#402About a year ago I travelled to the south west (of UK) for a job - A full day of interviews, product ideas, I nailed the whole lot. Apart from the obligatory coding test. I have 15 years in this game and I have coded OSS or commercial code every day or week in Python, the language of the test, since 96. It was a codility.com test - I had not actually been expecting it but, kerpow. I rewrote my own abs() because I for…
That is the perfect example of what not to do.
Re: Why we don't hire programmers based on puzzles and tricks
#403Earlier quoted context omitted.
Reversing a string is actually an incredibly common interview question. It's a bit like FizzBuzz (IME even more common, but I can't really speak about the world at large).
It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…
1) That a string is implemented as an array of characters.
2) How to reverse an array.
The implementation is straightforward and should be trivial for just about anyone who's done much development.
I don't know that the question is that great, but it certainly isn't bad as a fizzbuzz-type question to use as a filter.
Re: Why we don't hire programmers based on puzzles and tricks
#404One of my career goals is to get a programming job without having to show that I can add a leaf to a binary tree through recursion (again). I don't mean this as flippantly as it might sound. I used to think it was kind of fun and exciting to be at the whiteboard, thinking on my feat, dealing with various curveball data structures and algorithms questions. I certainly always read up on this stuff prior to interviews,…
Which means you're not using that stuff on a daily basis. Which is fine. You're probably doing other things. Development is more than just data structures and algorithms. Yet, that's all many interviewers want to ask about.
Here's my guess: you probably reviewed that stuff prior to job 1. You got that job, due to short term memory, then you went to work. Now you want to go to job 2 (or 3 or 4). And you find yourself having to "review" material that doesn't stick to short term memory, but I'm sure you know damn well how to find it and interpret it if you needed to. No doubt at all.
Re: Why we don't hire programmers based on puzzles and tricks
#405The question I always like to ask and reserve a good chunk of time for is along the lines of "What non-technical hobby or interest do you have?" and then "If you had all the technical resources you could dream of, how would you now bring something new to your hobby?" and once we've gone through that the real question is: "Given that when you're duck hunting the key is to shoot ahead of where the duck is, and that a l…
>What non-technical hobby or interest do you have? That seems like a poor choice. Are you trying to eliminate people who don't have non-technical hobbies for some reason?
Re: Why we don't hire programmers based on puzzles and tricks
#406The best interview I ever had, I was given a problem to solve with a system, a whiteboard and 20 minutes. I sketched out a quick ERD, and explained the high level architecture of the system. No code was written -- it was assumed that I could implement said system if I could design it. The worst job interview grilled me on low level algorithms (I'm not a CS grad) and wanted me to sketch out a quick sort. Of course, I…
Exactly. Same here. Now I give interviews, and I do the former not the later. Make sure you do the same if you get to interview others. This puzzle and brainteaser shit needs to stop.
Just ask for CS ONLY and we can easily avoid you and make this easier on all of us.
Re: Why we don't hire programmers based on puzzles and tricks
#407Re: Why we don't hire programmers based on puzzles and tricks
#408Earlier quoted context omitted.
>I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. Yep. That basically amounts to an application fee.
Which is strictly forbidden in most jurisdictions.
I doubt there would be anything wrong with saying "we maintain open source project X and we only hire people who have made submissions in this project that we have accepted. If you want to be considered for employment, you must first get involved in the community."
Re: Why we don't hire programmers based on puzzles and tricks
#409Earlier quoted context omitted.
I've worked to two programmers who could not code. I mean literally not code. You cannot imagine how frustrating this became before the managers finally got rid of them.
How can this even happen? I mean, isn't it obvious in the first week or two, month tops? If not how can they hide their cluelessness for months until they are laid off?
Re: Why we don't hire programmers based on puzzles and tricks
#410Earlier quoted context omitted.
I think the swapping two variables has a bit more going for it if they do not know the trick. Explain the concept of invertible functions. Hopefully they would be able to come up with plus and minus - even if you have to walk them through the a=f(a,b) b=g(a,b) a=g(a,b) From there you can say that works fine with pen and paper but why might it go wrong in a program? So how do you avoid integer overflow? If the signs a…
XOR trick? I'm not sure I'd want to work for someone who didn't know about the x86 xchg opcode.