Earlier quoted context omitted.
If an interview is a negotiation, then why interview somewhere that I'm going to have to start off at a weak negotiating standpoint? Obviously this is predicated on the dev job market being as good as it is, but still. I can just go elsewhere.
You're missing the point. Regardless of the circumstances in which an interview takes place, you can ask for changes. And usually get them. The only way to be guaranteed not to get the changes you want is not to ask. So, if you ever find yourself in an interview about to go the wrong way, ask.
I will not do a tech interview
361–370 of 554 posts
Re: I will not do a tech interview
#362Earlier quoted context omitted.
I get your point, but knowing the differences between http, udp and tcp isn't minutia ... it's cornerstone knowledge for anyone working with distributed systems.
I'd tell you a joke about udp but you might not get it.
Re: I will not do a tech interview
#363Earlier quoted context omitted.
You have to look at the candidate's overall performance in the interview; not the answer to a single question. Describing a closure is actually a great example of something many great software developers WON'T know based upon their prior domain experience. A strong Java or old school C/C++ programmer (yes I know C++11 has closures) may actually be an excellent candidate, but have no idea what a closure is. I would ex…
I can get anything I need to done in JS and I have no idea what a closure is. I've even written an emulator in it. Took me a little while reading to figure out what it is. Apparently it's just using vatiables in a lambda that are from a scope higher than it. I do that all the time, I just didn't know it had a special name. To be fair, I didn't know JS could do lambdas. I've only used them in C# and possibly Python. W…
Javascript people use closure to mean lambdas, closures and sometimes anonymous functions.
Ask two programmers the difference between lambdas, closures and anonymous functions and be prepared for a different and probably wrong explanation from most of them.
Including me.
And that's the only reason you don't know what a closure is, if you hung out around javascript programmers a bit more in RL or online you'd have heard it constantly.
If it was described to you, you'd know what it is.
Re: I will not do a tech interview
#364Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
The company he mentioned was able to get 10 hours worth of work info on him this way.
Re: I will not do a tech interview
#365Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
If you truly have only a day or two to get somebody up to speed, then sure, you need somebody who is already intimately familiar with every technology that you use ... but if it's a gigantic project, you're probably going to have a bigger learning curve than a couple of days anyway.
However, if you're looking for the absolute best person you can get for a job, you shouldn't write them off because they haven't had experience with a specific technology. More important is that they have a solid understanding of algorithms, data structures, and various design architectures, have exposure to a number languages, and are capable of rapidly assimilating new concepts. I'll take the lightening fast learner over somebody who knows a few specific techs _really_ well any time, because the lightening fast learner will _also_ learn the specific quirks of my project quickly, whereas somebody who has a difficult time with new concepts but happens to know the right techs might struggle for a long time just to come up to speed on a large project that somebody else created.
Re: I will not do a tech interview
#366> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer Nice idea. Though I hope you don't expect to be given high priority stuff or be paid a full senior dev's wage during this short contract before which I don't know your abilities as I've not had some other chance to assess them. Of course an active public portfolio helps here, as potential employers can…
The nature of the work isn't that important. However, asking someone to take a low-ball contract is a great way to filter talent. People who are good, or busy, will completely turn you down. People who are desperate or suck will gladly take the money.
This contract test should be last one you do. It should be either the full day on-site or the short contract. You also need to pay market rate if you hope to hire market rate talent.
Re: I will not do a tech interview
#367Earlier quoted context omitted.
Why? Interviews are an unnatural situation. I have hired people who did not interview well but were great at the work.
But have you also hired people who did not interview well and weren't great at the work? The goal of interviewing is to avoid false positives, not to avoid false negatives.
Re: I will not do a tech interview
#368Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me. So for me, I really want to interview somebody before he can…
Believe me, your DBA or the person who writes queries doesn't need to know how exactly B-tree index works. Or even "B-tree" term. Just being aware about indexes and knowing when and where to add it would be sufficient.
Re: I will not do a tech interview
#369Earlier quoted context omitted.
I can get anything I need to done in JS and I have no idea what a closure is. I've even written an emulator in it. Took me a little while reading to figure out what it is. Apparently it's just using vatiables in a lambda that are from a scope higher than it. I do that all the time, I just didn't know it had a special name. To be fair, I didn't know JS could do lambdas. I've only used them in C# and possibly Python. W…
You've never passed a callback to a JS function?
Re: I will not do a tech interview
#370Earlier quoted context omitted.
Hm, I guess I didn't think about it that way since we wouldn't actually ever give out "real" work, we give out the same problem (which is an extremely scaled down version of a real application) to most everybody who passes a phone screen. I think paying them is perfectly reasonable, but I'll also note anecdotally that having done this for many candidates for years, I think very few people have ever declined.
>>...which is an extremely scaled down version of a real application You're putting the candidate in a very vulnerable and stressful position: You're potentially asking a candidate to solve a problem with your application (even if scaled down)-- The question/assignment could be a long-standing issue your staff have been unable to address on their own and you want to try to find out whether you can get a free solution…
I just don't see a couple hours spent on a interview programming assignment as being any different from the 5-6 hours you spend in the office being interviewed, which by the way, you don't get paid for either (excepting reimbursements, etc).