5 ms·
To be honest, while documentation is extremely important in the real world, interviews are time-constrained, and it makes no sense to write documentation when y
by GGfpc 7y ago
To be honest, while documentation is extremely important in the real world, interviews are time-constrained, and it makes no sense to write documentation when you have 45 minutes to implement something like that.
- Yhippa 7y agoI'm not defending those types of interviews, because I'm not great at them, but it seems that they're looking for human algorithm machines. People who can go in and write very specific performant code. Maybe that's the requirement for the job as opposed to someone who can interface with businesses and do general enterprise software.
- sdegutis 7y agoI have personally found that sometimes writing out comments that explain how a confusing function is going to work will help me to understand the ins and outs and flow of the function before writing it, which will in turn help me to actually write the function, especially with algorithmic functions. Those comments might as well be written as long-standing documentation that doesn't change as long as the implementation/algorithm doesn't change. I know "comments lie" but if it's a long-lived implementation, it's more beneficial than not.
- jniedrauer 7y agoWriting a function docstring is just muscle memory for me. It's part of my process. Explain the objective, then implement it. Docstrings are usually the first or second thing I write after the function signature. I would also have serious reservations about taking a job where documentation is considered a negative during a coding interview.
- xahrepap 7y agoI disagree. It's one way for the interviewee to reiterate back to the interviewer that they understand the problem and constraints.
- ChrisMarshallNY 7y agoIgnoring dozens of repos (non-forked), and thousands of lines of testable, shipping code, is probably not helpful. I was a manager for a long time. I loved long résumés and relevant material. I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting. Also, I never gave a single test, and I think I got it right, every time.
- leshow 7y ago> Also, I never gave a single test, and I think I got it right, every time. There's bound to be some confirmation bias there
- ChrisMarshallNY 7y agoYes. I confirm that everyone that worked on my team worked out well. Some had more challenges than others, but we got the job done. The team worked well together, and we worked with our overseas compatriots in exemplary fashion. I was very fortunate. It was a small, high-functioning, C++ team of experienced engineers. All family people, with decades of programming experience. I'm quite aware that this was a luxury. I'm grateful for that.
- saghm 7y ago> All family people, with decades of programming experience I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?
- ChrisMarshallNY 7y agoYou are reading it wrong.
- saghm 7y agoCould you clarify what the intended reading is, then?
- onion2k 7y agoHiring people who can pass a clever quiz without verifying if they do good work in the real world is precisely how a company ends up at the top of HN with the headline "Apple, Your Developer Documentation Is… Missing". I would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constraint then schedule a longer interview.
- keithnoizu 7y agowhat key macros do you setup to make jumping around in your IDE faster.
- onion2k 7y agoIt's even worse than that really. Most of these white board tests seem to be "Have you revised this specific algorithm for your interview, and found the specific implementation we're looking for?" If you have, great. If not, rejected. As a method of finding good candidates it feels like it must suck but so few companies are willing to actually measure their hiring effectiveness (and be open about it).
- dbt00 7y ago> Most of these white board tests seem to be "Have you revised this specific algorithm for your interview, and found the specific implementation we're looking for?" If you have, great. If not, rejected. As someone who has given hundreds (maybe thousands) and received dozens of these types of interviews, it's really not. Generally speaking I'm looking for at least 2-3 of these abilities, depending on which question I'm asking: 1) Can you reason about data structures and algorithms when looking at a problem you haven't seen before? 2) Can you communicate your ideas effectively? 3) Can you integrate new information from a colleague while problem solving? 4) Can you write code that makes sense? Do you understand basic programming concepts? 5) Can you read your own code and reason about it? There is at least two hidden attributes that I'm not testing for but do affect performance, so I try to account for them: 1) Are you comfortable with me, a relative stranger? 2) Can you do these things while dealing with a high pressure situation? You will encounter high pressure situations at work but often interviews feel more high pressure (to some people) than most daily conversations about engineering. That's it. If I can tell a candidate already knows "the right answer" to the problem, I'm usually disappointed because I'm more interested in watching them think.
- RaiseProfits 7y ago...which just shows how noisy that signal was to begin with.
- wolco 7y agoAt another company not writing it would fail you. It's difficult to know when to apply the correct answer-