Comment by ezekg | Hacker News Reader

Comment by ezekg | Hacker News Reader

Not entirely applicable to this particular quiz (most of the questions were relatively simple until the final few), but the interview questions like the ones that Hired and Triplebyte focus on honestly make me feel like an imposter.

I've been a software developer for over 4 years but I don't have a formal CS education. I've gone through CLRS along with MIT's open-courseware--but I rarely use any of that directly in the workplace and so have forgotten a lot of it. And I think I'm a pretty good software developer, yet in the past when I've tried to get into Hired or Triplebyte, I always leave feeling like I don't belong in this profession because I can't tell you the big-O complexity of DFS off the top of my head, much less write the algorithm on a scratch pad.

I've been doing technical interviews for a few weeks now (I was recently laid off) and I'm honestly just a little tired of the brain teasers and non-applicable algo questions--and more often than not, the interviewers flexing their "knowledge" muscles.

Case in point: I'm in final stages with multiple companies for a Rails position, yet only one of those had even mentioned Rails in the technical interviews--the others decided to quiz my CS knowledge and one of them even quizzed my FP knowledge (for a Ruby position…). I don't understand it.

Hello Ezekg,

I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea).

This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.

Do you truly believe that being really good at CS will magically make you a skilled programmer?

Are they not different skill sets? One is a practical skill, the other an academic one.

I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag.

I've watched online lectures where Doctors of Computer Science lecture about OO but clearly have no understanding of what works and what doesn't.

I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains.

I suspect I could add the word small to advantage and subset and that statement would still be true.

I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.

I certainly didn't mean my reply to be condescending. Are you objecting to the word magically?

He literally says that one way to be a skilled programmer is to be really good at CS. How is that not magically? What word would you have used?

Unfortunately, your reply is clearly condescending. And adds nothing to the discussion.

Do you truly believe that being really good at CS will magically make you a skilled programmer?

Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.

There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution.

I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.

That is nice, however when hiring people it is useful to get somebody who can actually implement the solution too, rather than just sitting back smugly having identified a problem as "Dijkstra's".

If somebody can get as far as recognizing the problem as requiring Dijkstra's algorithm, they can go pull a book off the shelf, or use Google, and find the details of the implementation. Or, more likely, find a pre-existing implementation[1] that can be re-used.

Personally, I doubt that many people are walking around with the deep details of Dijkstra's memorized and readily available, unless they have a job that very specifically focuses on graph operations and they do nothing else day in and day out. So you could memorize it just for the interview, and then forget it again by the next day. But is there really any point to all that?

[1]: https://www.google.com/search?num=30&q=graph+algorithm+libra...

There are however people who can fairly easily write graph traversal and recursive code on a whiteboard. I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.

I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.

Fair enough.

I agree with this--but I don't think the interviewer should be asking for an implementation of Dijkstra's in the first place. That's my whole point--it's not a real world problem to need to know an algorithm from memory. If I need a particular algo, I'll look it up and find a supported open source library that implements it 10x better than I could have.

My point is that you can gauge somebody's knowledge without making good software developers feel inferior e.g. by asking them how they would go about finding a person's likely connections given some weighted data for an imaginary social network. And then you can maybe get responses like, "That's a good question--I've dealt with that before when I was working on X, Y, Z and ended up using weighted graphs according to how many friends a person had in common …" or "I'm not entirely sure on the exact algorithm I'd recommend, but that sounds like we would set up a weighted graph and go from there …".

Rather than making talented people feel stupid, you encourage conversation. But what do I know, I don't interview people every day so take what I say with that in mind. I just think tech interviewing is broken. I'm always left frustrated and my excitement to join the team dies down due to thinking I won't fit in because I'm not "smart" enough.

> Are they not different skill sets? One is a practical skill, the other an academic one.

I'd like to see you design and program a P2P networked program without any CS knowledge, like Kazaa or Bit Torrent, that actually works as well as they do.

> I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag.

That's true for lots of fields, but it's not hard to see that that doesn't mean theoretical knowledge isn't useful.

> that actually works as well as they do.

