Live data from Hacker News

How to win the coding interview

blog.devmastery.com

111–120 of 305 posts

Re: How to win the coding interview

#111
> Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation.

> It’s not unreasonable to expect that you know the basics of RegEx

So that's a fairly arbitrary distinction. Regex has a famously terse syntax. Maybe in some jobs it's used frequently, and in those cases I could expect someone to recall the basics. But it's been my experience that regex comes up just infrequently enough that I never recall the exact expression, and then spend more time googling a regex tutorial (even more if it includes groups or look behind) to refresh myself than I would have if I just had a strings library that just had .StripWhitespace() .Contains() .Startswith() .IsItAValidPhoneNumber etc etc functions.

Re: How to win the coding interview

#112
post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

This is a decent solution if you are a freelancer or between jobs or family free and able to relocate short term (you could do it remote but job interviews if you actually work on premise should also be on premise to some extend). If you're currently holding another job it's pretty tough as you'd essentially have to take a week of vacation time or do all the work remote.

Re: How to win the coding interview

#113
post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

In a whiteboard interview, comments can/should just be said out loud to the interviewer.

Re: How to win the coding interview

#115
post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

I have done what you have proposed and it worked for my latest job (2 years and counting). I flat out refused a coding interview. I openly said, in my experience as a developer, great candidates fall through the cracks because they fail under a controlled environment which does not reflect the real world. They actually agreed with me. I came in and did a one week trial, I brought in my own computer, they gave me acce…

Let me add a somewhat unrelated side note since you have some say in the new hiring process which is awesome btw. and the company sounds like they "get it"...

Bring your own device should always be understood as a security tradeoff. Especially if it's someone who is auditioning for a job (I'm sure you're aware of that but can't hurt to point it out).

Re: How to win the coding interview

#116
post #54

Why regexes combined with the pre-processing? First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer. If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation. And if the inputs are very large then the probability of contradiction in the firs…

Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either st…

[deleted]

Re: How to win the coding interview

#117
The author have a list of secret good questions, and that is not helping anyone. He expects the candidate to think loud and be explicit, but are himself very implicit in his requirements. What I consider production code is without a doubt different from what he things is production code.

> Your code should be commented.

Then put this requirement, because judging from the example, the authors expectations, is what I fail students and junior devs for. Comments are complementary and explain things like "the why" ("pad to multiple of 256, otherwise libX will hang"). Don't expect people to automatically know your implicit requirements, it's a recipie for disaster.

> You should have error handling or at least logging.

Again, put this in the requirements. Some environments need no error handling, because the error handling is external. And don't get me started on logging. Yes it's nice in a debug situation, but in many high volume production systems you have engineers with the sole responsibility of creating a logging system that impact performance as little as possible.

> You should have a test harness.

If you say so, otherwise I'm not going to make one. Be explicit.

> Runs fast. > Doesn’t take up more memory than it needs to. > Is stable and easy to maintain.

1. and 2. are secondary. 3. is king, unless you have empirical evidence that warrant 1. and 2. This is something many developers struggle with, including the auther by the sound of it.

> RegEx

No, just no - the imfamous quote is "I have a problem, let's use a RegEx. Now you have two problems" and it's true 98% of the time, including testing if a string is a palindrome. Besides, regular expressions cannot identify palindromes - this is first year CS stuff. I'm well aware that some implementations allow back references, thus they are not really regular expressions but leaning on CFGs. For this particular problem, reversing the string and then compare is by far the most readable and understandable solution.

> For senior devs, I want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points I want you to flag any of your assumptions in the comments.

What is optimal? With regard to execution time? Memory usage? Maintainability? Program size? What kind of error handling?

Re: How to win the coding interview

#118
post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

>>> I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value.

I don't really agree with this statement.

The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results.

You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring.

But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)

Re: How to win the coding interview

#119
post #76

Earlier quoted context omitted.

I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one wee…

Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates.

If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

Re: How to win the coding interview

#120
post #66

Earlier quoted context omitted.

>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value. Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and…

The fact that you need to involve three different departments just to hire someone for a week is a key part of why hiring is so broken these days.

Some companies have trade secrets. Do you think Google is really going to let you come in and poke at the Search stack for a week just to see if you're hireable?

This isn't about the number of departments. This is about companies needing to make very real tradeoffs between maintaining their current speed/security/stability and investigating future talent.

Post reply on HN