81–90 of 243 posts
> "I’m writing this as an interviewee, having never been on the other side of the interview table ..." > ... > "Most candidates will have side-projects or work they’ve done for previous employers." As someone who has actually done a lot of interviewing, I can say with great confidence that this is simply wrong. At my current employer, we have a "homework assignment" as part of the interview process. We tell candidate…
Earlier quoted context omitted.
The difference is the interviewer is being paid for their time, the interviewee is not.
Then pay the candidate! It might seem ridiculous but consider how much time is spent by interviewers, hiring committees etc, giving some fraction of that out even to utterly worthless candidates might not be the worst idea in the world. A side effect of this is that suddenly the cost of a bad screening becomes more intuitive
Hiring a bad developer can be a costly mistake. In addition to the costs for the developer, there are often other costs and productivity lost. Basically a good coder is not the same as a good developer. Coding is relatively easy - if you can visualize and solve problems using code, then you're a good developer. It's the thought process that makes you a good developer. Coding challenges are often a good way to test th…
So the candidate doesn't want to spend 1 hour on a coding interview because 'they don't have time.' The solution?
Spend a month on-boarding the candidate to your company (taking time from multiple team members), give them an implicitly high stakes work project while they get used to the new working environment and production codebase.
Meanwhile there's tension/friction because the company wants to quickly validate the temporary hire. If it's successful, okay proceed as an employee. If it's unsuccessful, it's a huge waste of everyone's time, a costly experiment for the company/team, and likely a very unpleasant 6 week long working engagement. Then the candidate will have to explain why they only lasted at their previous employer for 6 weeks in their next set of interviews.
I do, however, not expect any candidate to do anything we haven't had to write ourselves. I also let them look up Google/StackOverflow etc during the interview. They're also offered a beer but nobody ever takes me up on that.
- It's designed to take about the same time as the round of interviews it replaces (half a day), and we clearly communicate how polished and complete we're expecting it to (not) be in that time.
- It's a lot like the actual work; if you enjoy it / are good at it, there's a good chance you'll enjoy / be good at the job. It helps make sure (on both sides) that the job is a good fit.
- But at the same time it's designed to be obviously not actually work we're going to use; we're not exploiting unpaid labor.
- There aren't gotchas to it. We review it with an eye toward "if my coworker showed me something they'd been working on for about this long to address this problem statement, how would I feel about their work," and do our best to express that.
- The rest of the application process takes the challenge into account in a positive way. I might have a conversation with you later to understand how you think about the problem you solved, but none of the interviews have to be gotchas or on-the-fly skills tests because I've already seen the kind of work you do.
- Everyone takes the same challenge, and it feels way more fair to discuss candidates based on reviewing how they do the kind of work that we do, compared to "X person has a cool open source repo; Y person gave a good interview answer to this technical question; Z person worked at an interesting place in the past." There's still some apples to oranges in comparing coding challenges, but much less than comparing one person's bootcamp group project open source repo with another person's reason that their best code is closed source but it sounds cool.
With a well-designed challenge the benefits on the hiring side are really obvious (we actually have a basis for comparing applicants that feels somewhat related to the work they're going to do), but also (I hope) we've managed to make a better process for applicants without expanding the time they're spending.
Earlier quoted context omitted.
This one? https://leetcode.com/problems/two-sum/ >>> Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target. You may assume that each input would have exactly one solution, and you may not use the same element twice. Seems trivial enough to me... except if the interviewer forgets the hard constraint that there is exactly one solution, then that's a shi…
Does the problem actually have that constraint? If so then yeah it's significantly easier. I thought the reason you'd have to use a clever algorithm is because a brute-force solution to find all index pairs would require n^2 operations, where n is the size of the input array, because you can't stop after you find a single pair.
If you can create a new array containing indices to the original array, sort the new array, and use two pointers starting at the beginning and the end of the sorted array to find a solution, it takes O(n×log(n)) time. It is not necessary to assume that the solution is unique, assuming it is okay to simply write one of the possible solutions.
If all values are between 1 and k, and you can make a k-sized array, you can find a solution in O(n+k).
No matter what you do, you can't get better than O(n).
The important thing is that there is more than 99% chance you will never have to solve this problem in your job; and even in the case you would, there is 95% chance that the O(n×log(n)) solution would be acceptable regardless of whether it is the best possible or not.
Earlier quoted context omitted.
If we're being very charitable I guess the idea of using a HashMap for an optimal solution might slip your mind but even a freshman in CS can just loop twice over an array and solve it.
I might be misunderstanding the question; how many pairs can there be? You can't just loop over the array twice to find all qualifying pairs of indices, if there are multiple. You'd have to loop over the array n times, where n is the size of the array. Isn't that why the question is difficult? There doesn't seem to be much incentive to using a hash table, complexity wise, if you could just solve it in O(n) time and O…
Yeah, you just do it in O(n²) worst case because the problem is O(n²) to find all pairs that match because there can be O(n²) pairs.
However he meant one pair here too. Pretty easy to solve. Did it in under 30 s in Python on my broken cellphone. If there are multiple pairs, just replace return with yield.
I require them because candidates lie, not always intentionally. The unfortunate reality is that it can be really tough to fire low-performers. I NEED to know that a candidate can do the work. We go out of our way to make our ask reasonable, relevant to the role, not spec-work, not time consuming, and well defined. It's not uncommon for us to learn that the candidate can't actually do what their resume says they can…