The only thing doing tech tests has taught me is that I'm too stupid to do the job I've been doing professionally for the better part of 2 decades.
Can't just be me, can it? Currently 0 for 3 on interviews because I can't seem to get past the technical interview/test. Usually because of some crazy complicated algorithm question that's never been relevant to anything I've ever had to do on the job in all my years coding.
Also, while I'm ranting: screw the usual non-answer when given feedback.
You are viewing a single comment
A few years ago I was in a hiring loop where four interviewers grilled me on a number of subjects, including algorithms and data structures. They asked me all sorts of trivia questions on assimptotic complexity of this and that algorithm, how to implement this and that, how to traverse stuff, etc. As luck would have it, I was hired. I spent a few years working for that company and not a single time did I ever implemented a data structure at all or wrote any sort of iterator. Not once.
I did spend months writing stuff in an internal wiki.
I can't help but feel that those bullshit leetcode data structures computational complexity trivia are just a convoluted form of ladder-pulling.
My workplace has the opposite problem.
The company has been in dire need of programmers for years, so they hired people (including myself) without tests. However, the work involves lots of custom iterators and the occasional handcrafted parser, which most of the company is incapable of writing. The bright side is that management has their metrics mostly right, so I'm getting lots of raises for solving fun problems.
Ahem, uh, where are they hiring? Asking for, uh, me.
I don't see that as a problem. The job description of an engineer includes dealing with new problems and onboarding onto new things. So you never wrote a parser and now you have to. That's ok, just go ahead and start from the ground up.
What I perceive as a major problem is the utter disconnect between what companies test for, and what companies actually do.
It makes no sense at all to evaluate candidates on obscure trivia questions no one will ever care about or use, let alone reject an applicant because they mixed up O(nlogn) with O(logn). It matters more if you know a good, healthy answer to tabs vs spaces.
I once was a part of an hiring loop where we assessed a candidate, and one other fellow assesser wanted outright to reject the candidate because he failed to answer one of his questions on data structures. Everyone in the meeting voted in favour of that hire, except that one guy. When we asked to reconsider his position, he threw a tantrum because he felt that it was a matter of principle that we had to not hire a candidate that didn't knew trivia. The hiring manager asked if that info was important, and in case he felt it was whether it could be looked up online in a matter of minutes, but the assesser tried to argue that it was besides the point.
Data structures and algorithms trivia feels like ladder pulling.
You had me there, for a second
That sounds like a win-win situation. You lucky bugger!
I always just answer that with "do you want a software engineer, or a text book? If we need that for a project then I'll go dig out my college notes"
It usually works with other engineers, the issues are usually with the recruiters.