Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Facts Should Be Resident in a Developer’s Head?

DZone's Guide to

What Facts Should Be Resident in a Developer’s Head?

How much implementation details should a developer remember when going for an interview? Should you remember whole algorithms by heart?

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I just finished reading this reddit thread about a guy that cheated to get a job (the original post doesn’t really shed a good light on anyone there) and the comments related to that.

That got me thinking about our own interview process and what kind of things I expect people to have in their head, for interviews, but also in general. In particular, this comment:

Honestly, I wouldn't hire someone who couldn't code a search or sort algorithm on a whiteboard and tell me how e5fficient or inefficient it is.

Another example I heard of in a conference is literally examining people on Knuth. To the point where you didn’t know chapter and verse for Oscillating Sort (literally, in what chapter is that covered), for example, you are obviously worthless and there is no point in continuing in the interview process.

For myself, I don’t think that I bother keeping any actual details about algorithms in my head. Much more important is to know about the algorithms and to be able to have just enough information to recognize that it might be a viable option for my use case and then read up on the details.

In interviews, and in their work, I would expect people to know about big O complexity and be able to tell what kind of complexity a specific piece of code had, as well as whatever this was good or not.

As for implementing a sorting algorithm, I remember some of the details on how quicksort works - but actually writing that from scratch? There are far too many details for this to actually be a viable option.

For example: 

  • Lomuto or Hoare partitioning?

  • What about the choice of pivot?

  • How about parallelism?

  • How do you handle repeated elements?

I just pulled those from the Wikipedia page, mostly because I remembered this post about how to answer such interview questions.

Implementation details shouldn’t matter (beyond understanding costs & complexities), so they shouldn’t take up valuable mental space in your head - that is why we can search for that. The important thing is that you know that you need to look up additional information, as well as know how to do so.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
agile ,interview ,developers ,algorithm ,career

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}