5 ms·
I share both of your concerns (while I was very lucky in getting initial experience, I know of other beginners that haven't/arent, so I'm very sympathetic.) . S
by ergothus 8y ago
I share both of your concerns (while I was very lucky in getting initial experience, I know of other beginners that haven't/arent, so I'm very sympathetic.) . Started coding for work in '95.
> was I wrong then? Or am I wrong now? Perhaps both.
Neither, I think. The Algorithm interviews are bad for 90% of the positions out there, and experience matters much more than trivia, so you were right then.
And today, everyone is trying to hire "senior" (and above), so there's no concept of "will learn, lacks experience" - and the algorthm questions do badly at identify THAT, so you're right today too.
It turns out that interviewing is hard, and we don't know what works well. Most of us think "we" are the ones that can obviously see what's wrong and everyone else is interviewing poorly. Most of us are wrong.
But even besides that, we need to focus more on getting newer coders that DON'T have experience. We'll spend years looking for people that have experience...longer than it would take to grow that experience. We want seniors because we want people that will grow without being mentored, because we have far more work than people...but we skip one of the ways to reduce that workload.
I'd much rather have an interview that was teaching something new, and see how the person processed it. That's not a good interview either, but at least it is trying accomplish the correct goal.
And when we do interview for senior and above, experience will count a lot more than building a frickin' linked list.
- lowdest 8y agoAs I see it, the difficult algorithm interviews screen for people who are motivated enough to spend 100s of hours studying for an interview, or know this stuff for some other uncommon reason. Both types are acceptable hires.
- jammygit 8y agoWouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? Personally, I'd rather not work somewhere that hired based on drilling fringe information - what will the job be like? Maybe I'll feel differently in 10 or 20 years
- brabel 8y ago> Wouldn't it be better to hire somebody who thought that was lame and who spent 100s of hours learning performance testing, new libraries, design patterns, or just working on projects? I would hope so, because I do all those things and, after over a decade writing software, find the ability to solve puzzles almost completely useless for most coding I've ever done. But reality doesn't need to make sense. So, if you want to work for Google or Facebook, learn puzzles anyway :)
- BossingAround 8y agoI really think it depends on the quality of the project. If I'm looking at a candidate, and see 3 projects, each pushed in one commit, each project has 3 classes in one package, and I see pushed compiled classes as well as source classes, that's a clear sign that this person doesn't know what he or she's doing. That may not be necessarily a bad thing, depending on the position of course. But projects are not the be all end all, at least not in my company, and where I interviewed.
- BossingAround 8y agoIt's interesting to me how many people value personal projects. From my personal experience, a confusing Github account with a number of small, questionable projects pushed in one commit half a year ago hurts you more than helps you. Personal projects are fine, but I think many people have the mentality of "getting a TODO app in Angular will help me waay more than implementing algorithms in C, that's useless!" which may not necessarily be true.
- jammygit 8y agoFair enough, the quality of the projects matters for sure
- pishpash 8y agoYes you get drones and autistic savants. Great!
- scottlocklin 8y agoblack pill: that's what they want
- yuchi 8y agoI’ll share my process: 1. The first interview must not be a technical assessment — identify shared interests, look for collaboration opportunities. You need to understand if the person in front of you will be someone you would work with for the next 10 years, their current technical skills have little to do with this. 2. At the end of the first interview, right before the logistic questions, assess how they position in the junior-senior axis — either with direct questions or by pushing them to the topic. Once you‘ve done that ask an evil surgically difficult question — the correctness of the answer is not what you‘re looking for: pay attention to how they present their (eventual) missing knowledge, or how the address the answer by giving context. A senior developer doesn’t know everything, but must know enough to manage gaps in their knowledge. 3. Search for young and talented people — search for the fire in their eyes. You want someone which, eventually, will reach goals by their own.
- dacur 8y agoSearch for young people? So discriminate?
- SturgeonsLaw 8y agoI read that charitably as "give newbies a chance"
- yuchi 8y agoYeah absolutely, it was in the context of the OP.
- Stratoscope 8y agoI really try hard to apply the principle of charity, but as a 67 year old developer who is still working, I'm afraid it's hard to read "search for young and talented people" without thinking of it as illegal age discrimination. That said, I do like the interviewing approach we're replying to, other than that "y" word... :-)
- 8y ago
- bradleyjg 8y agoIt turns out that interviewing is hard, and we don't know what works well. Most of us think "we" are the ones that can obviously see what's wrong and everyone else is interviewing poorly. Most of us are wrong. Cowen’s Second Law: There is a literature on everything. Hiring is no different. Why do so many of us that say “of course you shouldn’t reimplement timsort, stand on the shoulder of giants” either make up an interview process based on gut feeling or cargo cult one based on what we heard google does?
- james_s_tayler 8y agoBecause of Cowen's First Law: there's something wrong with everything. So no matter if you've read the literature and implemented a process, there is something wrong with it. That's why there threads persist. Every process has something wrong with it depending on who you are. Funnily enough everyone eventually manages to sort themselves into the right category. The system isn't broken any more than armed conflict is broken as a way of settling disputes. It's works, it's just a little terrifying and awful.