331–340 of 384 posts
Required reading on the subject: https://erikbern.com/2018/05/02/interviewing-is-a-noisy-pred... I realize that there are problems with it, but I'm a huge fan of take-home problems that are similar to real problems the candidate would face on the job.
Earlier quoted context omitted.
Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly n…
"The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list." I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who w…
Earlier quoted context omitted.
I don't think any good senior devs are under the illusion (privately) that they're rusty at whiteboard interviews. I'm certain my college grad self fresh out of practicing for the ACM contests could have run circles around my recent job search self when it comes to algorithm stuff. I had to practice and then pass a ton of whiteboard rounds to get my current senior developer job, so I'm not saying this out of bitterne…
Saying that "you're not payed for that" is risky. Yes, you're technically right but when you will be at your new fancy job you may need to do MANY things that you aren't technically being payed to do, so that you can deliver. That IMO is one of the essential skills a senior developer has, not that they can do things a junior developer can't, but that they have a breath of knowledge and skills that make them good juni…
Guess I was too expensive, heh. The tone of the declination was actually super kind.
Earlier quoted context omitted.
Yeah this somehow still works for pretty much every other profession, and worked fine for programming until a few years ago when everyone decided timed programming challenges were the way to go. I wish all jobs could just hire devs for short contracts then convert the keepers to full time. I'd be more than happy in that scenario because I know they'll want to convert me and now it's up to me.
The big problem with this is that the short contract does not guarantee continuity of health insurance coverage, and this is a dealbreaker for a lot of folks. The pool of applicants who would accept these offers excludes the top-performing folks who have much better alternatives than contract-to-hire.
For this reason, experienced developers from other countries which have universal healthcare coverage and low cost of living, such as many Eastern European Countries, are very attractive to many startups.
My feeling now is that the fact that it is arbitrary and doesn't have that much to do with real-life work may be a feature. You can dissect job performance in a number of ways but I think most people would agree that these four factors are important: general cognitive ability, conscientiousness, domain knowledge and motivation. And of those, domain knowledge is already relatively easy to discern from the resume and otherwise easy to screen for and if your company is doing anything unique, not as important in the long run. Almost any process would do a sufficiently good enough job of taking into account relevant domain knowledge. Thus what makes one process better than others has more to do with extracting other signals.
Whiteboard coding interviews, by being timed, somewhat arbitrary, yet something that is widely practiced and easy to study for, implicitly selects for cognitive ability, motivation and conscientiousness. It's hard enough that you can't be dumb, it requires enough preparation that you have to be somewhat motivated. And the process of preparing for interviews is sufficiently repulsive and it's easy enough to fool yourself that you're prepared enough when you really aren't, that studying to the point where you're prepared is a test of conscientiousness. This creates a paradoxical situation where the test itself isn't necessarily that relevant for the job, yet those who get through the test are almost always very good.
In short, given that what you need to do to pass these interviews is fairly widely publicized, the ability and willingness to do what it takes to pass positively signal that you'd make a good employee. Even if you're great at software development, if you're neither sufficiently motivated nor conscientious enough to prepare yourself to pass these interviews, it's unclear to me why you'd also go out of your way to excel at any given job - every job requires you to do things you don't want to do, learn what you don't care to learn and deal with a variety of suboptimal situations constructively. So while I'm sympathetic to the point of view that this shouldn't be how things are done, I think the willingness to say, "you know, this is how things are, so let's deal with reality as it is instead of wishing it away and ignoring some of the best job opportunities because I don't want to study" is a positive characteristic. Every job has challenges like that - something that in an ideal world is kind of stupid, is not at all fun to do and takes a lot of effort, but doing it is strictly better than not doing it. You want to hire people who are willing to do these things, not just complain about how stupid it is.
Earlier quoted context omitted.
One problem I have is at my level it's really more about architecting than coding. Although coding is still important. (And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.) But the main parts of my job I have to get right are picking the right approaches technolog…
> It also takes a good architect to interview an architect And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to inter…
Earlier quoted context omitted.
> It also takes a good architect to interview an architect And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to inter…
Why is this getting downvoted?
I reject senior software engineers all the time. I give interviews on whatever language you're most comfortable in, I'm not interested in time or space complexity, I just care about how well you can use your tools and debug. I'm continually astounded at the number of people who can't sort a list (with their language's standard library), clone an array, or do basic string manipulation. I've had a staff engineer at Goo…
Lol. At my job, I code in several different languages. Sometimes, a new project requires me to to learn to write in a new language. It's not a big deal... Programming is pretty general, so new syntax doesn't slow me down too much. But I can't tell you what the sleep command is any of these languages. I look it up every single time :P
Earlier quoted context omitted.
Lol. At my job, I code in several different languages. Sometimes, a new project requires me to to learn to write in a new language. It's not a big deal... Programming is pretty general, so new syntax doesn't slow me down too much. But I can't tell you what the sleep command is any of these languages. I look it up every single time :P
I’m starting to experience that too, where as the breadth of languages learned widens I forget the language specifics and really keep the generic terminology keen. Searching questions like how to sleep in LanguageX, how to iterate, create a thread, whatever need be. https://en.wikipedia.org/wiki/Interference_theory#Retroactiv...