Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always Be Coding – How to Land an Engineering Job

medium.com

Post reply on HN
Print view View original

51–60 of 250 posts

Re: Always Be Coding – How to Land an Engineering Job

#51

Post by NamTaf »

marceldegraaf wrote: post #45
nbroyal wrote: post #16

To properly prepare for these interviews you have to invest quite a bit of time. At this point in my life (late 20s), my time is one of my most valuable resources. So, the last thing I want to do is spend that time effectively preparing for a data structures and algorithms exam. Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start…

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

How do you cope with people who are presently employed but want to interview? Do you expect them to find two days of absence from their present employer to test themselves at your company?

I mean for me that's no problem, but I don't live in the US and therefore have pretty liberal employee leave arrangements. I know that many companies in the US are a lot harder on giving out leave. That said, it wouldn't surprise me if this issue is minimised in the tech sector with their progressive business approaches.

Re: Always Be Coding – How to Land an Engineering Job

#52

Post by hippee-lee »

marceldegraaf wrote: post #45
nbroyal wrote: post #16

To properly prepare for these interviews you have to invest quite a bit of time. At this point in my life (late 20s), my time is one of my most valuable resources. So, the last thing I want to do is spend that time effectively preparing for a data structures and algorithms exam. Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start…

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

I forget the exact details but my current employment agreement has a paragraph saying I won't do contract or consulting work while I am a full time employee here.

Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethically challenged.

Re: Always Be Coding – How to Land an Engineering Job

#53

Post by AdamTReineke »

callmeed wrote: post #9

