Live data from Hacker News

I Am a Bad Developer

eewz0z.pen.io

121–130 of 223 posts

Re: I Am a Bad Developer

#121

I also feel like I'm not very good at in-person interviews because I'm not very good on-the-spot. I mitigated this by using a variation of "The Briefcase Technique" which I learned from Ramit Sethi. The company I interviewed with is in the SAAS email space, so to get their attention I created a mini web app combining SMTP and web technologies. This took me about 3-4 hours tops. I was trying to demonstrate a few thing…

I got my last two jobs this way minus the white paper. For the last one I learned Rails and made an app using the technologies listed in the job description, threw it up on Github, spent a lot of time on the cover letter, and voila.

They also asked me lots of computer science oriented questions in the interview, and for most of them I just said, straight up, "I don't have a formal CS education, so I don't know, but here's how I think that works."

So many people try to stand out by doing some variation on the standard resume + cover letter routine, so it's relatively easy to stand out if you do literally anything else.

Re: I Am a Bad Developer

#122
IMHO, little that you mention, the books, the open source projects, the magnitudes of complexity, the math, code-kata, the introspection, whatever, has much to do with what people need to develop software. What you need to be able to do is take crazy shit thought up by management, clients, contractors, government, and turn it into good enough software. The job is to appease those who are paying and attempt to squeeze as much good code into it as they can tolerate.

Get passable at that and someone will give you a job.

Re: I Am a Bad Developer

#123

I could have written this piece. It hit that close to home. I'm 15 years into my IT career and I can honestly say it's not getting easier. I don't believe it's an ageism thing, but just a symtom of something I still cannot put my finger on. I put myself on sabbatical after realizing that my needs were not being met on a regular basis by my job. While I'll allow short-term ROI to be negative, I will never allow my lon…

> - when I type in a URL in my browser's address bar, press Enter, and then the page appears, tell me what happened technically in as low level as possible.

Hey, that's one of my favorite questions as well! Great way to gauge depth of knowledge, and you can take it so many places afterwards (HTTPS / SSL, REST, etc).

The best answer I heard started with "well, the enter key press triggers an interrupt...., followed by discussion of browser / OS differences with respect to caching DNS info."

Re: I Am a Bad Developer

#124
A lot of this angst can be resolved by just buckling down and working through a good algorithms/datastructures book, chapter exercises and all. Yes algorithm puzzles are over used in interviews, but if the game is played that way, learn to play it.

My 2 cents.

Re: I Am a Bad Developer

#125

Earlier quoted context omitted.

> Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken? Certainly the hiring practices of Google et al, generally the worst perpetrators of cs bingo in my experience. Started a startup, you say? Rebuilt a non-trivial webapp? Won a hackathon? That's great, but we're going to need you to implement red-black trees and variations of fizzbuzz until yo…

Did interviews for 5+ years at Google... the real problem is that there's no uniformity to the hiring process. I was allowed to just make up my own questions and judge candidates based on those. And I did so. And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired. But I didn't give a crap, because hiring is something you're kind of coerced…

Wow, glad I've never been interviewed by you.

Re: I Am a Bad Developer

#126

OP here. To clarify: I do understand algorithmic complexity. You don't often study information theory and ordering while skipping Big-O and friends if you're into CS. I was rather mad at myself for missing it in an interview. I should know it but I struggle with it under pressure. If it's not one thing it's another though... and the repeated failures to find market acceptance for all the effort I expend to be a good…

I think I went through 50-75+ different applications, 25+ phone/skype screens, and 5 on-sites for my most recent job hunt. I stopped keeping track after a while.

I targeted companies that I thought I'd fit with a person and agreed with the products they made. It's very disenheartening to find out that you didn't make the cut time and again.

I guess I'd advise you to ensure (1) you're going to open houses and tech meetups in your area and (2) be sending out several targeted applications per day for companies that you genuinely want to work for.

Note, I would advise you or any other techie to move to a tech city for work. I've lived in the boonies for a few years now, there's almost no work here, no point in living here unless you have a cushy remote job.

Re: I Am a Bad Developer

#127
I'm looking for work and this is kind of driving me up the wall too. Not so much the algorithm stuff (generally I can crush that, even if I see the point the author is making). It's the take-home stuff.

After you pass that their algorithm trivia test (subset sums? REALLY?), then they ask you to do a take-home test. The latest one is literally "here's some data, code up an interface. Be creative." No direction, no use cases. They barely explain what the product even is.

This isn't going to be easy. I've already spent four hours on it - getting a sense of their product and what their customers even want - and a few more hours thinking about it and then one hour just massaging the data. I can see six more hours ahead of me. I'm doing it mostly because it's a way to motivate myself to learn more about mobile interfaces, but it's really irritating. Perhaps I could use more boilerplate code (and I'm trying to use as much off the shelf stuff as possible), but what do they learn then?

One of my old employers was guilty of something even worse - their take home exam was "code up a bug tracker". I felt so embarrassed about that. Either they whipped up a basic thing in something that creates most of the forms for you (which tells us relatively little), or they spun their wheels for two or three days (trying to do it from scratch, likely not producing anything that good).

Re: I Am a Bad Developer

#128
post #118

Earlier quoted context omitted.

You're right that it matters very little if you can deduce the exact complexity right off the bat. But it DOES matter is if you can tell if an algorithm is closer to n^2 than log n. OR identify that n is low enough that it doesn't matter. > Besides a O(N log N) algorithm over 10 or 100 items is not going to cause any issues. In the case of your standard CRUD application that's what you are going to be dealing with. I…

Going to have to ask for an example. I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor queries but never from an bad algorithm. Keep in mind I would say that a simple CRUD app with millions of entries is no longer a simple CRUD app.

What does "poor queries" mean other than queries with poor asymptotic complexity based on the query plan?

Re: I Am a Bad Developer

#129
I perform much better at interviews when I am relaxed. If you put too much pressure on yourself, then you will not be relaxed and will perform badly.

If you do a perfect simulation of an interview at home do you perform well? Find an interview question you haven't seen before, and attempt it exactly like you would at an interview. Have a software developer friend mock interview you.

If you feel like you perform better in a simulation, you may consider seeing a psychologist or reading some books on the subject. I once went to a workshop on how to deal with high pressure situations, and many of the exercises suggested made a difference to my interviewing.

The tips in the following article I feel apply equally to interviewing. I suffer the mentioned symptoms during interviews. When adrenaline levels are high the brain will enable a short-cut mechanism that allows you to make quicker decisions, but often not correct when considering a difficult question. The dreaded "tunnel vision" is a fight/flight response.

http://blog.bufferapp.com/what-happens-to-our-brains-when-we...

Re: I Am a Bad Developer

#130
post #89
post #49

Earlier quoted context omitted.

Although understanding the difference is important, the specifics are typically far more relevant in a high performance language than a dynamic scripting language with lots of "magic". OP is interviewing for a C++ gig, so performance was clearly a motivating factor. Not nearly as relevant for someone using scripting languages and building UIs.

Once I made a Ruby program noticably slow by using "array += items" instead of "array.push *items" in a loop, making it O(n^2) instead of O(n). Once we noted that doubling the input size quadrupled the runtime, I found the bug. (I was a Ruby newbie and didn't know that Ruby's "array += items" is just syntactic sugar for "array = array + items".) I've used slow web pages that show a lot of items or data. One way to ma…

Oh shoot. I used array = [array, other_array].flatten to get around the += slowness. Way faster on lists of tens of thsouands that I was throwing around. Totally forgot push. (Granted, my solution was developed on Sunday morning with a hard deadline of Monday morning and I had been working hard all week. )
Post reply on HN