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

How to talk about yourself in a developer interview

stackoverflow.blog

Post reply on HN
Print view View original

131–140 of 194 posts

Re: How to talk about yourself in a developer interview

#131

Post by andy_ppp »

lettersdigits wrote: post #22

> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block…

Okay so I built shit version of Google Maps single handedly, from raw map data, before they had an API in 2005. It "worked" in IE5.5. Does that count?

Re: How to talk about yourself in a developer interview

#132

Post by LrnByTeach »

sheetjs wrote: post #70
luu wrote: post #34

Earlier quoted context omitted.

I have no idea how to answer this question. There have been some problems where someone was stuck for weeks, and I came in and coded up a solution in a day. That seems, in some sense, good evidence of being hard, but those problems never seem hard to me. The reverse happens to me too, where someone else solves a problem that was hard for me, and it's easy to them. Is that a hard problem? It was hard to me, but the pr…

It's all relative. Sometimes solutions require insights. Other times solutions involve a ton of grinding. Many people have a tendency to overemphasize the first and greatly underemphasize the second, even though the grinding may actually be harder than devising clever solutions. We build tools that read and write Excel files (open source library: https://github.com/sheetjs/js-xlsx ) There are plenty of very difficult…

I totally agree with these gems ...

> It's all relative. Sometimes solutions require insights. Other times solutions involve a ton of grinding.

> Many people have a tendency to overemphasize the first and greatly under emphasize the second, even though the grinding may actually be harder than devising clever solutions.

> No individual problem is hard. It's arguably hard to do tedious work day in and day out for months at a time, but I don't think people would call that "technically hard".

Re: How to talk about yourself in a developer interview

#133

Post by mjibson »

NickLarsen wrote: post #29
lettersdigits wrote: post #22

> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block…

The localization project I use as an example here was definitely one of my top 3 hardest projects of all time (and that was years ago). It was not a particularly difficult technical challenge, it was difficult because it touched every single aspect of the codebase. The project took me and a coworker 3 months to build out the infrastructure for, then another 3 months of actually rewriting everything to use it, and exp…

Off topic but: this is some good nostalgia here. I was that other coworker. Some of the best pair programming I've ever done. It was fun working closely with Nick.

Re: How to talk about yourself in a developer interview

#134

Post by ereyes01 »

lettersdigits wrote: post #22

> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block…

My go-to answer is my time when I worked in AIX kernel development at IBM. We'd get bugs for kernel crashes that appeared related to memory corruption. They frequently ended up being caused by stale DMA addresses in device drivers for (mostly) Infiniband adapters writing into memory that now belonged to some userland process or kernel data structure.

How I'd debug these (it took me a while to be effective in this regard):

  - Main tool was the AIX kernel debugger (like cutting bone with a butter knife :)
  - Identify corrupted memory, look for clues like recognizable data structures or pointers in the raw dump that could be cross-checked against symbol maps, etc.
  - Confirm the alignment of the corrupted memory. Page alignment was a tell-tale sign of errant DMA writes in our system... cache alignment is more mysterious and can be related to CPU design bugs (IBM designs their own POWER processors, and we'd test on alpha hardware frequently).
  - Scour the voluminous kernel trace for the physical frame # of the corrupted memory. A typical offending sequence was: 
    1. Frame assigned to adapter for DMA
    2. Physical memory layout change (we supported live hot-swappable memory arbitrated by the POWER hypervisor)
    3. Frame allocated for use by page fault handler
    4. Crash happens
Sometimes the root cause was that the device drivers were not properly serialized with the dynamic memory resource subsystem (the hot-swappable memory) and the sequence above happens very quickly (We had to be like a prosecutor and build a strong case to implicate a bug somewhere else. Until then, our team was always on the hook to figure these out.

This class of problem was hard because the tools we have at our disposal to collect evidence were quite inadequate, and the amount of data to sift through was enormous. Also, any tool we think might help to sift through all this data needed to already be in the system and in the kernel debugger as a diagnostic command (a crashed system in the debugger cannot be modified in practice). There's hundreds of those debugger commands for all kinds of randomly recurring problems we had trouble figuring out. Over time, you'd build your own for your own set of problems in your kernel specialty :-)

Re: How to talk about yourself in a developer interview

#135

Post by kafkaesq »

What is the hardest technical problem you have run into?

Almost always asked from companies that don't have problems to offer even remotely comparable to the "war stories" they're expecting to you rattle off -- at least not for the position you're applying for, anyways.

Re: How to talk about yourself in a developer interview

#136

Post by alok-g »

itsjustjoe wrote: post #102
lettersdigits wrote: post #22

> What is the hardest technical problem you have run into? I never seem to find a quick good answer for this. Maybe I just almost never work on REAL hard things. So my question to you, HNers, is : What is the hardest technical problem YOU have run into? I am really interested to know what you would consider 'hardest'.. It's probably not going to be something like 'I changed the css property value from "display: block…

I ask: 'Tell me about a problem that was particularly challenging' I'd love for someone to tell me a story about something they couldn't solve (or at least not the way they wanted to). If they can't come up with something, which is rare, I ask them to tell me about something that was fun for them.

>> I'd love for someone to tell me a story about something they couldn't solve

I was in twelfth grade. I was given some EEPROMs which I had to write data to, just that I did not had the standard equipment to write to it. I used a printer port to drive an amplifier circuit I built, which in turn sent the voltages to the EEPROM. I sent waveforms exactly the way the data-sheet suggested. Yet, I wasn't able to read back what I was writing.

I had no oscilloscope or waveform analyzer to debug. All I could do was to re-read the data-sheet and then my program for correctness.

I could never figure why wasn't it working.

Later, my Dad found someone who did have the company-supplied EEPROM writing equipment and took the EEPROM to them. He learned that there was just data on the first few locations on it.

This is one of the very few projects where I have failed. Being in twelfth grade then, doing stuff that would fail college grads, I have not taken an offense with myself. :-)

