4 ms·
>but this one is excellent. Not really. You'll give the impression this quality of code is part of production code and send them running for the hills.
by FLUX-YOU 9y ago
>but this one is excellent.
Not really. You'll give the impression this quality of code is part of production code and send them running for the hills.
- mark-r 9y agoDo you seriously think anybody would confuse this snippet for production code?
- zaphar 9y agoYou've obviously never seen the kinds of production code that I have. This example is clearly distilled down but manifestations of the cause can be found in many different languages and I've encountered quite a few of them in my day. That said I wouldn't really consider this a good interview question.
- protomyth 9y agoCheck me on this one. What if this is some absurd way to do a series of process steps where the a == 1 checks if you can do step 1 and then executes step 1 with a being set to 1 on success and 0 on failure thus allowing the && to go to the a == 2 comparison which handles step 2. This continues with the rest of the line. Its just psycho enough to be plausible in a truly dysfunctional way.
- zaphar 9y agoI have encountered code written by people just psycho enough to think that's a clever way to handle just that scenario. They were not wrong it was indeed clever. It was also terrible.
- protomyth 9y agoThe sad part is I too can see someone who needs to do batch processes reading about short circuit evaluation and having this "amazing" idea for a framework that would look exactly like that if. Its moments like those that make me wake in a cold sweat.
- FLUX-YOU 9y agoIf they want me to assume this kind of code would never be in prod, then they can assume I know how to write code and we can dispense with the technical interview altogether.
- billconan 9y agoIMO, a good interview question should reflect daily work.
- mark-r 9y agoIf this were the only code they showed you, then you can consider that a fail on their part. Remember that an interview goes both ways.
- protomyth 9y agoWell, given some of the code I have seen, I would have a sneaking suspicion that clean code was not the hallmark of this company's source code. They are also probably asking these type of questions because they use some of these "cool techniques" in their code. I then start having a flashback to some code in 98 that I had to debug at 2AM to get the damn batch job out by 6AM that turned out to be some really "clever code"[1]. Yeah, I might checkout early and run for the parking lot. 1) said right there in the comment, but not why or how it was clever or what it really did
- lucideer 9y agoIf I were hiring, I'd be looking for a candidate who makes considered, well-researched-and-thought-out judgements, not one who runs for the hills based on speculating that a few characters of a conditional might be representative of a company as a whole.
- FLUX-YOU 9y agoCould you maybe use some considered, well-researched-and-thought-out judgements regarding the kinds of questions you ask so that candidates can get a better feel for the demands and level of quality you put into your code instead of intentionally asking lower-quality questions which give you arguably little insight into how candidates actually code?
- lucideer 9y agoThe quality of the question is subjective. My opinion of its quality is well-researched-and-thought out - you're entitled to disagree but that doesn't nullify the fact there's thought behind it. You were making out that a candidate would "run for the hills" based on a wild extrapolation about the company's production code - I was responding to that point, which is quite independent of the quality of the question.
- FLUX-YOU 9y agoTechnical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview, it certainly says something about how you view and respect potential candidates' time and maybe it indicates the quality of code you run. I have nothing else to go on unless you have public repos. I personally don't think it's a wild extrapolation based on the code quality compared to interviews I've gotten and I quickly reject companies that don't put forth fair tests. At worst, I'm wrong about the code quality, but I'm still selecting based on bad interview questions, which I'm perfectly fine with and I think more people should do if only to generate some kind of rejection signal to get interviewers to stop asking mundane questions like this. It's not like companies don't also reject candidates for equally small bullshit or extrapolating conclusions about candidates based on the interview anyway.