Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm always curious about the senior engineers who "can't code their way out of a cardboard box". I often wonder if I'm one of those, or come across as one of those.

Can you give an example of something you've seen. I just keep hearing about people who can't do fizzbuzz, but how bad are people really? Or what is it that makes these engineers so bad? How have they lasted in the industry?



they're really bad. i interviewed people that couldn't fill in a simple fizzbuzz after defining a function body and return type for them. they last because they can last, a lot of these jobs really just require codemonkeys. I have seen if states literally hundreds of words long made by these kinds of people.

that said i feel you. tbh, i have managed to impress anyone i worked with. most were people i met at hackathons, people that wanted to bootstrap their startups or general referals. on the other hand I failed most interviews i took(with a few noteworthy exceptions)

It once took me until after the interview to figure out that the guy just wanted to find out whether i understand how variable scopes work.

A lot of interview questions are questionable at best, and most code challenges are even worse. they're exactly how universities teach programming. The only problem is that universities suck at teaching programming. I know a lot of really awesome people that went to university because they thought knowing the topic they study was a good idea, but it turned out to be the opposite.

But one lady once asked me is there a special command to find out where traffic goes? I said route. Is there any special flag you would use she continued. But what she wanted was to hear route -n.

I'm pretty sure in those kinds of interviews they think i'm an idiot


I have two examples to share. A simple whiteboard question I ask is "Write a function to compute interest on your money. You have $X and I'm going to give you y% interesting for Z years."

I'm generally happy if they don't ask any questions and write a simple interest calculator. Most people ask some questions about when interest is calculated during the year. Then, if the questions haven't gotten us there yet, I ask them to modify it to a compound interest calculator where you can also contribute some money every year.

I've never had anyone who didn't understand the concept or what I was after. Or at least I didn't have anyone who admitted to still not understanding how it worked.

Two people stand out.

One of them immediately tried to write a recursive function and got lost. Then started over and tried to calculate a one-liner to do compound interest without looping. Couldn't get it, started over with a for-loop and failed to return in the proper place: the code was returning a value and then immediate next line was more calculation.

The second let me explain the problem and then said "I'm sure there's some library call for calculating compound interest, I'm just not sure what it is." Full stop. I explained that I wasn't asking for the library call, I was asking them to work up the algorithm and write code that did it.

They repeated the statement that there was a library call for it but they didn't know it and that if the interview was going to be about the specifics of library functions then it wasn't going to be a good interview.

In both cases these people passed a phone screen focusing mainly on experience, algorithms, design, etc... Since then I've adapted the phone screen to cover more of Steve Yegge's points [1] and I actually include a small coding question on the phone.

I don't think my system is perfect, but in the last round of hiring the people who made it through the screen were almost all good technically and weren't offered positions because of fit with the team. I'm sure there were a few people who might have been good that got filtered out by writing code over the phone but at the time I was willing to risk that vs the time commitment for the rest of my team to do on-site interviews for someone that could be DOA.

[1] https://sites.google.com/site/steveyegge2/five-essential-pho...


"Engineers" who use so many nested if's that I have to horizontally scroll my 2560px width monitor.

They've lasted because they've usually only had one or two employers, as a permanent employee (rather than a contract) and no-one code reviews until it's too late.




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

Search: