Sometimes I ask candidates to come up with a question for the interview, something that would allow them to put their best foot forward.
Any thoughts on that?
How to Interview Engineers
151–160 of 489 posts
Re: How to Interview Engineers
#152The 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 the candidate starts by drawing 2 lines, then marking start and end on the lines, you know you would be off to having a good chat
My thoughts exactly. Defining the problem space and all possible cases is the key that so many people miss. Once you do that, the solution is just Boolean logic.
Re: How to Interview Engineers
#153Earlier quoted context omitted.
So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I would argue that as a candidate I would rather interview with as many of my potential coworkers as possible. Interviewing is a two way street. The more exposure to the actual people I would be working with allows me to make a better-informed decision. How is reducing my exposure better for me…
> So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I think the idea is that if you do the first round with Triplebyte instead of with Apple, Facebook, Dropbox, or Stripe you are effectively doing the first round with Apple, Facebook, Dropbox, AND Stripe.
>"... you are effectively doing the first round with Apple, Facebook, Dropbox, AND Stripe."
Except that I am not. By doing the first rounds with Tripplebyte I have squandered an opportunity to learn about and form an opinion about the people and team I might be working with in the future. The more answers I can get to my questions the better informed I am.
I guess I don't understand this whole "we will fast track you" as a value proposition. The only efficiency gain("fast tracking") is gotten by the company looking to hire. I myself am still subject to the same length of the interview sequence. Only one is with Tripplebyte and one is with the company doing the hiring instead of two or more with the company doing the hiring. And in the process I have given up the opportunity to have more exposure to meet and talk to the actual team I would be working with.
Should I be so grateful for an opportunity to work for "Apple, Facebook, Dropbox, AND Stripe"(Tripplebyte seems to beat this drum loudly) that it doesn't matter whether I think it would be a fit for me on a personal, cultural and professional level?
Re: How to Interview Engineers
#154You can ask someone to solve a rubik cube in under a minute.
Or you can ask someone to beat a Go bot that is ranked over 5 kyu.
Or you can ask someone to find adjacent zeroes in a matrix of numbers in under 15 minutes.
All those exercises, however tricky, do not correlate much with how smart you are or what your programming abilities are.
Re: How to Interview Engineers
#155Earlier quoted context omitted.
I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
> not fully thinking it through What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.
I don't think it's a bad question to ask... just not the filter that the op thinks it is. all these people who are sitting in the comfort of not being in an interview and they are still getting it wrong. this filter should be easy enough to get the question right if you know any programming at all. something like the fizzbuzz question.
Re: How to Interview Engineers
#156Earlier quoted context omitted.
> given the starting and ending times of two calendar appointments, determine whether or not they conflict. Say the first appointment goes from a to b and the second goes from c to d . What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a . So, the appointments conflict just when not( b ≤ c or d ≤ a…
If you were writing code, I would argue against using De Morgan's laws just because you can. You're saving a few characters to make the code less obvious. Please correct me if there's some other benefit.
Usually after a mathematical simplification like this, you can find a direct explanation for it. In this case you can reason:
If two appointments conflict, that means that there is a time when they are both active. Thus each of their end times are after both of their start times. Of course, each appointment ends after it started, so that just leaves that each appointment ends after the other started. So if the appointments are a to b and c to d, then they conflict iff b > c and d > a.
(I've corrected bumbledraven's mistake of a > d vs. d > a.)
Re: How to Interview Engineers
#157My 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 on mars, overlapping clock hands, or how many eggs fit into a phone booth
- Don't put someone into a socially awkward situation
- If you ask a knowledge question and the response is something like "I don't know, but I would google it" that should be acceptable if they are demonstrably capable of using what they find
- Do ask them to walk through their own projects, their code, their past work/contributions, etc
- Do try to effectively convey the corporate culture so the candidate can know if they are a good fit or not ahead of time
- Do try to accurately convey what their actual job duties and day-to-day work will be
Re: How to Interview Engineers
#158The 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…
I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
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 either (1) careful training or (2) surviving many repeated failures, and finally getting at least partially acclimated to these kinds of confrontations.
Yeah sure, perhaps some of the people who "bombed" that calendar test really were the walking fraudsters the interviewer (who knows they'll get to stay in their well-paying job regardless of the outcome of said interview) makes them out to be. But most are probably simply nervous, and due to a variety of psychological factors (imposter syndrome, among others) are simply momentarily blanking out, and having suffering from a very common form of mild anxiety attack which makes the problem seem much more complex to them (at that moment) than it otherwise would, under more natural circumstances.
Re: How to Interview Engineers
#159Earlier quoted context omitted.
I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
> not fully thinking it through What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.
I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.
Re: How to Interview Engineers
#160Earlier quoted context omitted.
> how many people can get into a train Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)
You're too forgiving. I turn down interviews when they list "linked lists, hashing, breadth/depth first search" on their study guide. I've never had to write a linked list EVER in my career, don't fucking bother me with that shit. Also, if the position is in a language where linked lists would be stupid (i.e. python), then I definitely reject that company. I can explain what everyone of them is, and why you'd want to…
(Singly linked) lists have many advantages (e.g. useful operations on them are side-effect free), but whether they should be used depends upon which problems you solve and which languages you use. It's unsurprising they're used all the time in Lisp, and functional programming languages generally. I'd advise against their use in C or other languages without garbage collectors. They're rarely needed in languages (such as Python and Java) which have vectors and hash tables as basic data structures. I've never found a need for doubly linked lists in any language, for any problem.
So you'll either have them built in to the language you'll be using, the company's using the wrong language, or you'll be tackling problems where they're not really needed.