71–80 of 82 posts
The author advocates questioning the interviewer directly, but he doesn't mention questioning anyone in his Netscape interview, only making mental notes of various red flags. In practice, I think that's the way 'both way' interviews generally have to go - you don't interview your interviewer, but you do evaluate and judge your potential employer critically. Personally, my attempts at interviewing an interviewer have…
Huh, I was asked that very same tree traversal question at an interview recently.
My answer was, "I don't know; I would look it up in a book. Is this really relevant for an architect position?" I got the offer anyway and turned it down.
I think these technical interview questions are a silly way to evaluate developers. You almost never have to write low-level sort routines because you just call them in runtime libraries. But it's harder to evaluate the more important ability to modularize code and manage complexity.
I interviewed for a dev job a good many years ago. I hadn't heard of the company at the time (they were pretty small so there was no reason that I should have) so I did a lot of research. I remember that their financials were looking decidedly bumpy, but almost always in the black. I asked about this at the interview. The lady interviewing me looked offended that I would ask about their financial situation as it was…
Not assessing the financial situation of small employers pretty much has always lead to them going bankrupt in my limited experience. And employers unwilling to give any indications are the ones that leave paychecks un-funded when they do (that was an SOs employer).
One question I always ask my interviewers is "What is the best thing about working here?". You can tell a lot by their immediate response and whether their face lights up with excitement. One answer I will never forget is a developer responding with "We have a Dyson hand dryer".
An equally interesting, and perhaps more useful, question I always follow that with is "What's the worst thing about workign here"... The cop out answer is usually 'it's a big company so you get some politics and inefficiencies'.. I suppose a good follow up would be; "how does the company intend to change this going forward?" or even "how does it compare to other places you've worked"
Why would I invest my time interviewing you only to turn around and tell you something that might make you decide not to work here.
Earlier quoted context omitted.
An equally interesting, and perhaps more useful, question I always follow that with is "What's the worst thing about workign here"... The cop out answer is usually 'it's a big company so you get some politics and inefficiencies'.. I suppose a good follow up would be; "how does the company intend to change this going forward?" or even "how does it compare to other places you've worked"
As an interviewer I loath that question. Why would I invest my time interviewing you only to turn around and tell you something that might make you decide not to work here.
Earlier quoted context omitted.
Right vs. wrong isn't what he's concerned about, I think. Every company/organization/person should have a long term strategy. That way you can weigh potential actions to see if they are moving you toward or away from your goal. If you don't have that goal, or it isn't well communicated, everyone scrambles to optimize for different things, which frequently leads to people pulling against each other. It's totally accep…
Sure, but long term strategy at a 6 month old company is a year out. 2 years at best. 5 years is multiple lifetimes for most startups.
What this is not, is skewering someone on "j=j++ in a loop" trick questions, or dryly sacrificing them on the algorithmic altar. Programming is supposed to be interesting, so it should be interesting to dive into fundamentals, language issues, library specifics or whatever, and keep drilling to the edge of the candidate's knowledge, and beyond.
The hope is, the good candidates get grilled a little, and walk out thinking "I could learn something here."
One aspect of "selling the candidates" that can be overlooked is the tech interview. There's a big opportunity to demonstrate your own/your team's technical excellence as a selling point. What this is not , is skewering someone on "j=j++ in a loop" trick questions, or dryly sacrificing them on the algorithmic altar. Programming is supposed to be interesting, so it should be interesting to dive into fundamentals, lang…
This seems bass-ackwards. Library specifics, and to a certain degree language issues, are exceedingly amenable to recourse to documentation. An understanding of algorithms, less so.
Earlier quoted context omitted.
I always ask "Do you enjoy working here?" Their instant response is usually telling.
I always ask this. Doesn't even require an honest answer, the length of pause is sufficient. (although now it's been on HN interviewers will probably be better prepared)