Re: How to talk about yourself in a developer interview

#137

Post by cthalupa »

dahart wrote: post #25

I see some criticism on this point, but for me this passage is a gem. > In general, real stories are told chronologically backwards. This is why we start off with a punchline. In contrast, practiced stories are told chronologically forwards. It’s a solid indication as the interviewer that the person is reciting something they have committed to memory if they tell the story forwards, and in turn it’s significantly mor…

> In general, real stories are told chronologically backwards. This is why we start off with a punchline. In contrast, practiced stories are told chronologically forwards. It’s a solid indication as the interviewer that the person is reciting something they have committed to memory if they tell the story forwards, and in turn it’s significantly more likely that the story isn’t entirely true.

This is awful and just completely untrue. Many companies that take the time to want to do interviews properly will have something similar to STAR or SOARA implemented, and you'll be starting with the situation, move on to the tasks/target you wanted to complete or hit, the actions you took to achieve that, and the results of what you did. This is chronologically forwards.

This comment is the kind of psuedoscientific crap that makes interviewing a crapshoot and is a good indication of an unstructured interview.

Re: How to talk about yourself in a developer interview

#139

Post by cookiecaper »

wernercd wrote: post #123
cookiecaper wrote: post #94

Earlier quoted context omitted.

This is not impressive. This is normal. When they say "What's the hardest thing you've done?" I would hope that if you are going to run with this, you explain why conventional maintenance/upgrades were so extraordinarily difficult in this case. Every developer dreams of going greenfield. Ultimately, that's because it's harder and much more tedious to read code than to write it. If you start from scratch, you understa…

"This is not impressive" That's because I've given you a mile high description. We have an outside consultant who does one thing: Fix businesses. When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it. While I understand and don't disagree with what you say - a full rewrite is normally not the answer - you haven't seen this codebase. Or the co…

>When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it.

I take it as a consultant emphasizing biases that favor his presence.

Anyway, the point of my comment was not to nitpick your specific situation, which I have no information about and obviously cannot speak about intelligently. Perhaps it is as extreme as you indicate. If so, my only suggestion would be to focus on the difficult problems rather than colorful characterizations of them. In an interview, the employer will know about its own problems, and may imagine your running the interview circuit and saying all the same kinds of things about them.

The goal is that as general advice for what to say when someone asks about technical accomplishments/pride, talking about the nightmarish situation you're coming from is first, trite, and second, a signal that you may not possess the cooperative qualities or the perspective to properly evaluate situations as they arise.

Re: How to talk about yourself in a developer interview

#140

Post by ssttoo »

pc86 wrote: post #66
wernercd wrote: post #35

Earlier quoted context omitted.

> > What is the hardest technical problem you have run into? >I never seem to find a quick good answer for this. Real easy: Overcoming technical debt/bad decisions of the previous group of programmers. At my current company/position, our group basically replaced an outside company - two programmers. You name something you should do and they did it: Code in the behind, logic in triggers, plain text passwords, direct d…

> Overcoming technical debt/bad decisions of the previous group of programmers. This is often a gold mine, just make sure your interview doesn't become a discussion about how bad other programmers are.

how about overcoming technical debt you created yourself in the past? :)
Post reply on HN