Hacker Newsnew | past | comments | ask | show | jobs | submit | hcatlin's commentslogin

Can we get the metric system now?


Yes! Yes! Yes!

Except, remember, top company also means experience. If you are at a top company, your second-year CS stuff might be a little rusty.


I'm sure this happens, yes. But, that's not what's going on here, IMHO.

Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job'

Most of these interviews are more like math problems than anything a practical developer would encounter.

Shit, if these interviews were "What do you think of node?" or "What is Go's concurrency model?" I think experienced people would do fine.


> Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job'

No. No one in their daily jobs implements a linked list or B-Tree. There are predefined libraries in the languages or a user created library that people use. Do you really think every person in the company has his/her own version of a linked list in the same code base? This is a fallacy perpetuated time and again. (I'm not against these type of questions, but they don't represent someone's true ability)

Building a product, app, project requires application of this knowledge: eg., I need to design a distributed data store, should I use hash map? What about collisions? Should the collisions be resolved by chaining (linked List) or another map? What kind of data am I storing? Can that be exploited to make this more efficient, synchronization of data across nodes (?), etc..

Many of these interviews completely overlook someone's design ability and harp on some straightforward (and some obscure) topics which IMO has little to no co-relation to someone's ability as a software engineer.


this, so this.

Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done.

I find the processes in a large company rather robotic (note: we're a startup, so my views might be biased).


>Why is everyone stuck on getting someone to reinvent the wheel as against getting him to use the said wheel and get things done.

A person who can only use a pre-made wheel is a technician (regardless of how ostentatious their job title may be).

A person who can invent the wheel on demand can also usually invent any other type of rolling mechanism one might encounter a need for and that makes that person a full-fledged engineer.

No value judgement of either person is implied; it's simply a statement of capability. Which type of person is needed depends on the company and the position but it is becoming increasingly clear that the two roles in software are separate, just as they are in other engineering disciplines.


> No one in their daily jobs implements a linked list or B-Tree.

Counter case: HFT. Those guys really do implement this stuff. Again and again.


Which is why it's an outlier.


Asking a person to traverse and modify a linked-list (a very common problem) or to implement a B-tree are not 'tech outside their job'

Yes, it is.

More to the point, it's built-in bias toward recent college graduates. Once someone's actually been out in the real world programming for several years, any space in their brain's metaphorical working set that was ever dedicated to remembering how to do this stuff has long since been paged out in favor of the actual day-to-day knowledge they need to do their job. Implementing basic data structures and algorithms is not part of what they need to do their job; that stuff's already provided by the platforms they use.

So when you get to the interview, if you just put someone on the spot and ask them to do one of these things, you're inherently biasing toward an inexperienced recent college graduate who will have this stuff close to the top of their head (on account of having just done it in school and not yet swapped it out of working memory through time on the job).

Which is in turn why there are now books you study -- as an already-qualified programmer -- in order to freshen your memory and ability to quickly regurgitate problems that have nothing whatsoever to do with your day-to-day work, in order to be able to perform them on command in interviews.


Right, as a metaphor, I'd almost compare it to grading a novelist or writer's grammatical knowledge of parts of speech and sentence structure rather than their ability to write a book or compelling article.


I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems. If you have trouble with those, I'm going to really wonder if your programming skills are really very good to begin with.


Those are bad examples, but real interview questions tend to be "implement from scratch, live and without reference to any materials, these things you've forgotten about because you could take them for granted for such a long time".

Also these days the trendy interview problem is longest common subsequence, which ends up testing "how recently did you review dynamic-programming techniques", not "can you code".


> I'll be honest, traversing a linked-list and implemented a B-tree (assuming someone reminds you what a B-tree is) are not particularly difficult problems

I'll be honest, this is indistinguishable from "I am good at X and I'm great therefore X is a good measure of ability".

Maybe worth rephrasing


They're not particularly difficult. You usually take the algorithm definition and implement one, as you did in the university or in the Coursera algorithms course. Fun, you might learn a thing or two about the language you're using.

If the point of the exercise is a TRIVIA question, leave the interview. On the other hand, if the point of the exercise is not to get the right solution but see how you think and how you use basic programming blocks, then you're in the right place.

I've used the linked list question. And the goal is not for me to check if it is "not difficult" for you. Because I might not be able to teach you what a linked list is in 5 minutes while you're nervous in a technical interview. But to work on technical problems and see the following:

- Can you speak your mind so your peers know what are you doing?

- Will you ask for help?

- Will you accept help and feedback?

- Can we have a discussion about something that there are many "right answers"?

- Do you know the basic building blocks of the language you decided to use? <-- This plus javascript plus references is very funny.


You refer to the interviewers as 'peers' but that's very much not the relationship that exists in an interviewer. The context is different, therefore the behaviour is different.

What you're describing is a confidence bias filter, dressed as an objective test.


Individually, with minor refreshing-study, perhaps no.

But in practice it's merely one of hundreds of things that might get instantly sprung on you as you stand before a whiteboard. In addition, developers with actual jobs can't stay in a continuous cycle of "exam cram" to the same extent that unemployed recent graduates can.


Traversing is a linked list is far simpler than implementing a B-tree.


The problem is its possible to run a B-tree implementation and see if the unit tests pass or non-technical interviewers can compare the official solution to what the candidate is talking about fairly easily.

I've never used Go, don't really plan to unless I have to, nothing wrong with it just not my area of expertise and I'm busy with other toys although I'm sure its a very nice language, and if I went up against a non-technical or technically weak interviewer (aka almost all of them) I could probably BS my way thru based on what I do know about concurrency in general. Although after decades of experience, the reason why I'm not still programming in 6502/Z80 assembler is I'm good at that whole "BS my way thru till I'm an actual expert" thing, so maybe I'm talking myself into agreeing for non obvious reason!

BSing skill is under-rated. If you can't BS your way thru something that you don't entirely understand (because you're lazy), then when you're at the cutting edge developing or debugging you'll have trouble BSing about stuff that no one on the planet understands. Not all the worlds problems have a stack overflow question or a script reader at a support hotline, and how you deal with that gut check says a lot.


Actually BSing in tech makes you look very poor if you don't come out with a convincing answer.

(I listened to a training video given by a Marketing Cloud consultancy at my work. Someone asked "what is FTP" after seeing that as an option to upload files. Lots waffle including "the cloud" and no actual answer. The person asking the question was no wiser, and my opinion of the consultant went way down).


I think my words may have been clumsy. My reference to "tech outside their job" was meant more about having relevant skills to a current job market (marketability), not the interview itself.


Cool!


I'm not really sure what the use cases are for collaboration on this kind of thing or what that means. Are there real-world use cases I'm not thinking of? "Collaboration" is a great buzzword, but what does it have to do with a data store?


(full disclosure - pachyderm employee)

Good question. It's funny how much collaboration is overlooked. And you're right - it's not obvious how a data store can enable collaboration.

In the software engineering world, collaboration by means of git is so prevalent its like breathing air. There's no such thing today for data scientists! That's crazy! Because doing data science involves more variables than writing software alone.

Pachyderm stores your data in a git-like manner. We store the deltas and version the data so that its consistently reproducible. We also give you some nice tools to run any code alongside your data.

This enables some very basic workflows:

1 - You're trying to develop your analysis - so work on your code & lock your data

2 - You're trying to vet new data - develop and version your feature extraction and data together

3 - You're trying to work on some analysis w colleagues - fork the data + analysis to do your work ... then merge to make sure your work is compatible before deploying

There are many more ... but hopefully that makes it a bit more concrete


And I should add we talk about Collaboration and other design goals more here: https://pachyderm.io/dsbor.html


Hi, I'm one of the founders of Pachyderm but I'm actually drawing more on my experience as an Airbnb employee in this comment. We used Hadoop at Airbnb and had a lot of problems with collaboration on data science.

The biggest difference between data science tutorials and data science at a company is that you have to work with people, lots of people all of whom have different backgrounds, skill sets etc. In a setting like this it gets very easy for people to step on each other's toes. For example Alice is doing some analysis on a data set and she realizes that there's a format for this data that would greatly simplify her work. So she reformats the data, but unbeknownst to her this same data was being fed into our fraud model every night... which is now broken. So reformatting data that you don't own is a bad idea, Alice learns her lesson and the next time she's in this situation instead she makes a copy of the data first so that she won't mess things up for others. This is a pretty standard thing to with a Hadoop based data lake but it leads to much more subtle problems down the road.

By making a copy Alice is setting up her own little data silo, a month later when she goes to report her findings she'll discover that in suddenly contradicts with other data scientists work. Why? Because each data scientist has his/her own completely separate copy of the data. We had cases of side by side reports which greatly disagreed about how many users we had. People stop trusting data really quickly in an organization when there are glaring flaws like that.

In Pachyderm this workflow makes a lot more sense, if Alice wants to modify data then Pachyderm will give her a clean room to work in that won't affect any of her coworkers analysis. As data outside the clean room changes it can be automatically pulled in and processed using the same code she wrote before and when she's ready to present it to others she can share it publicly.


When I was first releasing Haml, I remember that Ezra piped up and encouraged me. Actually, thanks to the Internets, it's still there https://groups.google.com/d/msg/rubyonrails-talk/UqYlo_N59zo...

Seeing someone as brilliant as Ezra saying he liked my project (Haml was the first thing I ever released) really encouraged me to continue on in OSS development. And, of course, we added iterators to Haml shortly after Ezra suggested it.

Also, Ezra was super helpful when we built m.wikipedia.org using Merb... helping me get everything set up so that we could scale that project to 2 billion pages a month through the three dinky machines I had!

I'm totally surprised and gutted to hear that he's passed. :(


If it's "for teams", then users seems like a better option. You wouldn't want to punish usage. Remember, you are creating value and you want to make sure that the user gets as much value as possible... and that's by sharing more often, typically. And, as the user base within a company grows (hopefully), the price should go up. This stuff is always hard to figure out and I don't think most companies are always 100% happy with how they are charging, but if you are a team-based app where you can easily measure by employees using it, then user is probably the clear winner, even with the little information you've given.


Some more information: we are called http://www.teamgum.com.

our competition: mostly they have all user based pricing

my view: i think value of the product will be more visible if no. of users in the network are increased & no. of links shared are also increased.

my concern: if we price per user & end up restricting free flow of users then do you think we may end up turning off many of the acquired teams?


If they are promoted to CEO, then... yes. Hence why we were building apps for it knowing full-well that he was a homophobic CTO. CEO is a whole other level, and was our personal line.


This reads like "I don't like big cities" which is totally fair, but not a general comparison. To each their own. Dirty, loud, expensive: It's a big city! I personally love big cities. I grew up in the suburbs, but have chosen to spend my adult life in Toronto, NYC, London, and SF. I love the kinetic motion, the bars, the rowdiness, the closeness of social classes, the camaraderie of being 'miserable'. I love it!

But, I also see how someone who only moved here for a tech job and to be financially comfortable, who previously lived in a very middle-class suburban area, wouldn't be totally thrilled. Fair enough! Lots of good jobs in lots of decent places.

I do want to throw in one small defense item in the middle of SF hating. I didn't move here because of the tech stuff (which I am a part of) or because of the weather. I moved here for the crazy, wild, weird city that SF is without technology. For the hippies, the dropouts, the drag queens, the commies, the environmentalists, the capitalists, the techies, the artists, ... the great mashup of people that make up SF as a big and wild city.

Before anyone moves to SF, they should read "Tales of the City" by Armistead Maupin. If reading that doesn't make you want to immediately move to SF, then you'd probably do better in some other city with a decent tech scene. Or, as another reader pointed out, you'd probably be happier in the Valley if you are looking for a more NC-feel.

PS: the homeless problems being right next to the rich reminds me of the Settlement Movement of the early 20th century. check it out: https://en.wikipedia.org/wiki/Settlement_movement


Yeah, its run against the WHOLE sass spec!

Also, thanks for the supportive post!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: