Why is there so much aversion to proving one's abilities? Programmers today feel they shouldn’t have to do whiteboards, hackerrank, or take-homes.
How does a prospective employer evaluate someone’s problem-solving and programming chops?
How does a prospective employer evaluate someone’s problem-solving and programming chops?
But hackerrank/leetcode don't test for those skills. They test your ability to memorize solutions to trivia questions, typically things you'd never be asked to do in the workplace.
There's enough to learn to be good at software without having to also memorize arbitrary trivia.
I understand that at many companies, they just use pre-canned questions and all the above criticisms apply. But I don’t think this is the fault of the platform; it’s a conscious choice of the company to do so.
That's not really true. Most of them are variations on a relatively small set of techniques. Dynamic programming, back tracking, tree traversal, sliding window, greedy algorithms, and minimal connected tree will solve 90% of them. And those are all techniques that are occasionally useful.
Sure, some of them will have some esoteric math or algorithm that makes the solution trivial if you know it. Or sometimes there will be some confusing wording. But so long as they're not like that it's a pretty fair test.
Shouldn't we be testing for skills that you will be using 90% of the time in your day job rather than skills that are occasionally useful (and thus could be looked up / learnt on demand if necessary).
I know developers who have written books on subjects related to development and are 100x the developer I am, but have no knowledge of DP beyond what was taught to them decades ago because they never used it when helping to build systems used by millions of customers.
Because it doesn't necessarily prove one's abilities. Each of those items have pretty obvious flaws:
- Whiteboard: Usually idealized problems requiring specific knowledge that is easily looked up, but not necessarily in one's short-term memory. Whiteboard is generally not the tool one uses to write code. It's very easy to bomb these sessions despite being competent.
- Hackerrank: Easy to cheat. Usually toy problems with idealized properties, i.e. they don't have the dirty edge cases you see in real world development. This also tends to be just a first-pass filter for getting an phone interview or maybe on-site.
- Take Home: Easy to cheat. May run afoul of existing employment agreements. Requires a pretty large up-front time commitment, and IME does not actually avoid the on-site whiteboarding sessions anyway. It's more of a first-pass filter.
> How does a prospective employer evaluate someone’s problem-solving and programming chops?
That's the million dollar question. As an industry we just don't have a good system for identifying competent developers. My personal approach is to stick with folks I've already worked with, who have a long track record of delivering. That doesn't scale at all and is not very good for folks just entering the industry.
I truly wish we had better answers and I support anyone trying to build something that explores the problem space. It's nice to have diversity in hiring practices.
Writing algos from memory on a whiteboard is not what I do in my job. It isn’t a subset of what I do in my job. It isn’t something I have ever done in a job at all. You may as well be giving me a first year chemistry final.
So it is just something I drill, forget, and then re-drill when I want a new job.
I am fine with take homes though.
The same problem happens with take home tests. It pretty much optimises for people with more time on their hands (i.e. people who don't currently have a job, people without kids etc).
In both cases a lot of good people will be filtered out. Some people think it's good to avoid bad hires at all costs but I don't think wasting people's time is particularly ethical.
there's market leaders breaking new grounds every day, and for those I'd say it might be appropriate.
then there's your average bookkeeping application that is at most transforming existing data based on problem already solved by the customers, and these are like the majority of jobs on the market, but still pretend to hire the best 10th percentile - except they don't provide a 10th percentile pay and the job is boring and soulless so they probably won't even have a 10th candidate apply to begin with
> How does a prospective employer evaluate someone’s problem-solving and programming chops?
how do factory evaluate the capacity to tighten bolts?
this problem was solved by Ford a century ago.
if one's building run of the mill business software with spaceship grade engineering, you're trying to solve a hiring problem you shouldn't be having to begin with.
I am ok with leetcode screens ( actually enjoy them) but I hate take home assignments. Worse is now companies asking you to do both.
I'm slow and methodical. I'm proud of it. My code runs for years in demanding environments without breaking and I'm famous for it, at least within my own network. My code is boring. The tech I choose is boring. The solutions I deliver are predictable.
Hiring an experienced engineer is not difficult. Can the person do the work? Can we see some examples? Will they get on with the team? How quickly can they get up to speed? Will they deliver value to you?
So when hiring, I don't care if you're slow and methodical, or super fast. What I care about is that you understand basic algorithms and data structure (lists, sets, maps, trees) and can apply them to simple problems without me telling you that using a hash map here will speed up the solution tremendously, or using a heap will simplify the code. Those simple problems are also taken from most common patterns we see in our codebase, which consists of lots of geospatial data processing and analysis.
And if you need more than an hour to solve a couple of those simple problems (let's say, find duplicates between two lists), you'll definitely have a problem fitting in with the rest of the team - since everyone on the team has solved those problems and agrees that we need people with at least this basic algorithm knowledge to be able to make a significant contribution here.
These questions also a first hour of the interview, the rest goes deeply into discussion of previous projects you made, different architectural patterns, etc.
result = set(l1) - set(l2)
Time taken: 20 seconds. I take your point that you need people with at least a certain level of competence. I found I saved those who were hiring an awful lot of time by sending them example code or asking them to give me a challenging weekend project as a test, perhaps even something they needed doing for real. But I dread these exam-like online tests where I have to have a right answer in 20 minutes. I don't work like that. Few people over 40 do any more.
And there are many developer position applicants that wouldn't be able to do it. If you actually solve it in 20 seconds, I presume you passed the test.
Is this a flaw or a feature? What I'm really asking is: is it a coincidence that some of these tests may tend to filter out an older demographic? It may be yet another one of those ways that some people can be filed away as not being a "culture fit" or whatnot.
To be sure, there are companies that do care about domain experience - and I personally value it as well. But that experience often carries a price that some companies will jump through hoops in order to avoid paying. I've seen that first hand, unfortunately.
Some people complain that the questions and exercises being asked are silly.
And most people are bitter about a rejection and want to vent.