3 ms·

I'd probably follow up on talking with your buddy. It's often invaluable to get an outsider's feedback on how others look at our code. From what you typed, it

by ebrenes 10y ago

I'd probably follow up on talking with your buddy. It's often invaluable to get an outsider's feedback on how others look at our code. From what you typed, it seems like there wasn't a lot of communication prior to doing the coding exercise. I'm also not aware if you had channels to ask questions or discuss technical design options. If available, those are often "part of the test", to see if you make use of such resources. When I'm reviewing code in such scenarios I'm often looking for other indicators aside from the code's correctness. Things like: naming conventions, structure of the code, patterns used, how over-engineered it is. Just as important is seeing if the candidate picked up on less explicit instructions or hints in the coding exercise. Finally, I look for code that follows the conventional patterns and standards for that programming language; I expect a candidate to discuss with me the deviation from those standards prior to handing in the code. Anyways, I wouldn't completely give up. This might be an opportunity to grow and learn, but you'll never know unless you follow through on asking your buddy. Likewise, I've seen people here on HN volunteer to review code and provide feedback.

geebee 10y ago
Thanks for your reply. Your instincts are good here - one cited problem was indeed the departure from standard conventions. I had my reasons, not saying they were good ones, but I didn't get a chance to explain them either. I'd like to, but it appears I won't get that chance. I gotta say, that is the part of this all I don't really like. It was vastly better than my only previous experience with a take-home project, where I didn't hear back for a month and got a one-line brush off from a recruiter. In this case, I am certain that they looked over the code reasonably carefully - they did provide a short bit of feedback, though it was delivered by a recruiter, and there was no back and forth here. I'm ok with not getting a job, but I would have liked an actual follow-up where we reviewed the code after that level of effort and time invested. Lastly, the job was fairly senior, so it may have been a high bar, and that wasn't the only problem with the code. Then again, how much are you really supposed to work on a sample project? Overall? I'd be hesitant to do this again. I might ask in advance what the policy is on a review. Maybe a 30 minute conversation is a requirement for me to do this. Still mulling it over.

by ebrenes 10y ago

geebee 10y ago

Thanks for your reply. Your instincts are good here - one cited problem was indeed the departure from standard conventions. I had my reasons, not saying they were good ones, but I didn't get a chance to explain them either. I'd like to, but it appears I won't get that chance. I gotta say, that is the part of this all I don't really like. It was vastly better than my only previous experience with a take-home project, where I didn't hear back for a month and got a one-line brush off from a recruiter. In this case, I am certain that they looked over the code reasonably carefully - they did provide a short bit of feedback, though it was delivered by a recruiter, and there was no back and forth here. I'm ok with not getting a job, but I would have liked an actual follow-up where we reviewed the code after that level of effort and time invested. Lastly, the job was fairly senior, so it may have been a high bar, and that wasn't the only problem with the code. Then again, how much are you really supposed to work on a sample project? Overall? I'd be hesitant to do this again. I might ask in advance what the policy is on a review. Maybe a 30 minute conversation is a requirement for me to do this. Still mulling it over.