71–80 of 471 posts
How can more companies adopt this and give candidates more take home tests rather than leetcode
Earlier quoted context omitted.
> they often give a very good and reasonable signal that often has a high corollary to work performance Do you have any statistically significant data to back this claim?
There is statistical data saying the opposite: http://chrisparnin.me/pdf/stress_FSE_20.pdf That whiteboard interviews are actually testing how you perform under stress rather than how good you are at your job. Additionally, in my opinion, it measures how good the interviewer is. If you get a bad interviewer or even just one in a bad mood, just pack your bags because you aren't getting it. Whiteboards are incredibly a…
Interesting study and really good discussion on HN at the time, but the opposite of "[Whiteboard interviews] often give a very good and reasonable signal that often has a high corollary to work performance" would be something like "People who do well at whiteboard interviews tend to be worse performers at work." I don't think that's what the study said at all; rather that people do worse at whiteboard problems when they're being watched vs. not being watched.
Earlier quoted context omitted.
Which is why the interviewer should ask specific and thoughtful questions about the project, so they can gauge the candidate's level of understanding. This concern could also be addressed by introducing a trial period.
>This concern could also be addressed by introducing a trial period. Why would I leave a stable well paying job for a job that basically says they don't trust me enough to not fire me in two weeks?
Earlier quoted context omitted.
I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't real…
I don't see a solution for this. What you're describing is someone who's clearly good enough to take a project and rewrite it, and still be able to talk in detail about the code. I'd bet they could also pass a whiteboard, pair-programming or take-home test too. That they are willing to lie about it and pass off other's work as their own isn't something that you're going to identify in your typical code interview. Usi…
But I'm not sure, I've never interviewed this person.
No one enjoys whiteboard interviews but it's not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I'd prefer the employer look at my GitHub profile as there's plenty of code there already. Furthermore, I'm not a fan of "interviews" in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.
I think part of the problem is not everyone is good at giving interviews. But most software engineers can talk about their work once you get them going.
FWIW, I think white boarding interviews are pretty fun.
Here we go again perpetuating the stereotype of the whiney privileged engineer put in a position of mild discomfort by the villainous abusive white board interview boogeyman. I don’t mind whiteboard interview exercises. They’re not great, but they often give a very good and reasonable signal that often has a high corollary to work performance. I think there’s bigger fish to fry in refining fair and objective intervie…
Earlier quoted context omitted.
I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't real…
One question is, if someone is doing elaborate deceptive work like this, gets hired and has no problems performing the job, does it actually matter? Some people mostly or entirely code at work, so this looks like a legitimate way to get a "good" project in GitHub that he knew well. It sucks that it's deceptive (which could be a major red flag), but it's also clear enough that he understood a large codebase well enoug…
I put the anecdote up as a real-world example of one way the GGP's github reference can be faked.
You would have to dig really hard into their knowledge of the system to catch them, which you wouldn't have time to do.
For instance, I believe the issues would show up in a benchmark.
The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews. Pair progr…
It is very easy to completely forget all about graph algorithms in, say, 3 - 5 years during which time you've been a productive, valuable member of a software development team that...you know...actually builds things customers care about.
I interviewed at one of these companies in the list. I'm nobody special, did the test, did the interviews which were more about doing the work and how it gets done and I how I think about it, and they made me a really good offer which I accepted.
No one enjoys whiteboard interviews but it's not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I'd prefer the employer look at my GitHub profile as there's plenty of code there already. Furthermore, I'm not a fan of "interviews" in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.
Recurse Center has a pretty nice model where they give you a part of a program (small) to bring ahead of time (or you can pick any program you've written) and the interview is going through the code and adding a feature or two. That kind of interview mitigates the amount of trivia and preparation-gaming while also ensuring that the applicant can solve problems as a team and is a competent programmer. It is cheatable…