81–90 of 243 posts
I hope this article takes off so that my company will have to change its initial code screen. We make no use of xor in our rather large codebase (I’ve checked) yet pin a lot on whether an interviewee is aware of this trivia.
You have a single question that is always present in your "initial code screen"? XOR-only questions are poor unless you're interviewing someone for a very specific kind of role.
A fun party trick not mentioned here is reducing storage in a doubly linked-ish list: Normally each node stores 2 pointers: struct Node {void * prev;void * next} The trick is to use only 1 'pointer', storing prev XOR next: struct Node {void* xored;} While traversing, you remember not only the current position, but also where you came from. So forward traversal goes: next= current.xored XOR previous. Backwards also wo…
That is amazing and disgusting.
Earlier quoted context omitted.
I think it kind of depends on the type of programmer one wants to hire. There are different roles, solving different types of problems. There are places for people with technical brilliance, there are places for people with social brilliance, with both, and with neither. That's healthy. You want a diverse economy with different types of positions for different types of folks, and vice-versa. If I ask a half-dozen que…
> there are places for people with social brilliance, with both, and with neither. That's healthy There are lots of socially brilliant people out there, it's what many of us spend at least 20 years of our lives practicing. Why would being a brilliant socializer command the same salary that a brilliant engineer does?
A fun party trick not mentioned here is reducing storage in a doubly linked-ish list: Normally each node stores 2 pointers: struct Node {void * prev;void * next} The trick is to use only 1 'pointer', storing prev XOR next: struct Node {void* xored;} While traversing, you remember not only the current position, but also where you came from. So forward traversal goes: next= current.xored XOR previous. Backwards also wo…
> There are a whole bunch of popular interview questions As a very personal strong opinion, this makes me groan. I'm not concerned If someone happens to know some esoteric trick that they could Google search (Unless of course you're applying for a position at a company that manufactures very low level devices like microcontrollers or embedded systems and questions like this are _actually relevant_). I'd rather know w…
> pleasant person, are a team player, whether they have leadership aspirations, and take responsibility. I know the above is a popular opinion, but I've worked as a SWE at a company A that had a "technical interview" process and Company B that didn't have a formalized one. I would much , much prefer to work at company A (pay differences aside) because of the type of person who passes these interviews. It can be quite…
The thing to note is that, in exchange for this, Company A (probably) had a lot false negatives. So it comes down to whether you'd rather missing out on someone that would have been beneficial for the company (false negative) or have to deal with accidentally hiring someone that is not a good choice (false positive). The best choice to make depends a lot on the situation.
Earlier quoted context omitted.
I think it kind of depends on the type of programmer one wants to hire. There are different roles, solving different types of problems. There are places for people with technical brilliance, there are places for people with social brilliance, with both, and with neither. That's healthy. You want a diverse economy with different types of positions for different types of folks, and vice-versa. If I ask a half-dozen que…
> there are places for people with social brilliance, with both, and with neither. That's healthy There are lots of socially brilliant people out there, it's what many of us spend at least 20 years of our lives practicing. Why would being a brilliant socializer command the same salary that a brilliant engineer does?
> There are a whole bunch of popular interview questions As a very personal strong opinion, this makes me groan. I'm not concerned If someone happens to know some esoteric trick that they could Google search (Unless of course you're applying for a position at a company that manufactures very low level devices like microcontrollers or embedded systems and questions like this are _actually relevant_). I'd rather know w…
Nobody wants to see the XOR solutions. These questions are really basic and only filter out the non-programmers. Any decent programmer should be able to solve all of these without a problem.
> There are a whole bunch of popular interview questions As a very personal strong opinion, this makes me groan. I'm not concerned If someone happens to know some esoteric trick that they could Google search (Unless of course you're applying for a position at a company that manufactures very low level devices like microcontrollers or embedded systems and questions like this are _actually relevant_). I'd rather know w…
Maybe you feel like you are being inclusive and warmhearted for praising soft skill vs 'teh codez skillz', but please also consider that tech and programming jobs is like the last refuge for people with high technical aptitude and perhaps less social soft skills regarding the meta political and expectation games, eg people somewhere on the autism spectrum. Perhaps such interviews are overused but if the interview is…
> XOR all values between 1 and n An O(n) algorithm!? You'd expect there to be a closed-form solution for this, analogous to summing a series using n*(n-1)/2. OEIS to the rescue. http://oeis.org/A077140 gives ((n+1)%2)*n + (n+(n%2))//2 % 2
Err... if you sum all the numbers that’s O(n) as well.
Earlier quoted context omitted.
You have a single question that is always present in your "initial code screen"? XOR-only questions are poor unless you're interviewing someone for a very specific kind of role.
One of several. But I agree with the general sentiment.