I doubt most CS grads could do this. One hard part of it is the p2p (but that's already been solved [0]). Having a project that large where you don't eventually shoot yourself in the foot because of architecture and finish in a reasonable time without using too many resources on a user's computer is also a hard part.

[0] https://github.com/bittorrent/libutp

> I doubt most CS grads could do this.

Of course not, but the point is that the information can be valuable for making real things.

It's a lot, lot easier to read papers on the algorithms needed by, and understand the specific requirements of, a particular project than it is to learn the entirety of software development outside algorithms ad hoc.

Honestly, even though I do know a fair bit about the Bit Torrent algorithms, I wouldn't trust that knowledge since it's most likely out of date or incomplete. It's deserving of research for anyone, even people who 'know it already'.

That's why I don't understand these narrow algorithmic tests - very, very seldom is a priori knowledge about DFS vs BFS going to be something that makes or breaks a project.

It would be akin to testing civil engineers on the memorization of precise ratios of the ingredients of concrete in current usage, instead of on the broad applicability of particular materials to particular purposes.

Yeah, I'd love to know how they test civil engineers in interviews.

For a working peer-to-peer network, who would you bet on to get a working solution first:

1. a programmer without any formal CS training

2. a CS graduate without any practical programming experience

Most programmers without CS degrees would pick up the concepts needed in a few days, most CS students would take months to even be able to finish a basic program. And it would fall over as soon as you sneezed at it.

While there will be exceptions on either side, run that race a thousand times, and the programmers would win the majority of times.

This is why I said you'd have to squint really hard to find something like this. You're clearly moving the goalposts here. I didn't ask about just a working solution, which could be almost anything. Even just something as hacky as everyone running an ftp server might fit such an extremely vague criterion.

But to run with your new scenario, professional programmers could come up with just a working solution quickly. However, lots of CS students could do the same. Pretending like no CS students can program reasonably well is disingenuous.

> most CS students would take months to even be able to finish a basic program

I don't have statistics on that, but I suspect most seniors and juniors could get something working in far less than a month. You're just trying to paint them in a worse light here. It's not like CS students don't have larger projects they complete in relatively short time frames.

> And it would fall over as soon as you sneezed at it.

I bet the that would be even more so for programmers with no CS experience. The reason I mention P2P programs is that they require CS fundamentals to function reasonably well. And CS students would be far better equipped to look up and understand and implement those things. Your average programmer who thinks CS is unnecessary is likely to write something that indeed 'falls over as soon as you sneeze at it' here because under a real load, it will not perform well.

> While there will be exceptions on either side, run that race a thousand times, and the programmers would win the majority of times.

For writing yet another Rails website or somesuch, maybe. For an example like mine, that requires in-depth CS knowledge, not a chance! I think the reason you are so confused is that you assume CS students can't be 'programmers' and/or you're mentally pitting experienced devs against new CS students. I doubt a new programmer that didn't have CS knowledge would do well at any of this!

> I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains.

> I suspect I could add the word small to advantage and subset and that statement would still be true.

I doubt that's even close to true. You need CS knowledge to optimize programs and to design reliable services. It would only be true if you squint really hard and cherry pick some domains where CS knowledge isn't valuable and cherry pick what counts as 'academic CS knowledge'.

I would have edited my previous reply, but it was too late.

>I suspect I could add the word small to advantage and subset and that statement would still be true.

Sounds like you're only familiar with programming to solve easy problems. Lots (most) of us do it, and that's fine, but there are a large number who tackle the more complex domains and need both skills.

It's because I do realise there are a small number of domains that do benefit from formal CS knowledge that I couched it that way.

You are, after all, agreeing with me. Most.

I'm disagreeing that I don't believe it is a 'small' number of domains, only that they are domains you're not familiar with (or aware of.) Other than that though, yes, we agree.

They probably assume if you know programming, Ruby, and everything else you should be fine with Rails. Quizzing people about minutia that can be easily Googled doesn't really sound like a great way to find apt candidates.

Been programming for a living for 30 something years, my last contract ended recently so started investigating the technical interview process so sympathetic with your point of view. I've never had to do any of the basic algorithms/puzzles from scratch that one typically has to do in these interviews for a shipping product, based on the samples I've seen from hackerrank and leetcode. The questions marked easy on leetcode were ones I was asked in the 90's.

I don't understand people who don't do prep for interviews ... https://news.ycombinator.com/item?id=13888581

and I don't understand people who want to waste a month (or more!) of their life every time they change jobs... https://news.ycombinator.com/item?id=13888703

Well different people need different amount of time to prepare for interviews, but if preparing for one month gets you a much better job offer, that sounds like a good investment to me.

You've completely missed the point. If you need to do this every time you change jobs, then throughout your career you're spending years! of your life on interview prep. Getting into Google for the first time, sure, it's worth it then. But what about the next job? Or the job after that?

Geez, how many jobs are you planning to have?

Changing jobs often is not rare in CS and related fields.

Changing jobs gets you a higher pay increase than interviewing well once.

I dunno, I just ask for raises based on what I did in the past year. I've heard many employers say no, but if they don't want to lose you and you have a good case (management loves numbers, show them numbers) you should get it...

I've always just kind of assumed that everyone does a fair amount of interview prep. Maybe not a month, but at least a week or so to refresh your interviewing skills and practice. The skills needed to pass an interview have almost nothing to do with the skills you're employing day-to-day in your job, so you should expect them to get weaker the longer it's been since you've applied for a job.

I mean, what do you guys do, just walk in and wing it?

I used to prepare for about a week every time I switched jobs early in my career. That's back when every company just asked typical DS&A whiteboard questions. Now, every company has its own method. I don't bother to prepare because I never know what I'm walking into. I just wing it.

This comment[0] says it better than I can:

unless you're interviewing at one of the big companies with a known interview process, you'd basically be wasting your time.

I've done hundreds of tech interviews over my career, and especially in recent years (now that companies are trying new things), it's completely random.

Some will do "Cracking the coding interview" type shit, some will do code reviews, some will give you a take home thing you have to present, some will do pair coding. Some do algorithms only, some do design discussions only, and so on and so forth.

So any prep I do will be a shot in the dark and 99% of the time I'll have to do something I did not prep for. So I don't bother trying.

Notable exception is my current job, which is a big tech co with a semi well known interview process (not as infamous as google or facebook, but still), and they gave me a fair amount of info up front. I also -really really really- wanted to work there because the team I wanted to work for did things no one else does. So i bit the bullet and studied/practice.

That was literally the first time (and probably last) time I did.

[0]: https://news.ycombinator.com/item?id=13888703

Yes. Just walk in and wing it.

Ok, so I generally do research about the business to make sure I understand the problems they are solving and have good questions to ask, but never CS interview prep. And I'm not some coding genius...I couldn't rattle off big-o for any algorithm off the top of my head, for instance...maybe a little above average.

Then again, I've only worked for 5 employers in a 19 year career. I think that was something like 18 interviews total in my career. A grand total of 1 or 2 required any deep CS knowledge and those were questions like "write fibonnaccci on the whiteboard*" or write a linked list in a code editor. I don't consider those to be worth studying...you should be able to do those off the cuff. And also, I'm pretty sure I can come up with a reasonable solution to most problems presented under pressure...something I know throws some people off.

Anyway, those 18 interviews yielded something like 9 or 10 job offers. And the fibonacci one...no offer...stared at it for 5 minutes after getting stuck on one of the conditionals before finding my mistake and didn't get the job. But whatever. There are always more interviews.

Now, I've also never approached a job like "I really want to work at Google/Apple/Facebook/etc so I have to ace this interview". I've always taken a broader, more laissez faire approach to try to find the right fit for me. So it might just be a matter of your approach to a job hunt.

I never prepare and I received offers in maybe 13 out of 16 interviews.

When I hear people are getting offers in that high a proportion of interviews, I wonder if it's time for them to set their sights higher.

I'm amazed that it takes a month to refresh basic concepts like BFS and DFS.

Reply on news.ycombinator.com