Live data from Hacker News

How to talk about yourself in a developer interview

stackoverflow.blog

151–160 of 194 posts

Re: How to talk about yourself in a developer interview

#151
post #146

This is one of the best blogs on the topic and as someone who has easily cracked all big tech company interviews I can say this is a good piece of advice. I will make following broad points: 1. Never walk into that room without practicing. Practice before a mirror, practice before a friend, practice in a car. Have a written script and optimise it to remove redundancy, highlight achievements etc. It is not about repea…

If that's what it takes to get a job as an engineer at the big companies, it's not particularly surprising that the quality of their engineers has declined as they've grown.

The skills of a con artist are not related to the ability to build good systems.

Re: How to talk about yourself in a developer interview

#152

> 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…

One of the most complex on the front-end was a repaint/reflow issue in Safari that was complicated by the way we were using Angular.

The easiest solution was to use transforms to force rendering through the GPU render pipeline by adding a Z-depth to the elements.

Which caused rendering issues in rendered font-weight for Firefox. We never resolved the issue, even after a root cause analysis showing the bug in Webkit and not Blink or Gecko.

On the backend, it was finding a way to store a persistent collaborative changelog with proper access control and heirarchy on top of a RDBMS. Resorted to redesigning a distributed file-system based on HFS+ and btrfs for COW and COR obligations. This is one of the most data-structure and depth of infrastructural knowledge problems I had to address.

Re: How to talk about yourself in a developer interview

#153
post #146

This is one of the best blogs on the topic and as someone who has easily cracked all big tech company interviews I can say this is a good piece of advice. I will make following broad points: 1. Never walk into that room without practicing. Practice before a mirror, practice before a friend, practice in a car. Have a written script and optimise it to remove redundancy, highlight achievements etc. It is not about repea…

If that's what it takes to get a job as an engineer at the big companies, it's not particularly surprising that the quality of their engineers has declined as they've grown. The skills of a con artist are not related to the ability to build good systems.

Conversely, the skills to build good systems are not related to working effectively with others. There's probably a balance that needs to be struck, though they're also not mutually exclusive.

Re: How to talk about yourself in a developer interview

#154
post #146

This is one of the best blogs on the topic and as someone who has easily cracked all big tech company interviews I can say this is a good piece of advice. I will make following broad points: 1. Never walk into that room without practicing. Practice before a mirror, practice before a friend, practice in a car. Have a written script and optimise it to remove redundancy, highlight achievements etc. It is not about repea…

>2. Converse not interview

This is good advice but it applies to both sides.

The best way to learn about a person's technical background is to start from a common base and go over their experience. I like to start talking backwards from their resume, and say "OK, Job A. What were you focused on there? Your description mentions technologies B,C,D. How did you apply them?"

You then just take it from there, pick up on the things they discuss to get into the technicalities. Ask them hypotheticals. Ask them how that technology could apply to a different problem set. Ask them about things that annoyed you specifically about those technologies in the past and how they addressed/resolved them. etc.

This is the best way to interview in my experience. It keeps the pressure low, it doesn't waste time on rehearsed answers, it doesn't waste time on whiteboarding unless it comes up (a very basic takehome project (30 minutes) should be given pre-interview), it lets the person discuss their experience and provide real feedback about the things they've learned. It gives them the opportunity to discuss their technical habits, values, and interests. It reveals the most about the candidate in the minimal amount of time.

So many of my colleagues would lock up when they'd go in to interview people and not know what to do. They'd sit there and just expect the candidate to know what they wanted to see and carry the whole thing. They'd print off a list of questions that they found from a site about how to interview people, or they'd give them a code trivia quiz that is a massive waste of time for everyone.

All of that is very silly and misses the point. Everyone just needs to relax and hold an unscripted technical discussion. You can go in with an outline to make sure you hit the topics intended in the course of the discussion, but shouldn't need more than that.

Re: How to talk about yourself in a developer interview

#155

Earlier quoted context omitted.

If that's what it takes to get a job as an engineer at the big companies, it's not particularly surprising that the quality of their engineers has declined as they've grown. The skills of a con artist are not related to the ability to build good systems.

Conversely, the skills to build good systems are not related to working effectively with others. There's probably a balance that needs to be struck, though they're also not mutually exclusive.

> the skills to build good systems are not related to working effectively with others

Yes they are if you're talking about the types of systems that large companies have. It is in fact so difficult that I believe it's a considerable advantage to have scopes small enough to be manageable by a single engineer, but inherent complexity is often well beyond that, especially for very profitable business engines.

Re: How to talk about yourself in a developer interview

#156

> 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…

>> What is the hardest technical problem YOU have run into?

I have solved about ten "hard" problems in my career, most of which has been in R&D. Each one of these had multiple prior failed attempts, and in some cases took me months of thinking before I could find a solution.

1. Qualcomm wanted me to devise a computer vision solution that was more than two orders of magnitude power-efficient than what they had then. There was a clear justification existing as to why such a drastic improvement was needed. Nobody had a solution in spite of trying for a long time. Most laughed it as impossible. I started by looking for a proof as to why it could not be done if it indeed could not be done. After some three months of pulling my hair, I started getting glimpses of how to do it. Some three months later, I could convince myself and a few others that it is doable. Some three months later, the local team was fully convinced. Some three months later, the upper management was convinced. You can read the rest here: https://www.technologyreview.com/s/603964/qualcomm-wants-you...

