231–240 of 489 posts
Earlier quoted context omitted.
A trial week seems like it would only work for more desperate candidates, ones who are currently unemployed.
"unemployed" != "desperate"
Earlier quoted context omitted.
Since it was in 2014 and I don't know if they still do this, I won't name them. I guess the lesson learned is to ask what the interview process looks like before getting involved. However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me, and tell me they wanted me onsite for a week.
>"However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me" This is a huge red flag in my opinion and I would recommend people not agree to this. Why? Because it shows complete disregard for the candidate. "Pass a test and you can speak to an actual human being." Its demeaning. It also shows just how useless many recruiters…
The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…
If one meeting ends at t1 and the other meeting starts at t1, do they conflict? To which meeting does t1 belong? One, both, neither? Can we set up an event at t1 which is not in conflict of either? How about two events at t1?
Earlier quoted context omitted.
A weeder question I've used: How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability. People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty…
When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.
The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No lo…
A weeder question I've used: How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability. People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty…
My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable: - Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity - Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview - Don't ask time-wasting stupid questions about manhole covers, boiling bagels…
Can you expand on the boiling bagels on mars question ? Havent heard of that before
As long as you make it clear that the actual number they come up with is irrelevant and you just want to see how they think (and you're also open to pragmatic answers like "why the hell would I be trying to calculate the weight of an Airbus A380 when I could just look it up on wikipedia?") I don't see why it's that bad a question.
Some engineers I interviewed got "offended" by ElonMusk-like questions and refused to answer :)
Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers."
> An interview can result in a bad engineer being hired and later fired (a false positive).
Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."
Earlier quoted context omitted.
Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview? This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by…
Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.
I've been in many stressful situations at work - none of them involved finding algorithmic solutions.