221–230 of 570 posts
Earlier quoted context omitted.
I feel ya buddy - come and join the wacky world of front end development where these things matter less ;)
I wish. I've been asked these kinds of questions for jobs that are just gluing libraries to JSON coming from a backend.
Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…
> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…
If your job is mostly frontend, yeah, you probably won't need to worry about this problem. But if you're hiring somebody to work on graphics? You better be doing complexity estimates in your sleep.
Earlier quoted context omitted.
> I'm pretty good at avoiding "false positive" results And you know that...how exactly?
Because a false positive is very visible - you've got a terrible engineer bringing everyone down. It's the false negatives that are harder to detect...
Earlier quoted context omitted.
There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.
A resume should reflect your current skills and abilities. You should feel free to leave in old positions, and the interviewer can ask about it if they want, but you should not leave in technical things you don't want to be asked about.
Earlier quoted context omitted.
I wrote some Ruby in an interview. It was so terse, I had to explain to the interviewer (who favored Java) what the code did, and why it was linear instead of O(n^2). That was actually kind of fun.
If your code is sufficiently terse that it's not very understandable (such that the complexity isn't very understandable) surely that's a realistic red flag?
Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…
Earlier quoted context omitted.
But the people who'd need that the most are the ones furthest out of school. I shudder at the thought of ever having to do another programming interview. Well, alternately shudder and laugh. What a joke!
It's my belief that the best experienced programmers don't have to go through programming interviews. Even if you don't actively make an effort to network, you have a network of people who know you're good enough to outright hire without the whole rigmarole. Companies who aren't finding people like this are missing out on many of the best.
Not sure why you think this is the case. It is really easy to end up with a worthless network (I managed), and many larger companies insist on forcing every applicant through the HR hiring funnel for compliance reasons.
I remember the best interview I had was at a company offering open source software. For the coding components of the interview they give applicants a task (they cherry pick one of the easier ones) from their JIRA backlog and told applicants they've got two weeks to come up with a patch. It didn't matter if the applicant could fully solve the bug/feature, since it's not particularly fair to expect the applicant to be familiar with the ins and outs and gotchas of the system they are working with, but what did matter is that they A) submitted something, and B) could talk their way through their thought process and how they arrived at their current solution.
This sort of process really clicked with me. Obviously it's not as straightforward for some organisations that may offer proprietary software, but the process could certainly be adapted for a lot of organisations, in my opinion.
Interesting article. For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them. We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonde…
Mostly, we want to see how well the developer can explain their decisions throughout the process. Maybe they made a shitty decision. If they know it, and explain why it was shitty, that's a pass.
When I joined the company, the exercise took me about 3-4 hours. I don't think that's a ton to ask, especially if you make the onsite interview less intensive (which we do).
The practice section doesn't mention anything other than the book. Are there any other resources that people use to prep for an interview? Looking for something that tests algorithms and data structures more than solving tricky problems.
For a refresher on algorithms and data structures, I also like the Harvard CS50 videos up on YouTube. They walk through sorting algorithms and cover the bases of various data structures.