2. I wanted to solve a specific machine learning and Artificial Intelligence challenge. I would code for a day or so, and then again run into days of thinking how to proceed further. E.g., coded a specific parser algorithm for context-free grammars, including conversion to Chomsky normal forms, in 1.5 days including basic testing. However, what's next. Woke up with new ideas for about ten days in a row. Conceived Neural Turing Machines back in 2013, about a year before Google came up with their paper on the subject. (Unsurprisingly, I did not had that name in mind for it back in 2013.) I also did not get an actual opportunity to work on it, as a result of which I am still not sure if I could have actually done it.

3. Needed to make a very sensitive capacitance measurement circuit, trying to get to atto Farad scale floating capacitance even with pF scale parasitic capacitance to ground. The noise and power requirements were very challenging. After about three months of seeking inputs from the team lead without hearing a solution, I ended up coming up with a solution. I later discovered that the technique was already known in RF circles, though only a few were aware of it. Capacitance measurement circuits with such sensitivity did not show up in the market for several years. (My effort was target at using inside a bigger system.)

4. I was working on measuring bistable MEMS devices. The static response of these was well understood. However, so far, the dynamic response was only measured by the team; there was no theoretical explanation behind it. We invited several professors working in the field to give seminars to us, and asked questions for this, but never heard back a good answer. A physicist colleague found an IEEE paper giving the non-linear differential equations behind it, which worked, but yet provided no insights into the device behavior, and took time to solve numerically. I wanted a good enough analytical solution. I kept on trying whenever I had time-opportunity, while the physicist colleague kept on telling me to give up. Six months later. I woke up with a solution in mind, and rushed to the office at 7 am to discuss with whosoever was there at work at that time. The optics guy I found did not fully understand it, but did not find it crazy either. A few hours later, the physicist friend confirmed my insight by running some more numerical solutions. I could then soon find tight enough upper and lower bounds, and the whole thing fit the measurements so well that most people thought it was just a "curve fit". (It was pure theory vs. measurements plotted together.)

5. I proposed making pixel-level optical measurements on mirasol displays using a high-resolution camera to watch those pixels after subjecting them to complex drive waveforms. Two interns were separately given the task (surprisingly without telling me), and both failed to develop algorithms for pixel-level measurements. Later a junior employee worked on it, was unable to develop pixel-level measurements still, though was able to get it to work at lower resolutions. The system took about 40 minutes of offline processing in Matlab. Later, a high-profile problem came up where pixel-level measurements were a must, and I was directly responsible for solving. Solved in one day. Processed images taken in real-time, not 40 minutes. The system stayed in deployment for years to come.

6. We had bistable MEMS devices, and there was a desire to make tri-stable MEMS devices. Several people at the company attempted it, including a respected Principal Engineer, but no one could figure how to even start. I could not figure either at the outset, but started bottoms up from Physics and using Wolfram Mathematica to create visualizations around the thing. And bingo. In a few days, I had not only figured how to make these tri-stable MEMS devices, but also multiple schemes of driving them. My VP's reaction was "Alok, you should patent that diagram itself", given the clarity it had brought on the table.

7. We were creating grayscale/color images using half-toning. A famous algorithm, Floyd Steinberg, works very well for still images but has lots of artifacts for videos. An PhD student working in the field was brought in as an intern, nevertheless, the results were not great. The team also tried binary search algorithms to find the best outputs iteratively, however, it was not implementable in real-time as needed. I was interested in the problem, but was not getting time to give it a fresh thought that it needed, until one day. A few days later, the problem was solved. I developed some insights into it and just had the solution coded, to the surprise of people who had spent months working on it.

I could go on writing about more cases.

Re: How to talk about yourself in a developer interview

#157
post #34

> 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 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…

You are over analyzing it. The question isn't about defining what a hard problem is. It's about sharing how you overcame problems. And the interviewer is looking for stories that demonstrate how you overcame those problems. Times when you lacked the necessary skill to achieve something.

Not being able to answer this question is just a telling as an answer itself.

Re: How to talk about yourself in a developer interview

#158

> 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…

Talk about a problem of the same type as those likely being faced by the interviewing company.

Re: How to talk about yourself in a developer interview

#159
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…

I'm pretty sure I tell my stories chronologically forwards. What a strange accusation. (This is one of those things that's going to bug me for a while every time I tell a story.)

The assertion in the OP is that forward stories are practiced beforehand and are thereby less likely to be true. I am introspective in nature, so I do have many (true) stories thought over again and again.

I would rather disagree to the idea of telling stories backwards. We aren't doing Memento things after all! :-) It's best to tell the (true) story the true way, the way it happened.

Re: How to talk about yourself in a developer interview

#160
post #70
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…

That's actually my default response when people intimate the work I do must be complex / I must be clever - it's really just hard graft. Sometimes you just have to be willing / stubborn enough to chip away at a problem that initially seems insurmountable. Sure, the more knowledge you accumulate, the faster you can figure out when to look, but often enough you just need to roll up your sleeves and bisect your search space.

I can imagine you get some pretty warty excel files. I mostly get PDF for my sins. I'm sure, like me, you've spent hours taking bits out of files until they work as expected and then figuring out what the difference is :-)

Post reply on HN