Really good post, thanks David. I'm really curious as to how you landed an interview at Google (let alone a job) without a college degree. My understanding is they are very strict about that and it's hard to even get a foot in the door without a degree. [disclosure: I'm on a 10 year "hiatus" from my senior year in college]

Have you written a blog post about leaving and your time since then? I'd love to read.

Re: Always Be Coding – How to Land an Engineering Job

#54

Post by drawkbox »

mweibel wrote: post #41

Re-invent the wheel. You should implement the most common data structures in your language of choice. [...] While I agree that it helps a lot understanding those data structures by implementing them, it might be good to add "Don't use them in production!" paragraph.

Agreed. Working in games you really do get to work with smart people, yet with the power of C++ everyone wants to recreate their own String class, data structures etc. Game industry largely hates STL. There is also a distain for boost, another large collective of reviewed and hardened standard libraries (POCO is another nice one). The ego is immense at places like this. Programmers feel like they have to do this to compete or deliver over shipping and delivering products that work. Granted there are reasons for doing this such as keeping memory allocations through a common engine library to reduce memory and fragmentation but in most cases it is a moot point.

Performance does mean the most many times in this field for the AAA games out there, but not for most games. In web or app development if you are using custom data structures instead of native, in most cases that is wrong. How about consistent data structures that have been built and tested outside the company? The thing is though when the programmer that makes your 5th string class and data structures moves on it will be rehashed by the next, as other developers won't be as effective with them and recreate.

It is much more important to understand what data structures to use when and what impact they have on performance. Most of all can the developer ship and understand what is best for the product (not the ego or what will make them look like the hardest programmer of all time -- i.e. Rewriting the string class again and it is 10% faster, even though that is not a problem at all). I have seen some horrible, leaky, buggy data structures in situations like this, because they thought that was the job as led on by the interviewing. I have only really seen this while working in the game industry which I love but it is a problem with shipping product when this bike shedding happens over improvements to the game, engine or real custom needs i.e. the UI libs, event/messaging systems, naming/conventions are typically horrible in situations like this.

I also blame consoles for many of these problems as the libs are so jacked, incomplete and old that performance becomes a huge issue and you have to have custom structures just to use the hardware right especially in graphics, physics + networking libs. Yet mobile I have seen less of this problem even though there is less hardware to work with. The next time you play a game and the networking totally sucks, or a game takes forever or simply doesn't ship, understand the culture of the company and the industry might have something to do with it.

Re: Always Be Coding – How to Land an Engineering Job

#55

Post by mc-lovin »

codex wrote: post #38

These kinds of interviews essentially ask: are you willing to put in the time to be one of the best in the world at what you do? Are you gritty, or wishy-washy? If the answer is no, don't bother to apply. That's not an unreasonable way to hire, in my opinion.

It's also a matter of attitude. If you're not willing to put up with having to study for what you perceive to be arbitrary interview questions, you probably won't do well with all the other annoying things that can't be changed that big companies tend to have.

Which is kind of what many people in this thread are saying when they say they don't want to work for a company stupid enough to use algorithms and data structures questions as their main interview method.

Re: Always Be Coding – How to Land an Engineering Job

#56

Post by nitrogen »

hippee-lee wrote: post #52
marceldegraaf wrote: post #45

Earlier quoted context omitted.

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allow…

I forget the exact details but my current employment agreement has a paragraph saying I won't do contract or consulting work while I am a full time employee here. Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethic…

Interesting. Many (if not most) of the engineers I met in my earliest jobs were moonlighting. How common is such an anti-moonlighting clause in employment contracts?

Re: Always Be Coding – How to Land an Engineering Job

#57

Post by michaelt »

codex wrote: post #38

These kinds of interviews essentially ask: are you willing to put in the time to be one of the best in the world at what you do? Are you gritty, or wishy-washy? If the answer is no, don't bother to apply. That's not an unreasonable way to hire, in my opinion.

Google's how-to-prepare-for-an-interview e-mails used to say "give yourself at least 2 weeks to review and hone your coding, algorithmic and problem solving skills."

That's fine if you only want the unemployed and new graduates - how well do you suppose it works out for people with full time jobs?

Re: Always Be Coding – How to Land an Engineering Job

#58

Post by nitrogen »

rdtsc wrote: post #46
kanzure wrote: post #43

Hiring is entirely broken. I don't think anyone is listening to developers. I took some data about this (tracking pixel in a Developer Auction profile), but someone did an even better job than me and posted in these comments: https://news.ycombinator.com/item?id=5730843 I want a company that treats me with dignity and respect, even before and during the interviewing pipeline. How a company treats people during interv…

> Hiring is entirely broken. Aaaand tokenadult is submitting his "best hiring strategies" mega-comment supported by Schmidt & Hunter reference in 3...2...1 /I've been here too long perhaps ;-)

Maybe we need to play the role of the monkeys in the apocryphal conformity experiment (http://skeptics.stackexchange.com/questions/6828/was-the-exp...) and post it for him:

https://news.ycombinator.com/item?id=4613543

Re: Always Be Coding – How to Land an Engineering Job

#59

Post by nitrogen »

archer174 wrote: post #48

Every time I read the word passion in one of these articles I cringe. This has to be the most overused word in silicon valley. It's really just a convenient way to abuse people. Can't work 90 hours? Not passionate enough. Have a family commitment? Where's your passion? Passion. We get it already.

It doesn't happen nearly as often, but I also cringe when I hear the word "stability" used as a euphemism to indicate a desire for someone with a mortgage and family. Discrimination comes in many forms.

Re: Always Be Coding – How to Land an Engineering Job

#60

Post by codex »

mc-lovin wrote: post #55
codex wrote: post #38

These kinds of interviews essentially ask: are you willing to put in the time to be one of the best in the world at what you do? Are you gritty, or wishy-washy? If the answer is no, don't bother to apply. That's not an unreasonable way to hire, in my opinion.

It's also a matter of attitude. If you're not willing to put up with having to study for what you perceive to be arbitrary interview questions, you probably won't do well with all the other annoying things that can't be changed that big companies tend to have. Which is kind of what many people in this thread are saying when they say they don't want to work for a company stupid enough to use algorithms and data struct…

It's the worst method out there--except for all the other ones. The problem with the "here's my portfolio of work" screening method is that companies generally expect a certain level of productivity (and IQ), and there's no way to tell how long you worked on your portfolio. Did you write that code in two hours or two years? Any code can be made to look good given an infinite amount of time to polish it and test it. Behavioral interviewing questions, on the other hand, just don't work for coders; too easy to bullshit.

The arguments against coding interviews seem weak, to me. They appear to be rationalizations for not getting the job--an insult to the ego that must be rectified by bending reality. They essentially boil down to, "I shouldn't have to sweat these details; they're beneath me." But all of the greats sweat the small stuff, almost obsessively, and pay their dues.

For the vast majority of mindless coding jobs out there, you don't need to hit the high notes. But when you're moving the state of the art forward--indeed, civilization forward, inventing what has not been invented before--you need complete mastery. If you just want to build stuff, on the other hand, these skills are unnecessary. But that's not engineering. That's construction work, for construction workers.

Post reply on HN