Always Be Coding – How to Land an Engineering Job • Hacker News Board

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

#211

Post by brightsize » Thu, May 23, 2013, 4:26 AM UTC

norrec wrote: post #42

I've been a junior developer for almost 2 years now at a fairly large company. At my current position, there hasn't been a single task thrown at me that I have not been able to complete with ease. I've worked with multiple languages and technologies that I was not familiar with at all when I started. I tend to figure them out pretty quickly and get on with the task at hand. I've built a bunch of side projects (not al…

I sympathize 100%, I feel much the same as you do. I have decades of experience, doing real work, creating systems, making products. Back In The Day, these kinds of quiz-cage interviews simply did not exist, and, having sat on both sides of the interview table a great many times, I can confidently say that they don't need to exist. I would no more ask a candidate to implement a quicksort than I would ask a candidate for a trumpet chair in my orchestra to recite to me the frequency of every note in the F major scale or demonstrate how to weld a new bell onto this extremely broken horn that I just happen to have with me. The whiteboard stuff you describe is -nothing- more than hazing, as you, I think, have instinctively surmised.

At this point I don't bother to apply to corporate jobs, or even to jobs at startups that are larger than a few people, because I know I'll get the same kind of idiotic hazing each and every time. I'll found my own company (there have never been more opportunities than now) or do freelancing for companies that will treat me with respect. In your case, since you sound like you're sharp, I think that freelancing might be a good choice in the short term. You can bring in some bacon while you work on product ideas, do some networking, and find partners.

You sound like a good developer and the problems that you have with these interviews (which I share) are no reflection on that fact. This may sound a bit odd -- but do keep an open mind about leaving the field. There's a lot of interesting work out there in the world, some of it creative even. Software geeks tend to live in this very narrow, ant-farm-like world, have a hard time seeing outside of its walls, and assume that beyond the glass is a land that can only offer just drudgery and pain, which is simply not true. Best of luck.

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

#212

Post by prodigal_erik » Thu, May 23, 2013, 4:29 AM UTC

kanzure wrote: post #195

WalterBright wrote: post #187

Earlier quoted context omitted.

I don't make major financial decisions in an hour, either, and hiring an engineer is a 6 figure commitment.

You don't have to decide during that interview. You can take your time. Look at the candidates' source code on github, bitbucket, look at their mobile apps, disassemble them, take a look at how well they write software, etc.

How could you verify the code is actually theirs in just one hour, and not something they've been coached on? The stakes are so high that we already have an awful lot of blatantly unqualified people trying to bluff their way through in-depth interviews, and making that easier is a huge step backwards.

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

#213

Post by Homunculiheaded » Thu, May 23, 2013, 4:30 AM UTC

rikf wrote: post #120

The only recruitment process I know of that works is. Step 1) Send the candidate a small unattended coding test they can do in a couple of hours. If they pass great if they dont offer them feedback. Step 2) Invite them in for a pair programming test this should take max one hour, they can spend 15-30 minutes with one or two people on the team solving a problem. You wouldn't believe the amount of people who have amazi…

"If they pass great if they dont offer them feedback."

I've only personally encountered it once, but if you ask someone to spend a few hours of their free time on your coding challenge you absolutely owe it them to give them feedback, even if you don't like what they've produced.

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

#214

Post by sjg007 » Thu, May 23, 2013, 4:45 AM UTC

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…

Startups exist because hiring is broken.

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

#215

Post by lsiebert » Thu, May 23, 2013, 5:32 AM UTC

heh... a variation of always be coding is what I went with for my blog name a while ago.

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

#216

Post by lsiebert » Thu, May 23, 2013, 5:36 AM UTC

peterbotond wrote: post #198

marblar wrote: post #105

Earlier quoted context omitted.

Has anybody here ever actually been asked to exactly implement quicksort?

quicksort, shellsort, then implement it for parametric type.

I am not even sure what implementing it for a parametric type means... can someone point me to a link?

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

#217

Post by freework » Thu, May 23, 2013, 6:16 AM UTC

mason55 wrote: post #129

ap22213 wrote: post #100

Earlier quoted context omitted.

In a certain state of the economy, you're right. But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. For example, the company for which I work bills me out at $250 / hr. I get something like 15-30 job requests from other companies a week. It would not make any economic sense for me to pursue any of these other com…

> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work. The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all. It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a perc…

> A single bad engineer could theoretically destroy a company if they were savvy enough.

This sentence does not compute.

Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This results in crazy interview multi-hour processes.

In the real world, the worst employees rarely ever negate the work of more experienced workers. Thats like saying if you hire a bad teacher, students will forget information rather than learn.

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

#218

Post by freework » Thu, May 23, 2013, 6:23 AM UTC

prodigal_erik wrote: post #212

kanzure wrote: post #195

Earlier quoted context omitted.

You don't have to decide during that interview. You can take your time. Look at the candidates' source code on github, bitbucket, look at their mobile apps, disassemble them, take a look at how well they write software, etc.

How could you verify the code is actually theirs in just one hour, and not something they've been coached on? The stakes are so high that we already have an awful lot of blatantly unqualified people trying to bluff their way through in-depth interviews, and making that easier is a huge step backwards.

Its usually pretty damn obvious Ask them to explain what the code does and why they wrote it. If they backpedal and aren't able to say anything then you can assume they didn't write it.

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

#219

Post by fazzone » Thu, May 23, 2013, 6:23 AM UTC

lsiebert wrote: post #216

peterbotond wrote: post #198

Earlier quoted context omitted.

quicksort, shellsort, then implement it for parametric type.

I am not even sure what implementing it for a parametric type means... can someone point me to a link?

Parametric type means to take the type as a parameter; parent was probably asked to use Generics in C# or Java or C++ templates.

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

#220

Post by freework » Thu, May 23, 2013, 6:29 AM UTC

hackinthebochs wrote: post #149

reledi wrote: post #104

Earlier quoted context omitted.

> 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 thinking about how I'd much rather be building or tinkering with something. So that's what I end up doing. Nailed it. Another interesting thing I noticed about myself in technical interviews is that I have a lot of trouble doing things that I would have no trouble with if I'm…

>I'd rather spend my time tinkering with stuff than preparing for interviews If we're talking about raw programming skill, I would say that actually learning these fancy algorithms will pay off more than (random) tinkering. It's the difference between directed and undirected practice. Undirected practice only takes you so far. To truly get good at something one must do deliberate, directed practice consistently.

In rea world programming, those algorithms have very little practical use other than the "gee-whiz" factor.

If you understand algorithms in general, then I think thats enough. Its sort of like being able to play a single song on the guitar is great, but to have the skill to play any song is even better. On the same token, being able to write any algorithm is a much better skill than being able to write out a single algorithm.