TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

On Hiring: How Not to Annoy Developers

45 点作者 fredwu超过 13 年前

11 条评论

kls超过 13 年前
<i>I am in favour of having candidates to do one or two coding tests (on their own, not during the interview) that will demonstrate their technical abilities without spending too much time or be under interview pressure. If a question is going to take a candidate more than a couple of hours to do, it is too much.</i><p>I agree with this, I am a vocal advocate of getting rid of the whiteboard. These tests reflect the skills far more than a whiteboard in an interview. That being said, you should only ask developers that are in the final round of hiring to do this, if it is a filter to even get in the door for an interview then you are going to filter out a lot of good candidates. Developers are smart, more importantly most of them are good at simple math. They know hiring is a numbers game and are not going to waste time on a project, that does not even guarantee an interview. I am not a big fan of asking people to do stuff for free, because it is akin to saying here do some work, because we don't know how to spot good talent. It's not the message you want to be impressing on developers. As such, if they are in the final rounds, you have at least some rapport built with them, and can explain why it is important that they perform the task, and they get the confirmation that they are within sight of the goal, before they are asked to expend the extra energy.
评论 #3513483 未加载
评论 #3513582 未加载
phamilton超过 13 年前
I recently interviewed with a startup. They had all 6 engineers interview me one by one. Each interview had a whiteboard/tech question component. At no point in time was I restricted to a language or expected to use an API. The questions measured an understanding of algorithms (data structures and big-O notation), an understanding of operating systems (concurrency, memory allocation, etc.) and object oriented programming.<p>There was even a gross bithack, which I really struggled with. After a half hour the interviewer was laughing, saying "I love this problem because everyone just goes bananas with it". It wasn't to make me look stupid, it was to see how I approached a problem that was apparently unsolvable.<p>With each question I was free to ask any questions, whether it was a clarification on pthreads or a question about problem constraints. I did not feel like my "off the cuff" knowledge of programming was being tested, but rather my experience and understanding of programming.<p>My only complaint with the interview was that it was long (11am - 7pm with a lunch break). That was mostly due to the fact they wanted me to meet with the entire team one at a time, as well as the fact that I was only in town for the day.
lemieux超过 13 年前
Last fall, I had an interview where they asked me to reverse a linked-list in python and to filter out every unique items of a list. I failed because I did not remember the API by heart and they tried to impress me with a python one-liner that would do the job for me. Not so sure if the interview was for me or for them... Complete waste of time.
评论 #3513815 未加载
rickmb超过 13 年前
I've never understood the whole emphasize on testing technical skills during the interview phase. In most countries it's either easy to fire someone, or you have legal probation period.<p>One month of employment should be enough to find out if someone has the practical skills they've expressed in the interview, and catch the 1% that can bullshit their way through.<p>Of course that 1% becomes a lot bigger number if the interviewer doesn't know what they are talking about. But that's not a problem you can solve with tests.
评论 #3513940 未加载
评论 #3515130 未加载
评论 #3514075 未加载
akavi超过 13 年前
Having never experienced it, can someone tell me what the point of having the applicant code on a whiteboard instead of on a computer is (Maybe with screen-sharing so the interviewer doesn't have to be looking over the applicant's shoulder)?
评论 #3513693 未加载
sreyaNotfilc超过 13 年前
"The technical questions should focus on the logic behind a candidate’s solutions, not what functions or libraries a candidate may or may not remember from the API documentation."<p>Finally someone said it. I'm an Asp.Net dev by trade, yet I don't even use or know 80% of the available functionality. Yet, interviewers are very adamant on you knowing this.<p>What it seems is that they don't understand that a lot of solutions can be solved purely with logic, not by some specific function, library, etc provided by the framework. I don't need to know the full scope of Asp.Net because I'm able to hack up a quick and logically sound solution. The thought process from A to B to C is vastly important compared to the API. In layman's speaking, Batman's brain is much more useful than his utility belt.<p>And let say you do need those items to complete a task, Google is always there to help. I sometimes wish that they would test out your Googling skills instead of asking you a framework question.
phylosopher超过 13 年前
"pair programming is an excellent way for both parties to get a sense of what it is like to work together." So true and if you can convince a developer to do this, power to you. We are an early stage startup and we are two for two with this method and have carved out a strong team.<p>I would argue that high salary requirements can be negotiated if you can frame a strong vision. Developers are not investment bankers and often are not doing this for the money alone. Often, good developers are looking for a place where their voice has as much weight as anyone else and where they can grow with company. We wouldn't have it any other way.
richardburton超过 13 年前
Hi Fred. I would love to hear about examples of small companies that got it right. Have any stood out? What hiring techniques would make you happy?
评论 #3513507 未加载
kevingadd超过 13 年前
Since going on the job market in November, I've been exercising an experimental policy: Interview with basically anyone (basic constraints apply - has to actually be a job I can do, a language I can speak, etc). It's been enlightening, especially because I'm at best a middling engineer (not a 'rockstar').<p>Virtually every company I've interviewed with has had tremendously awful HR, committing dozens of enormous mistakes that would have led me to abandon any interest in working for them (if not for my above-stated rule). I've learned a lot of interesting things from this experiment, but I think the biggest two are these:<p>A lot of companies screw up hiring from the HR side, but in general, the ones who mess up more than once tend to mess up a lot.<p>And in general, the ones with big money and big HR departments seem to be <i>worse</i> at interviewing and hiring than the tiny scrappy ones that can't even afford an HR department.<p>Just to give a few illustrative examples from the maybe 50 or so companies I've dealt with so far:<p>One big local developer scheduled a day-long interview that spanned lunch (starting around 11:30am and ending at 5pm), and knew that I had to drive an hour+ in traffic to get there. There was no lunch scheduled, they had me sit in a room and interview all day, even after I pointed out how little sense this made to the hiring director while I was on-site. They did not reimburse me for parking at their facility. This on-site was after a long series of successful phone screens. After the on-site, they told me personally that they would contact me with an offer, and then proceeded to completely ignore me for 2 months before a person I had never met before finally responded with something cryptic about an internal reorganization.<p>Another up-and-coming developer repeatedly made basic scheduling mistakes that made it near impossible to actually interview with them. Their hiring manager failed to e-mail me to notify me that a director would be calling in the early morning and also failed to tell me who he was, so when I got an unsolicited call from a stranger in the middle of a night's sleep, I asked if I could return his call, and he said 'no, I'm too busy'. This pattern was reinforced when they scheduled my on-site interview to begin 45 minutes after my flight landed (in a city where it took over an hour of cab travel just to reach their office). They compounded this by having me wait an hour and a half in the lobby before actually starting the interview, and having me interviewed by employees who clearly had not even been told my name.<p>The technical director of one well-funded studio contacted me out of the blue to ask if I was on the market and solicit my resume. After providing it, he sent me their 'engineering pre-screen', a series of around 10 moderately complex engineering and math problems that took me around 8 hours to complete (and probably would have taken someone more skilled at least 4 hours). A week after I submitted the completed screen, the technical director responded with a long diatribe about how my solutions to simple algorithmic problems should have used specific SIMD instruction sets or optimized for corner cases that were not specified, and commented that my lack of certain domain-specific skills made me an unsuitable candidate for a job he had told me nothing about.<p>In general, it feels like the average company hiring developers doesn't have a clue how to do it. It fills me with terror to think of how many potentially awesome candidates are falling at the wayside due to simple mistakes, and the idea that those great candidates end up at mediocre companies only because of HR mistakes is a rough one. Worse still, it's extremely rare for a company's HR department to solicit feedback on the hiring process - even companies that make me offers tend not to ask how it went. It seems likely that they do not make any effort to improve.
chrisbennet超过 13 年前
Whenever I hear about how horrible some company does something, I always think "Opportunity!" Just not sucking at something puts your scrappy little company ahead of your more impressive competitors.
fredwu超过 13 年前
In case anyone is interested, I've written another piece on how to attract technical co-founders:<p><a href="http://news.ycombinator.com/item?id=3521476" rel="nofollow">http://news.ycombinator.com/item?id=3521476</a>