111–120 of 295 posts
Hell, in my experience you're not even guaranteed anyone will read it.
This is just a bad idea in an industry full of irresponsible employers. I'm not saying that Triplebyte is in any way irresponsible, but the rest of the industry has already ruined this avenue.
From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…
Earlier quoted context omitted.
This x100. I hate these interviews as one of the first exercises. More than once over the years I have spent 5+ hours doing a coding exercise for a company only to get a one sentence response, telling me that my "code fell short". If I pressed them further they might say my code was "hard to read" or "not what they were looking for". Vague, unhelpful, and pitiful responses. 0 interaction. No chance for a rebuttal. It…
Unfortunately, a big part of this problem is that companies face serious liability risks if they give useful feedback. My experience with tech interviews is that they are actually exams, taken under stressful conditions, with none of the courtesies normally extended to a student. For instance, in college, or grad school, there is a process for taking an exam. There is typically an affiliated study path, you receive f…
I would cram for hours before my blackboard interview making sure I knew all sorts of algorithms, just in case. My friend and I would quiz each other. I don't see how memorizing tree transformations relate to a Django application.
It made it so much more difficult to move jobs.
I hate coding interviews, because I freeze up and I look like a total idiot and cannot do even the simplest things. Same thing at exams in school or university - my mind just went blank and into a noisy self-rumination loop. I guess it's called anxiety.
I interviewed with Google last week and bombed it, even though the problem was quite simple and I would have solved it wonderfully without all that anxiety.
My mind just can't produce any sensible thoughts when someone's breathing over my neck and there's a timer. When I'm solving the problem in real time and talking about it, I have to stick with the split decisions that I verbalize and build on top of them, even though further down the road I realise they're not optimal and this contributes to the anxiety even more.
It's hard to 'refactor' your ideas during a 45m coding interview, but this is exactly the process we go through when we write 'real' code - we try a thing, then we improve it by refactoring, we optimize it, we find and fix corner cases, etc.
A take-home problem, on the other hand, would be totally cool. I have time to think about the problem, come up with solutions, optimize, unit test - do the real programming thing which I'm being hired for.
I would then gladly discuss and explain the code with the interviewer.
If then I would be given the task to extend the program with a new feature, then I would be familiar with the data structures and algorithms used and would probably find it much easier to extend, than starting with a blank file and figuring it out on the spot.
But I guess not everyone agrees with the home interviews - some think it's a waste of time and I'd have to agree..
So I guess the optimal solution is to offer the option of on-site coding interview or a take-home problem.
People like me would take the problem home, build it and shine at it, others, who's minds are sharpened by the adrenaline would take the on-site 1hr coding challenge.
Earlier quoted context omitted.
Good points. If you really care about being impartial, maybe have the 2 week period and a blind submission method in which the interviewer does not see when the assignment was completed.
But my rent is due the Friday after next and I need to know if I should send out another wave of resumes. It isn't but it strikes me we are looking very hard to find a new way to do things, when the old way was pretty damn good. Sit me down and talk about technology for ~thirty minutes. If I don't have the social skills to successfully do this (minority issue) I likely would not be able to communicate well with a tea…
Haha, exactly when was this 'old way' ever reality?
From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…
This does two things. In the long run, the time required converges towards where we want it to be (ASSUMING honest answers), and by bringing you in to talk through things, we can easily tell if these thoughts were your own by challenging you on specific parts of the prompt.
This is less than ideal since it costs the interviewee time, and time isn't cheap, but we've found that advance prep removes an even bigger wildcard in interviews: how you respond to interview stress.
From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…
This is very much true. We do take-home interview questions where they bring the output to the interview and we talk through their solution in person. We'll ask how long they took as a way to normalize expectations and also adjust the interview question to take more/less time in future instances. This does two things. In the long run, the time required converges towards where we want it to be (ASSUMING honest answers…
"That? Oh, it was no big, probably 20-30 minutes."
Earlier quoted context omitted.
Approximately weekly, when explaining something to another engineer.
Why don't you give yourself time to think? Why don't you use documentation? Edit: Oh, and how do you version control the white board?
Explanations work better without lengthy pauses. Ideally, I can explain the thing without stopping too long.
> Why don't you use documentation?
I do if it's necessary. Sometimes it's not necessary.
> Oh, and how do you version control the white board?
I don't.
~ every software engineer in the world
Anyone else realize we're the only ones who complain about this shit?