31–40 of 354 posts
After reading this I have a dumb question: The person behind the post is a CS major but only played a little bit with the C programming language in college — is this pretty common these days?
- After a first non-technical call, we ask the candidate to create a very small project based on our SDK. We send him the documentation and a very small sample. He can almost use every tools he wants to create that small project and, of course, we do not set any deadlines. It allows us to see how the candidate architecture his applications and it gives us a project to discuss during the following call. - If all goes well, we invite the candidate on site to present our code/project and eventually brainstorm together. So that both parties can see if they can work together and the candidate has an insight about how we work, how our code looks like.
Clearly, it's far from perfect and we are often considering changing it. Imagine if every company where you are applying would ask you to create an app from scratch with their SDK? We may lose some candidates, but at least we hire only people that fit the company's culture.
Earlier quoted context omitted.
This may be another reason people are eager to start their own company in lieu of working for someone else. If it is so, then it is a good thing. Right?
Well, if they really enjoy the challenge (and it is challenging), then yes. But I think there's something sad about being forced into it because hiring practices are archaic elsewhere. It doesn't have to be this way. I don't like it that so many new startups fail and I have a feeling many of these (besides lacking an idea, failure in implementation etc...) are due to a lack of other options. If you can't get hired wi…
I actually like asking math questions on interviews. It shows how people approach a problem. Asking code questions in an arbitrary interview setting shows just about nothing - no access to a reference doc, somebody peering over your shoulder. Heck, I couldn't code my way out of a wet paperback in that setting. Certainly, asking only math questions is stupid as well, people should know at least a little about the stuf…
"...a smart person eager to learn is a breeze compared to teaching problem solving to someone who memorized the reference manual." I would guess that there is actually significant overlap between these two groups.
Memorising the manual is the strategy of a surface learner. Surface learners can make pretty good PHP programmers, but they'll struggle with, say, passing Javascript closures.
A deep learner will look for the underlying principles and abstractions. They can quickly get an overview that, even when it's fuzzy, is still accurate enough for them to know where the gaps in their knowledge are, so they can fill those gaps quickly when they need to. They're like Mendeleev with his first periodic table. He didn't need somebody to show him a sample of gallium to know that it existed: he could inferred its presence and properties from the overall structure of the system.
Of course, a really advanced programmer will have done both. They will know and understand everything. But those guys are few and far between.
Earlier quoted context omitted.
Start with a simple interview which simply checks that the person (a) has a brain; (b) is somebody you're comfortable working with. Then do a short-term contracting gig (maybe just 1 day). If it works well, hire them. Edit: clarify length which even the best people could do.
Generally speaking, high quality people won't take a short-term contracting gig. They are probably working elsewhere and don't need that level of uncertainty; they're looking for something better , not just anything.
Also, I don't think it needs to be a long gig. Maybe even just a day, which isn't much longer than the gauntlet of technical interviews some companies will put you through. Even that short period should be enough to see if someone works well.
Earlier quoted context omitted.
Start with a simple interview which simply checks that the person (a) has a brain; (b) is somebody you're comfortable working with. Then do a short-term contracting gig (maybe just 1 day). If it works well, hire them. Edit: clarify length which even the best people could do.
Generally speaking, high quality people won't take a short-term contracting gig. They are probably working elsewhere and don't need that level of uncertainty; they're looking for something better , not just anything.
I actually like asking math questions on interviews. It shows how people approach a problem. Asking code questions in an arbitrary interview setting shows just about nothing - no access to a reference doc, somebody peering over your shoulder. Heck, I couldn't code my way out of a wet paperback in that setting. Certainly, asking only math questions is stupid as well, people should know at least a little about the stuf…
I think you don't get the point. Learning a new language after you programmed for 5 years in a variety of paradigms like assembler, object-oriented, purely functional, will take you between a couple of hours and a week. But if you have NOT had those 5 years of varied programming experience, then the new language is not your problem. Learning the concepts is, and that will take time.
The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.
For example: "This database contains 100,000 problems with standardized parameters. The problem definition is defined in the file spec.txt which you can grab from our code repository. Write the code to solve these problems efficiently, passing each solution to a remote service via POSTing to a REST API, the documentation for which you can find here. Bonus points for parallel execution. Feel free to use any editor/IDE and reference online documentation, Stack Overflow, etc. that you want. If anything's not clear or you need a hand with something, just ask as you would if you were an employee already. Ready to get started?"
The great thing is that once you've identified a candidate, you can do remote screen sharing and have them write code before they even have to come into the office. I've interviewed a fair number of remote people this way and it's excellent for weeding out the people who can talk the talk but can't program worth a damn. And it limits bias because you don't care about much beyond their communication ability plus their technical ability.
Hiring engineers is hard, and companies haven't really figured it out yet. Even the best companies rely on puzzles and gimmicks that often have little to do with day-to-day programming. At one company I interviewed with, I was asked to implement a queue using two stacks. At that time in my programming career, I had worked with C, C++, Obj-C, Lua, Python, JavaScript, SQL, and a handful of DSLs developing games, game d…
"To find out if they can get stuff done, I just ask what they’ve done. If someone can actually get stuff done they should have done so by now. It’s hard to be a good programmer without some previous experience and these days anyone can get some experience by starting or contributing to a free software project." http://www.aaronsw.com/weblog/hiring
Hiring engineers is hard, and companies haven't really figured it out yet. Even the best companies rely on puzzles and gimmicks that often have little to do with day-to-day programming. At one company I interviewed with, I was asked to implement a queue using two stacks. At that time in my programming career, I had worked with C, C++, Obj-C, Lua, Python, JavaScript, SQL, and a handful of DSLs developing games, game d…