Hacker News new | past | comments | ask | show | jobs | submit login

I gave an example of one of our erstwhile technical interview questions below. Batting around interview questions is a hacker sport and I've met dozens of developers who delighted in relaying and evangelizing their preferred questions. I'll admit, candidly, that "what's your favorite tech stack and what don't you like about it" --- a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know --- is a uniquely bad one. But even if I felt it was a good one, I wouldn't trust it. Interview questions don't work.



"a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know"

Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?...

You make it sound like I'm asking this question, getting a monologue response and just moving on. These questions facilitate a dialogue between interviewer and interviewee, which quickly reveals your deeper understanding of a subject.

Now, I think your above approach (lookup, memorize, pretend) works great for the kind of technical interview questions that I've been refuting this whole time.

Finally, I don't think my questions are perfect, nor do I think the interview process in general is that great. I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps, then executing. This is regrettably hard to do for most people and companies.


> I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps

How do you get people to do a trial run for a week or two?

Most people start looking for the next job when they are already doing their current one. So how can we ask them to do a trial run for a week or two?

Also what about the remuneration(what kind should be given if at all for this period) and does this work for freshers and absolute newbies too?


> Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?

To me, this is the crux of why I agree with you, rather than the questions themselves. Anyone can rehearse an answer to any question, but a dialogue needs to be created in order to actually find out anything about a prospective hire's competencies.

To be useful, an interview needs to be a conversation, not a monologue.


>I think the best way to find talent is to do a trial run for 1 - 2 weeks and see how good they are at taking fuzzy problems and breaking them down into actionable steps, then executing.

Except even if you could get someone to do that it doesn't filter for the right candidates. Someone who can quickly get up to speed in a foreign domain is not the same skill as being able to build great systems/code/etc in a domain you're familiar with. The day to day of a programmer after the first X months if the latter and not the former.


Aren't you two hiring for completely different position? One is looking for web system developer and the other is looking for the kind of coder that will write exploits and smaller tools. In one position you expect the senior to have general idea about wide range of relevant technologies, because you expect senior to choose between them occasionally (plus hiring manager knows that stuff too). Second position does not require it at all.

Plenty of people can do both or can change from one to another. But it still seems to be that the interview focus should be different as both positions require somewhat different focus.


Does one require actually writing code and the other just require talking intelligently about code? If so: I concede.


Writing code is trivial part of what I would expect from senior - making correct decisions about architecture and talking intelligently about code are less trivial parts that make difference between senior and junior. Ultimately, when senior cant write code, that can be found relatively quickly. When he fails at decisions it takes more time and causes more damage. When he cant talk about code, then he is suitable to some positions but not to many others (so it all depends on position at hand).

I don't mind interview having also part where code is written at all. Be it dummy feature or breadth/depth first search or fizzbuzz or any other simple reasonably sized assignment. But in case of senior as in partly decision maker with not much direct supervision in the long term, you need those other capabilities too.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: