Sadly, each time I want to change job, I have to go through those questions again. No any company (or interviewer) would admit that they decide whether or not to extend an offer to you solely based on how well you solve those programming puzzles. But reality is, your "performance" during the interview session is oftentimes more important than your experience (e.g., your side projects. Even you can demo your projects in front of interviewers, they just don't care -- because they themselves joined the company in the same way -- solving programming puzzles)
Software engineering interview questions
31–40 of 98 posts
Re: Software engineering interview questions
#32Earlier quoted context omitted.
We've found a good middle ground. Giving the candidate a few days to do a test project that involves fixing a bug on the production site. Its something they can do at night after work, gets them resolving a real-life problem, seeing how fast they figure out the codebase.
Really good candidates will have multiple offers and given equal choices of companies, will choose those which make them not run through hoops.
In demand DevOps candidate here. I had multiple six figure offers from companies, and still picked the job that required a 4-6 hour project I completed over 2 weeks in the evenings (that I was paid for).
Provide the right work environment and perks, and people will "jump through hoops" if they think its worth it.
Re: Software engineering interview questions
#33I'm surprised at this list of questions. Didn't everyone get the memo that "brainteasers are a complete waste of time?" from a year and a half ago? http://techcrunch.com/2013/06/22/the-technical-interview-is-...
I didn't see much that qualifies as a "Brain Teaser" - most of these are algorithmic questions. Knowing when do implement a depth first search != brain teaser.
Actually a crapload of efficient algorithms are applications of "clever" tricks. They're not necessarily intuitive, and the people that can recite them in interviews have very often already seen the solution (or the same general pattern applied to a similar problem). In that sense, they are very much like brain teasers.
If every programmer should be able to construct complex algorithms from first principles in a 10 minute window under the pressure of an interview, we wouldn't have so many algorithms named after the people who discovered them.
Re: Software engineering interview questions
#34Earlier quoted context omitted.
For me, speaking as a software engineer, I highly agree - if a company tried to pull that on me, that would be a quick way for me to turn down the company. It doesn't make sense if the candidate is working for another company - why would the candidate use up all of his/her vacation for one company if the company isn't serious about bringing the person onboard full-time as a regular employee off the bat?
To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such), I might see this as a pretty substantial benefit of working at a company that uses this method. Given that, I might be willing to participate in this kind of interview process. It would probably have to be a company I already know and admire for some reasons up…
I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.
I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.
Re: Software engineering interview questions
#35Best way is to paid-intern an engineer for a week/month and try them out (if they're willing) and see how they fit and might be able to expand on your current culture. That's really the only good way. Asking questions in an interview, no matter how clever or insightful they may be, has been and will forever be a crap shoot.
Even a week or month is short. I've been in situations where it's tough to make a hiring decision based on 10 weeks of (paid) interaction, even when saying "No" means having only 4-5 interviews to decide on a "Yes" for someone else.
This is why hiring people who we professionally interact with (referrals) is so important. And it's a handicap for people with weak networks or internal-only jobs.
Re: Software engineering interview questions
#36btw, this website is well-known among Chinese and Indian.
It's really really very hard to encounter an interview question that is not on this list nowadays, if you are interviewing with big name companies like linkedin, google, facebook ... It's more like preparing for final exam in college.
Re: Software engineering interview questions
#37I never asked any of these question, a good engineer is not a mathematician.
A good engineer should have a good base in algorithms, know which one to use for which problems, and when the algorithms matter and when they don't. And be able to research literature for appropriate ones when the need arise. That's not the end of what qualifies a good engineer, but it certainly is part of it.
CS and math researchers write papers (partially) so that engineers can pick them up and use them to improve on what's possible to build.
Re: Software engineering interview questions
#38I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that.
We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of the core parts of our product" with one of our engineers. That's followed by explaining the goals, technology, general approach etc. to another engineer, then a discussion about what would happen next, some of the specific domain problems, that sort of thing. There's no expectation that the project is completed in the time available, and it's more about understanding the process.
This has been pretty effective, and is great for getting a more rounded understanding of the skills of a particular engineer. In my experience, rather softer skills like the ability to clearly articulate the problem, to understand the broader impact on a bigger system, and to be able to identify future issues and challenges are more important than the ability to solve specific technical challenges. Lackluster technical ability is usually pretty immediately obvious when pairing with a developer, in any case.
Re: Software engineering interview questions
#39Earlier quoted context omitted.
To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such), I might see this as a pretty substantial benefit of working at a company that uses this method. Given that, I might be willing to participate in this kind of interview process. It would probably have to be a company I already know and admire for some reasons up…
I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.…
Right, I meant "pulling their weight" in a relative sense, with the understanding that a more experienced and talented employee will do more work or do it more quickly. Maybe my desire is simply to increase the proportion of coworkers who make roughly appropriate contributions to the team effort. I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.
A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.
All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.
Re: Software engineering interview questions
#40I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that. We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of…
This is how companies like google, facebook, and linkedin interview candidates. It's not effective, but it's the common practice