Mostly makes sense but your ability to write a parser is still going to depend on how many parsers you wrote or when you wrote them or whether you are able to use a framework/tool to do it.
How to conduct a good programming interview
181–188 of 188 posts
Re: How to conduct a good programming interview
#182Earlier quoted context omitted.
Why are the terrible engineers terrible, leading to them being fired (after 1-2 years?) I've not hired anyone who turned out to be bad at coding, but I have hired people who had other performance related issues, which were difficult to suss out during an interview. From my own personal performance, my approach to interviewing has led to far more true positives, than false positives, so I am biased towards continuing.
> other performance related issues What are some examples of these?
Typically it's patterns of repeated performance issues, such as providing estimates then routinely not completing work on time.
Or, failing to complete tasks they've taken on, requiring other teammembers to step up in order to meet deadlines.
There are more extreme cases, like insubordination, theft etc, but they are pretty rare.
Re: How to conduct a good programming interview
#183Earlier quoted context omitted.
> Engineers whos skills range from Great to Mediocre don't have a problem finding a job. How are you defining "skills" in this case? "Skills" as in the skills needed to perform well in the traditional technical interview gauntlet? If that's the case then you have a tautology on your hands. And if not, then maybe it'd serve us better as an industry to try to find a better proxy than the traditional technical interview…
Skills: writes code that's clean, efficient, simple, etc My question is this: Why does the industry need to change the interview process? If companies are able to maintain a quality bar of it's employees, and engineers are able to find meaningful employment, doesn't that mean the system, even if it has a flaw (false negatives) isn't really a problem? Perhaps the problem is that many of us who write code, consider our…
> Skills: writes code that's clean, efficient, simple, etc
> My question is this: Why does the industry need to change the interview process?
Because at the end of the day the process makes very little effort to optimize for any of those metrics of code quality you just laid out, and purposefully offers candidates programming problems and working conditions that deviate significantly from those they're likely to encounter on the job for no apparent reason, thereby hampering its reliability as a useful proxy for developer skill even further.
> If companies are able to maintain a quality bar of it's employees, and engineers are able to find meaningful employment, doesn't that mean the system, even if it has a flaw (false negatives) isn't really a problem?
No, it really doesn't. Just because a majority of software engineers manage to stay employed, doesn't mean we should ignore flaws in the system and insist that it's not a problem.
And if you would, take a moment to consider widening the definition of "companies" you have in your mind when you made that assertion. Yes, the process works well enough if you're Google or Facebook and have a constant stream of candidates and can accept just about any arbitrary false negative rate because you have the law of large numbers on your side when it comes to hiring. But startups and many non-tech companies large or small (most of whom don't have a lot of developer mindshare) often won't have that same luxury, because every month wasted in the hiring process to a high false-negative rate will take you that much closer to the end of your runway if you're a startup, and to the eventuality of being out-competed by a more efficiently run, technologically innovative competitor if you're just another technologically stagnating company. Countless numbers of these startups and technologically stagnating companies die off every year, and likely in no small part due to their inability to attract, recognize, and hire skilled developers in a timely fashion.
> Perhaps the problem is that many of us who write code, consider ourselves good at it, and getting rejected is a hit to our ego. We want to change how interviews are done _solely_ for the benefit of our egos, when instead, we should understand that if you interview, you might get rejected, and that is okay.
I don't doubt this is _one_ aspect of why some people want to change the interview process, but I emphasized the _solely_ part because I take issue with that part of your assertion. Getting rejected hurts, sure, and that can certainly bias one's judgement towards wanting change for their own benefit. But that's certainly not the _only_ driver for why people want to change the traditional interview process. You can see countless well-reasoned, rational cases, that make no appeals to emotion, for the many issues with the traditional interview process, both in this thread and elsewhere, made repeatedly by people from all walks of the industry from both sides of the interview process. Some people definitely do want to change the interview process for purely selfish reasons, but that shouldn't invalidate any of the countless well-reasoned cases constantly being made against the traditional interview process.
> Nothing is fundamentally wrong with the process, nothing is fundamentally wrong with you, and in 6-12 months, you can try again.
I would offer the counterpoint that, if nothing is fundamentally wrong with you, and you can get accepted again simply by applying again in 6-12 months, without having made any significant improvements to your skill level, then that is a clear indication there's something fundamentally wrong with the process itself. It all comes down to the fact that the ideal technical interview process should optimize for vetting for developer skill, and do so in a reliable fashion, minimizing both false negatives and false positives.
The traditional interview process has been well known to to exhibit a high rate of false negatives. If your company is deep-pocketed enough and attractive enough to candidates that you can afford the false positive rate by virtue of your naturally high rate of hiring, then by all means, keep using the traditional interview process. This is a process that has been proven to work well enough for companies hiring under those circumstances, and it's likely that for you, the risks posed by the high rate of false-negatives won't outweigh the risks resulting from adopting one of the less well-adopted and well-studied interview processes.
For everyone else, however, I'd strongly advise very carefully weighing how much risk you're really taking on by accepting the high rate of false-negatives that come with the traditional interview process, and consider one of the many possible alternatives to that approach before jumping blindly into that calgo-cult.
Re: How to conduct a good programming interview
#184Earlier quoted context omitted.
I love interview horror stories! In my most recent job search, which was early this year, I debated with one interviewer whether checking for key existence in a hash was a constant time operation. I insisted it was, and the interviewer insisted otherwise with the same amount of conviction. That was just a small portion of an all-day onsite interview. After leaving, I was told they were looking for a more senior candi…
Could just be a terminology mismatch. Checking for hash existence should always be constant, but checking for key existence is generally only amortized constant (that is to say, not constant across all lookups) - he may have wanted you to talk about addressing schemes and degradation at high load factors?
> checking for key existence is generally only amortized constant (that is to say, not constant across all lookups)
What you just described is "average" not "amortized". Amortized does not mean "across a set of representative inputs", it means "through time, even if given the same input repeatedly".
Amortized complexity is tricky sometimes. For instance, in a data structure storing a binary integer and allowing an increment operation, the number of bits flipped is amortized O(1). The same is true if the only operation is decrement. Neither is true if you have both increment and decrement!
Another example: you can change the accounting to make things amortized lower cost. For instance, a heap (aka implicit priority queue) can be said to have O(1) deleteMin by simply ascribing an extra O(log n) cost to each insert. In fact, you can say deleteMin has O(0) cost! An example of this being done in the literature is https://arxiv.org/abs/0903.4130, "Pairing Heaps with Costless Meld", by Amr Elmasry.
Re: How to conduct a good programming interview
#185Earlier quoted context omitted.
One of the worst interviews I've had the interviewer was not only similarly incorrect, but then afterwards proceeded to try to give me advice on interviewing skills, and how I should've "taken his hint" and been "more amenable to other answers". I probably would've been open to alternate answers if they were, y'know, factually correct.
If you think that's bad, I was this guy[1]. tl;dr: 1) Interviewer insists that an operation must be n^2 "because it has a nested loop" even though the nested loops are only iterating over their own subset of the master string. 2) Interviewer refuses literally any test that would help decide which of us is right. 3) Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agr…
> Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agreed-upon facts
That's a wonderful description of an attitude I have encountered many times.
Re: How to conduct a good programming interview
#186Earlier quoted context omitted.
>The cost of failing to hire a good engineer is small - they can just take the next guy. The cost of hiring a bad engineer is large. This is absolutely and completely backwards. The cost of hiring a bad engineer is small. You can always fire them. The cost of failing to hire a good engineer is enormous. You will never get a chance to hire them again, and probably all of their friends.
Firing is never fast or easy. It usually takes months to realize your mistake since it takes that long to get up to speed on a new job, And then you have to hire someone else, and get them up to speed. As a result, you're delayed by months, and out months of salary. Also, firing is terrible for morale. You really can't do it that often. Failing to hire a good engineer is only a big cost if you can't find a decent alt…
>Also, firing is terrible for morale. You really can't do it that often.
If you hired a bad engineer, not firing them is bad for morale, assuming you have a quality team. They will be pissed at picking up the bad hire's slack and spending so much time helping them.
>If you're paying a 6 figure salary with massive benefits like Facebook or Google, you usually have a long queue of qualified candidates to choose from.
But that's the exception, they have what most companies don't: prestige (rightfully or not). You listed the two companies that actually can get away with this without hurting themselves. Few others can.
See, this article wasn't written for Google and Facebook, it was written for everyday company CIOs, and this is very harmful for them for the reasons I stated. Who wants to spend hours writing calculators during an interview for Initech? Almost nobody. Also, a six figure salary is pretty much the norm for good developers all over the country. The main benefit for working at Facebook and Google is stock options and it looks good on a resume.
Re: How to conduct a good programming interview
#187Interviews suck for both parties, a world without interviews would be a better world. Why can't we just hire someone based on his experience and projects he previously worked on? You can have a first month as a "trial" where both parties can cancel the contract. Why interviews suck is because they are very, very biased and subjective and also not a good way to estimate the actual performance of a candidate. Say no to…
> Interviews suck for both parties, a world without interviews would be a better world. Actually, I rather like interviews. They typically pose some fun programming problems and I have a chance to talk about a lot of the cool work I've done over the years. Honestly, I do think the interviewing process is very risky from a company perspective (it's insane to me that companies will invest tens of thousands of dollars i…
I didn't say I didn't enjoy the interviews, I loved most of them where the interviewer was actually involved.
That being said, that's my point with interviews, if you don't trust something that the interviewer wrote on his CV (right 20 years experience and a history of successful products) then how can you decide to hire him or not after only a few hours of talking to him? You could have a bad day, he could have a bad day, it might happen that he knows exactly the question he has been asked or that he knows everything else EXCEPT that question. Usually it takes months of working next to someone to know how good he really is.
Re: How to conduct a good programming interview
#188Earlier quoted context omitted.
> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…
A friend just went through the hire process at FB for iOS. It actually was very practical. According to him it was more or less stuff we do every day, with one generic, programming puzzle of sorts.
Hey, I'm actually about to go through the FB iOS interview process and would really appreciate some insight/help from your friend if they have time. Thanks!