[deleted]
I will not do a tech interview
201–210 of 554 posts
Re: I will not do a tech interview
#202> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about t…
It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).
Do you have a source for this claim? None of my contracts in the US have ever had something like this. It's in fact illegal in most jurisdictions, including California.
Re: I will not do a tech interview
#203Granted, 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/…
Well, for most positions I don't need somebody who can talk to clients comfortably and I don't care if they are shy or quiet in meetings.
Re: I will not do a tech interview
#204Earlier quoted context omitted.
Google recently revealed that going back over the data they kept about past hires demonstrated that an individual's GPA was completely independent of the quality of their future contributions to the company. Why should Oracle be any different?
Have you considered that Google might be lying? Many larger firms with technical employees are worried about their lack of diversity, and the relevant legal risks. They may have to bend their effective practices to mitigate this risk. Beyond making this claim as an ulterior rationalization, mendaciously spreading it might help trip up competitors.
Correct me if I'm wrong, but considering the general make-up of Tech-employees in the Bay Area, by following your logic to conclusion leads me to think hiring outside of white males is a negative... if you think diversity = tripping up companies.
Re: I will not do a tech interview
#205Earlier quoted context omitted.
The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally…
Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.
>Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview.
Then you're like the guy who punishes interviewees because they didn't estimate the number of sewer ducts in New York correctly. Interviews can cause anxiety and stress to an extent that a typical employee may never encounter in their work.
Re: I will not do a tech interview
#206Granted, 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/…
Just replying to state my shock at how many people are defending poor interview performance. If you freeze up during interviews because it's "high stress" then maybe you need to practice going on more interviews until it doesn't bug you any more. When you're a developer -- especially at a senior level -- you need to be able to work well under stress. Hell -- you need to be able to do that for nearly any job in the wo…
I'm shocked that you're shocked. An interview is a contrived situation whose social stressors do not at all match those of programming a computer.
Re: I will not do a tech interview
#207Earlier quoted context omitted.
This seems false to me. Interview stress isn't deadline stress isn't code review stress. This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important. I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselve…
all drivers need to be able to drive well under stress But wouldn't you say a driving test is to driving as a technical interview is to a development role?
Absolutely. And if we conducted driving tests like we conduct technical interviews, it would be something like:
- Please sketch out a diagram of a typical family sedan, be sure to mark and explain all major components.
- Do you drive stick? No? Well, please draw out the full mechanical diagram of a manual transmission.
- You are going down the street and an old lady steps suddenly off the sidewalk. Please sketch on this whiteboard what you would do.
- Please play 5 rounds of Need For Speed: Underground. You are required to come in 2nd or 1st in all rounds.
etc, etc. It definitely won't entail actual driving.
Re: I will not do a tech interview
#208Earlier quoted context omitted.
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…
I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions. With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles. In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have…
When I'm working, I'm looking stuff up all the time. And, everyone I've ever paired with has been looking stuff up on a constant basis.
It's not that I'm crap, it's that the tools I'm using are always changing. HTML -> CSS? Sure, I won't look that up. CSS -> SASS? Sure, I probably won't look that up. Ask me to use LESS, I'll be on much looser footing. And, what's coming next? Do I have to have the new ES6 specifications memorized? I don't, though I've used those 100 times already, in the past weeks.
Hell, I still look up git commands.
Re: I will not do a tech interview
#209Earlier quoted context omitted.
if you freeze up in interviews, are you also going to freeze up in developer meetings? Are you really saying that your developer meetings are as high-stakes as job interviews?
> Are you really saying that your developer meetings are as high-stakes as job interviews? Most certainly aren't, but some are potentially higher stakes ( especially with smaller companies), since you and coworkers losing jobs you have -- which can be the price of getting things wrong -- is a bigger stake than you not getting a job that you currently don't have.
Woah hold on - you're firing people for getting things wrong in meetings? Most people would be unemployed.
Seriously though - if you're creating a high stress meeting like that in a company where people are at risk of getting fired then your culture is going to be terrible with people backstabbing each other so they look good at the next meeting. A company is a team - it's everyone's job to make sure the team is working by helping to fix any mistakes brought up in meetings, not firing people. You are not in competition with your employees. Your employees are not in competition with anyone either. Employees are hired by a company to work together to create things.
Re: I will not do a tech interview
#210Earlier quoted context omitted.
I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company…
In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.
We do this at my job. We try to come up with projects that are good fits for the candidate, usually a small version of a problem we've recently dealt with.
It's not a first line, though. We tend to start by actively recruiting/headhunting. We cherish recommendations from current or past employees, but we'll also open the position to all on the off chance we get a good application through traditional routes. HR only becomes involved with the process after an offer has been accepted or if the hiring manager has questions/concerns.
After an informal lunch with the hiring manager, you'll be invited to meet with some senior developers for about an hour. These meetings are mostly to figure out what the candidate thinks their strengths and weaknesses are and gives us a chance to talk about the stuff we plan to work on in the near and not-so-near future.
Once we have a fairly basic understanding of each other, we'll come up with a project. Think your strength is on the front end? Here's an API we wrote. Build a widget with the data. Think you're strongest at databases? Great, here's a database project.
We don't care if you have a lot of questions or if you fill in the blanks. We give as little direction as possible at first on purpose. Write it in whatever language you want to write it in. We want to see how the candidate works. If they ask questions, great. If they don't, great. Do they ship something?
We make sure to stress there's no wrong answers. At all. The projects are designed around your perceived strengths because we'll figure out your weaknesses and will compensate for those during the 90-day trial period all new hires have to go through anyway.
The point is to see something we can discuss in a later, final round. Even failure to complete is acceptable, so long as you can articulate why.
None of this is hard and fast. We have had candidates who, for whatever reason, can't or won't write code outside of their current position. We'll adjust. Our process isn't rigid at all. We try our best to take a holistic approach. It's only bit us in the ass twice, mostly due to culture issues because the hiring manager made his decisions unilaterally. Since then, all senior devs and a few others on the team meet all candidates before hire and can give management input.