151–160 of 226 posts
Earlier quoted context omitted.
I can never remember how modulus works, I use it so infrequently.
Just use n & 1 then. An odd number ends in binary 1; and’ing it with 1 yields 1 if its odd.
Earlier quoted context omitted.
There's also the issue of scalability. Grinding leetcode at least scales horizontally to a huge number of companies. Homework is typically useless outside of the single company you're doing it for. I generally refuse all takehome assignments unless: 1.) It sounds uniquely interesting and fun to do. 2.) The company is prestigious enough, or pays well enough, that making any effort to try to get the job worth it.
Why would you be interviewing at all if the criteria for (2) isn’t met? Unless you’re just trying to get interview practice or keeping them as a safety option.
A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…
> “take a novel problem that they haven't seen before and break it down” But who does that professionally as a stand-up performance, clock ticking, a judge breathing down your neck who has been equipped with a script that tells him things like “if candidate doesn’t do X within the first ten minutes it’s very bad”? Doing well in that situation depends more on social performance skills than problem-solving skills. You’…
Your experience sounds horrible, and unfortunately those sort of "tests" are just a horrible thing. Generally, do NOT do take-home exercises. That's your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it's less what you know, or…
> Often it's less what you know, or could do; and more about "can you do the test?" It really depends on how you create the test and how you review it. You can prepare one where the actual solution is 10 lines of code and anything else is exactly for showing what the candidate knows / could do. I used something like "read data from CSV, write it to sqlite, treat it like a mature production app, feel free to use place…
I keep seeing people claim that no one offers alternatives to live coding in interviews, but not only does the author provide an alternative (take home coding test/project), there are obviously many alternatives to live coding. I've been working in this industry for over two decades, and I've interviewed more candidates than I can count. I can assess a candidate with a 20 minute conversation, because a candidate's un…
Earlier quoted context omitted.
I don't get what's insulting about it and I'm glad I had the chance to prove it instead of people just binning my resume with experience the were obviously skeptical of.
Maybe it's not insulting, but it sure as shit is pointless.
A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…
Since there is no CS equivalent of a professional engineering exam, employers have no guarantees that applicants will meet minimal qualifications, and so we continue to see an arms race of increasingly complicated whiteboard / leetcode interview processes.
Your experience sounds horrible, and unfortunately those sort of "tests" are just a horrible thing. Generally, do NOT do take-home exercises. That's your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it's less what you know, or…
Earlier quoted context omitted.
> Often it's less what you know, or could do; and more about "can you do the test?" It really depends on how you create the test and how you review it. You can prepare one where the actual solution is 10 lines of code and anything else is exactly for showing what the candidate knows / could do. I used something like "read data from CSV, write it to sqlite, treat it like a mature production app, feel free to use place…
Your test sounds like what people complain about. You give them instructions but it's "really about ... ". Just ask them what you want them to know. If you hired this person and they turned in code without error recovery or encoding, you'd tell them they need to add it and they would. No need to obfuscate your intentions and have them read your mind in what you're looking for. No take home test is even needed. A simp…
You can't really ask about those things directly. If I ask "(how) would you add monitoring to this?" you can make something up on the spot. If I ask "what else would a mature production app contain?" that will give me a better idea of what you're familiar with.
> you'd tell them they need to add it and they would
Different levels. We were not after juniors in that case, but people who can do independent work. The question would be way more specific otherwise.
> No need to obfuscate your intentions and have them read your mind in what you're looking for.
It's not about mind reading. For that role, you either know how to create/manage serious applications or not. Your specific ideas may be different than mine and that's fine, but the general areas of interest will match. E.g. whether you register some event notifications, do text logging, persist decision journal, or do something else — you'll likely mention that. And you may forget/miss one or two things - that happens. But you don't miss them all if you're a good candidate for that position.
Earlier quoted context omitted.
> Often it's less what you know, or could do; and more about "can you do the test?" It really depends on how you create the test and how you review it. You can prepare one where the actual solution is 10 lines of code and anything else is exactly for showing what the candidate knows / could do. I used something like "read data from CSV, write it to sqlite, treat it like a mature production app, feel free to use place…
That's like a trick question given that interview questions typically want the opposite.