If you think interview is really a measurement of one's professional ability, then like any measurement, it has measurement errors. To me, it seems that this person has some sort of interview anxiety because of previous bad interview experiences.. So the anxiety kind of feeds back onto itself. In this case, the interview can't really measure his ability accurately. But this brings another question... How valid and reliable are those interviews? I really have no idea about that since I have never had a tech interview. Just a question to think about when it comes to evaluating a measurement
I will not do a tech interview
491–500 of 554 posts
Re: I will not do a tech interview
#492> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer. This article reeks of privilege, namely that of location. The suggested is horrendously unfair to people that would need to relocate (possibly even internationally) to get a job. I am currently interviewing for a large tech. company in Silicon Valley. I am living in England. It would take a substantia…
The contract work could be done off-site.
Not necessarily - for instance there may be requirements for physical access, data protection, actually working in the same office as a team member, etc.
Re: I will not do a tech interview
#493Granted, 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/…
Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…
It's only different in that, unless you're contracting, they're fairly uncommon.
Meetings and code reviews happen every day (or at least a few times a month), so you're well versed in their protocol.
Make yourself well versed in the protocol of interviews and they won't be any more stressful than any other type of meeting.
I find its helpful to think of people in a similar situation: door to door salesmen (possibly they're more disadvantaged, than you will be in an interview, I mean you know you've got the skill set or you wouldn't be there, they might get turned away just for being salesmen). Now a door to door salesman doesn't get terribly nervous selling something at the door of their house. Why? Well they do it hundreds of times a day, and before that the practice their marketing spiel, and techniques for getting the customer on side.
Practice questions, practice those body language techniques, practice telling jokes, and generally getting the interviewer to open up. When you do into do the real thing it won't be a big deal at all because you've practically done hundreds of them.
Re: I will not do a tech interview
#494I always walk in with this in mind: "Let's see if I want to work here".
At the point where I'm really convinced and want to work there I get a little nervous ;)
I also insist on doing some work there, to prove myself of course and see how things work. how they are organized, tools and frameworks they use etc. And most important to get a feeling about the people there. I know it's hard in just one day but you get an impression. I left my last job because I wasn't feeling good there. No team spirit and a "cold" atmosphere. Why should I spend 8-9 hours a day at a place like that?
Re: I will not do a tech interview
#495Earlier quoted context omitted.
I've tried that. The response is always, "This is how we do our interviews. If we changed it for you, it would be hard to compare you to our other applicants".
Yup. Business theater continues despite evidence it doesn't work. [1] Consider this a signal everything else is broken too. Notice their signals to show you are more than a technical automata to "fill a process void in the value chain". The best interviews are as casual as possible, and not called interviews. Good interview process looks like: - 2 phone screens (recruiter||hr and then hiring manager && closest cowoke…
Wow, it sounds like you're interviewing for a best friend there not a work colleague. I seriously doubt you've ever recruited more than a handful of people using this criteria.
Re: I will not do a tech interview
#496Rule of Thumb, which might apply or not (;-D): People who think they are good usually aren't!
There are many reasons why people would come to you to ask for help or why you are more successful then colleagues. E.g. in my company we have a guy who thinks of himself as a web developer but thinks that CGI is the protocol the browser talks to the web server. It is not hard to be the best in such an environment. Don't compare yourself inside your company! Compare yourself to the rest of the world! Look on GitHub, read blogs, talk with people on software development mailing lists. If you still feel stronger than most people around you, you probably are.
Re: I will not do a tech interview
#497> 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…
>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. 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 good, or busy, will completely turn you down.
>People who are desperate or suck will gladly take the money.
I don't see that as a universal truth at all. Many decent people are out of work for various reasons (start-up just gone under, contract ended and haven't found the next one yet, just back in the market after illness or similar, new to the area, or like the post that started this discussion: they just don't interview well despite their technical skills+experience) and some of them are desperate for new work. Not everyone, even amongst the best people, are sat on enough of a nest egg that they can turn work down willy-nilly.
People who are busy won't be applying in the first place, or will take the technical interview option (which is presumably less difficult to schedule the time for) if offered instead.
> You also need to pay market rate if you hope to hire market rate talent.
For the job yes, of course. For the interview, which this short contract is taking the place of? I don't think so. You can't be too cheap of course, as that will make people doubt the salary range being quoted for the real job/contract.
Of course if a company were to try use this as a way to get quick short-term resource in cheaply, with little or no intention to take people on for longer contracts, their reputation for it would circulate PDQ and people would stop applying at all (unless really desperate).
Re: I will not do a tech interview
#498Before I ask someone to come, I check his online stuff: github account, twitter, personal website, Linkedin. If with that I'm not enough sure I don't bother to interview anyone.
So you a priori don't believe what is stated in the resume. Why?
I read their cv's. In fact, Linkedin is a cv itself. But I like to inspect his/her code/design before taking a choice.
Re: I will not do a tech interview
#499Earlier 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…
Yeah, it's language sugar to capture variables (including automatics) from an outer scope and make them available to an anonymous function. This may involve copying the variables to other storage (e.g. to heap) if the anonymous function will be run outside the context of its caller.
Also, the language may, if it provides some sugar to allow the anonymous function to appear to return to the caller, e.g. through async/yield/co-routine type semantics, also transparently copy back the variables to the callers' locations.
As per another commentator, 'lambdas', 'closures' and 'anonymous functions' are used equivalently by different people and/or fields.
As a C programmer primarily, I was long confused why higher-level programmers went on about "closures". They're nothing special, we do this kind of stuff in C all the time. We have to do it by hand ourselves, the language doesn't give us shortcuts. It's not really mysterious and we don't have fancy names for it. Sometimes I wonder if the reason some higher-level programmers treat these things so reverentially is, perhaps, because there is an element of mysticism to it, borne of lack of understanding of what is happening "under the hood"?
Re: I will not do a tech interview
#500Earlier quoted context omitted.
You can figure out by discussing past experience, projects.
This is the easiest for people to fabricate and it makes it harder to discern good people from bad, especially when you can't actually look at the product of that experience.
I think it is quite easy to get to the level of discussions where one needs to be very smart to fabricate...
As for coding during the interview, I can't concentrate (get in the "zone") even when my wife watches me behind. So it is not about the stress, but the way how a programmer works.