4 ms·

I recently had an interview where I had about 40 minutes to implement a particular data structure. This was after completing an intial take-home of significantl

by Twisol 5y ago

I recently had an interview where I had about 40 minutes to implement a particular data structure. This was after completing an intial take-home of significantly more complexity (think, reading and implementing published specifications), for which I waited a month before I followed up and found they simply hadn't reviewed my application yet. I thought I had a good rapport with the interviewer; I explained my thought processes in real-time, identified domain considerations I'd want to explore, and highlighted places where I was doing something less efficient for the sake of getting something working first. I left the interview feeling pretty good that I'd represented myself well. I followed up a week later and learned they had rejected me; apparently I wasn't focused on the problem (??), and I used the wrong data structures. Okay. 40 minutes is too short to expect a perfect solution -- unless you're hiring for memorization, in which case yeah, I'm not going to be a good fit, your pipeline did its job. (I went back, looked up what they were ostensibly looking for, and built it up from scratch. It took twice as long as I was given to implement to my satisfaction, and it was only a couple of transformations away from where I had originally left it to go from correct to correct-and-efficient.) I won't name the company (I still think they're pretty great overall), but this was a pretty sour and confusing experience. (If anyone there reads this: hi, no hard feelings, we've all got to rant sometimes.)

zhdc1 5y ago
When you have a large enough number of qualified candidates, you look for any reason you can to justify why you picked one person over everyone else. Assuming that the hire wasn't already pre-selected (which is very possible), you were likely given the quickest answer the interviewer could come up with that sounded reasonable.
- Twisol 5y ago
  Friends have suggested much the same, yeah. It feels unlikely due to a few factors, but I'm very willing to chalk that up to naivete on my part. (If nothing else, it's a convenient fiction that allows one to move on.)
- JohnBooty 5y ago
  When you have a large enough number of qualified candidates, you look for any reason you can to justify why you picked one person over everyone else. Yes. Also, a lot of companies operate under the principle of, "It's better to turn away ten good engineers than hire one bad one."
  - mcv 5y ago
    That only makes sense if you have more than enough engineers already. If not, it would be better to hire 10 good engineers and the 1 bad one, and fire the bad or or at least not extend their contract. Then you'll still have the 10 good ones. And doing actual work is a much better test of an engineer's abilities than any interview process is capable of.
  - zhdc1 5y ago
    > Yes. Also, a lot of companies operate under the principle of, "It's better to turn away ten good engineers than hire one bad one." I wonder how successful they are at this. There is no way to have a 100% hiring success rate, and the benefits from hiring ten good engineers should strongly outweigh the impact of hiring one bad one.
JohnBooty 5y ago
I followed up a week later and learned they had rejected me; apparently I wasn't focused on the problem (??), and I used the wrong data structures. Damn. I'm sorry. To me this represents a very poor interview process. I just received two senior engineer job offers from companies with whom I actually ran into some roadblocks during the whiteboard/CoderPad sessions. Before the sessions, both companies stressed that the exercises were about my thought/communication processes more than the code itself. During the coding exercises I aced some things, and when I had some roadblocks I explained my thought processes and they nudged me in the right directions -- in both cases they were actually pretty fun and collaborative processes. That's really what they were testing for. Sounds like your interview was more like, "complete this fairly challenging coding assignment in silence while somebody looks over your shoulder," which is just not good interviewing. That's not a good simulation of an actual work environment. I had some total BS interviews too, at other companies. Some people/companies just suck at it.

by Twisol 5y ago

zhdc1 5y ago

When you have a large enough number of qualified candidates, you look for any reason you can to justify why you picked one person over everyone else. Assuming that the hire wasn't already pre-selected (which is very possible), you were likely given the quickest answer the interviewer could come up with that sounded reasonable.

Twisol 5y ago
Friends have suggested much the same, yeah. It feels unlikely due to a few factors, but I'm very willing to chalk that up to naivete on my part. (If nothing else, it's a convenient fiction that allows one to move on.)
JohnBooty 5y ago
When you have a large enough number of qualified candidates, you look for any reason you can to justify why you picked one person over everyone else. Yes. Also, a lot of companies operate under the principle of, "It's better to turn away ten good engineers than hire one bad one."
- mcv 5y ago
  That only makes sense if you have more than enough engineers already. If not, it would be better to hire 10 good engineers and the 1 bad one, and fire the bad or or at least not extend their contract. Then you'll still have the 10 good ones. And doing actual work is a much better test of an engineer's abilities than any interview process is capable of.
- zhdc1 5y ago
  > Yes. Also, a lot of companies operate under the principle of, "It's better to turn away ten good engineers than hire one bad one." I wonder how successful they are at this. There is no way to have a 100% hiring success rate, and the benefits from hiring ten good engineers should strongly outweigh the impact of hiring one bad one.

JohnBooty 5y ago

I followed up a week later and learned they had rejected me; apparently I wasn't focused on the problem (??), and I used the wrong data structures. Damn. I'm sorry. To me this represents a very poor interview process. I just received two senior engineer job offers from companies with whom I actually ran into some roadblocks during the whiteboard/CoderPad sessions. Before the sessions, both companies stressed that the exercises were about my thought/communication processes more than the code itself. During the coding exercises I aced some things, and when I had some roadblocks I explained my thought processes and they nudged me in the right directions -- in both cases they were actually pretty fun and collaborative processes. That's really what they were testing for. Sounds like your interview was more like, "complete this fairly challenging coding assignment in silence while somebody looks over your shoulder," which is just not good interviewing. That's not a good simulation of an actual work environment. I had some total BS interviews too, at other companies. Some people/companies just suck at it.