Earlier quoted context omitted.
> 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…
"Or had to find the O(x^n) and replace it with O(x^2)" The other thing that really seals the deal for me as an inferior interview question is that you don't need to have a clue what O(x^n) is to wrap some code in a simple time call, see that the code you think ought to run in microseconds is running in seconds, by visual inspection notice stupid nested loops, and fix it. Self-taught programmers may not be able to say…
How to Pass a Programming Interview
291–300 of 570 posts
Re: How to Pass a Programming Interview
#292"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.
Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".
Re: How to Pass a Programming Interview
#293If you have an unbounded abundance of good candidates, it is a different story then when you are a new startup fighting for talent. At highly targeted companies such as Google, Facebook et al, I'm sure that if they have a dryspell of good candidates in a given month (can't think of a reason why), then they revert to things like: "We don't care if you don't get the 'trick' immediately, we'll give you hints" and "we ju…
In Java this prints -4 int [] nums = { 2, -2, 0, 0 }; int dup = findDupe(nums); System.out.println("dup="+dup);
Re: How to Pass a Programming Interview
#294Earlier quoted context omitted.
Gotta say, this is incredibly discouraging for someone like me.
It should be encouraging because you're being told the truth and being spoken to like an adult for once in your life.
Re: How to Pass a Programming Interview
#295Earlier quoted context omitted.
Now they also tell you that it's OK if you don't finish the project. Yeah, they always say that -- but it's never really true. They should just be honest and say "If you don't finish the project in time -- then don't feel bad, but perhaps the test isn't right for you, at this time. Feel free to apply again in 6 months."
I've actually been through two interviews where I wasn't expected to finish the project, and I ended up getting the jobs. I think the difference there was it wasn't set up that it's "OK if you don't finish", but that "these requirements were crafted such that we don't expect you to finish".
Re: How to Pass a Programming Interview
#296Earlier quoted context omitted.
Gotta say, this is incredibly discouraging for someone like me.
On the positive side, no one can stop you from making lots of money using the internet. And if you have something that really takes off, those same investors will line up at your door.
Re: How to Pass a Programming Interview
#297Earlier quoted context omitted.
If you apply to Triplebyte you don't go through the full interview process at the companies we introduce you to. You skip the technical phone screens (most companies do 1 or 2 hour long phone screens before bringing candidates onsite) and go straight to on-sites. Where we can really save time is focusing on the matching process of candidates to companies. Interviewing is tiring and we find candidates often stop talki…
I don't really see how you are relevant if I still have to go through a technical interview - it still means the interview process takes way too much time and I am better of finding a way around it.
Just focusing on interviewing time, if you're talking to 3 or more companies that's approximately 3 hours of technical phone screens (usually repeating similar problems). With Triplebyte, you interview for 2.5 hours and save 3 (or more as you talk with more companies).
Re: How to Pass a Programming Interview
#298> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte. Thank you! This is a good write up and just like it concludes it's far from ide…
We're doing this differently at Triplebyte. We give everyone we don't work with (who does our final interview) a several hundred word personal email, with an explanation and advice on how we think they can improve.
Re: How to Pass a Programming Interview
#299Earlier quoted context omitted.
So, you may be right. Perhaps you're great at telling good programmers from bad. But almost no one does the analysis to really know if this is true (false negatives are the huge unknown). And most interviewers are not as good as you. The consistency between interviewers at the same company is low (we measure this). The consistency between different companies is low. We (interviewers) can do better than this!
I make no claims about false negative results. But I know that people that I've recommended hiring have basic analytical skills, can correctly code a Boolean predicate with a few connectives in it, and aren't confused by linked data structures. It's not a high bar that I set, and that's kind of my point: ask at least some low-bar questions! You can debate all day about how well candidates have done with the hard ques…
Re: How to Pass a Programming Interview
#300Interesting 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…
I am more interested in whether or not I can read the person's code, follow their logic, and if they think about logging, unit testing, etc.
Coding skill, while important, is a very small part of whether or not I am interested in a candidate. Soft skills are a much stronger part of the equation IMO. I could care less if a person can write a recursive function or if they don't know the performance difference between different ways of doing things.