21–30 of 88 posts
One thing that's missing here is video camera feed. As an interviewer, I don't turn on my webcam and I don't expect the candidate to do it (although they can if they want to). However, I've heard different people have different opinions on this. It's definitely something that could go on this list for phone interviews. Of course, intra-US interviews are usually done over the phone but when the interviews are across c…
I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.
A very large number of job candidates aren't very good at this. So something like it needs to be tested for.
Personally, I love code. For me, an exercise like this is like whittling or molding clay, tactile and creative. I wouldn't want to work for a company that isn't interested in my craftsmanship, independent of everything else at higher levels of abstraction or closer to the business. Why? Because it will hire other people who don't care, and the code will be ugly, and it will be an eternal uphill battle to stay sane.
Yes, this seems to be a generalized problem
> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.
So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc.
This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code).
This has worked out reasonably for me.
Why?
> Immediately announce that you are done coding. Why?
I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.
I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.
The primary task of a developer in a modern "agile" team is to take a small bite-sized piece of functionality and alter or add code to implement it. A very large number of job candidates aren't very good at this. So something like it needs to be tested for. Personally, I love code. For me, an exercise like this is like whittling or molding clay, tactile and creative. I wouldn't want to work for a company that isn't i…
But this is completely unrepresentative of the actual kind of programming tasks at work (in my experience).
Modifying the behaviour of existing code, that you didn't write, in a way that minimises technical debt, is a completely different challenge.
> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.
I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index exp…
Does it? Why?