How I Learned to Stop Worrying and Love the Job Hunt
blog.stephanbehnke.com
blog.stephanbehnke.com
Basically every take home assignment. Half the time someone doesn't look at it anyways. In theory everyone should love this as it's supposed to be practical real world work vs the mostly academic hackerrank problems. In reality it's usually a waste of time. Sadly if someone has a take home like this I usually skip them unless it's very basic.
http://www.publicsafety800mhzinterference.com/CTIAWeb/
My redesign... https://goo.gl/5LGvCQ
I never heard back from the company! It was 3 days of work and that was only my 1st attempt. I guess it sucked horribly....
It would have been nice of the company to get back to me, but yeah Im unlikely going to ever do post interview homework again.
You want me to code something for you? Sure, I'm happy to sit down with one of your engineers and we can collaborate on a pair programming exercise--something that can be completed within a couple of hours and doesn't require domain knowledge. That way the company is very mindful of how much time it takes, because it actually costs them something (engineer time). Otherwise, it's all too common to see projects of the "rebuild half our app from scratch in a couple days, but use this terrible schema and do it with our exact stack, which you may not know yet" variety.
How would you react if I agreed but... sent them a link to working web application, such as on Heroku, instead of full source code ? This clearly demonstrates a person can code, and they have no rights to demand that I hand it back. (They still did in the last place I got a job, so I ended up working for them for free for a week and then 3 weeks as an intern initially). If they insist on source code, I can offer to come with printouts and discuss it.
Basically how to defend against this ? Can I have the cookie and eat it ? There isn't plenty of offers to choose from in my area.
The last time I did such an assignment they had the nerve to say it really only takes 2 hours (rather than a week), and ask for documentation and 70% test coverage. Basically a short review then plug and play.
If they pay, it's their work. But if they give you real work to do for free, you probably don't want to work for them, as it's a good chance they'll take advantage of you again at some point.
Get really good at what you do and you'll find good work on your area or remotely.
If someone says “don’t spend more than a few hours on it” then I assume that’s part of the task requirements. I’ll get as much done as I can in a few hours and put a TODO section in the readme. I assumed that the reviewer will go through the commit history and it’s a red flag if something that should have taken a few hours takes you significantly longer.
Perhaps this is the wrong approach as the last one I did I didn’t even get a response to my submission.
Of course, this all assumes that the interviewer has an accurate idea of how long it should reasonably take.
I had started on this on the Friday afternoon they gave it to me, hoping that I could work on it Saturday. That was blown, along with much of Sunday, for family obligations. Sunday night I continued, and made great/rapid progress.
Went to sleep with the idea that I'd get up early and finish it.
Though at 10pm, my mother-in-law had to go to the hospital for a severe flu, so I took her, and waited with her, with my laptop, and worked until 5am when they released her. Drove back home after dropping her off, and caught a few hours of sleep.
Company sent an email asking for my solution Monday afternoon, and I said "almost done." Had some formatting/testing I wanted to do.
They said, "no, we're done."
I was more than a little pissed. But, upon reflection, this gave me a great signal as to the nature and quality of the company and its environment. I sent a nice letter to the CTO thanking him for the opportunity, noting what I had left to do. He said "hold on, lets talk."
I said, "no, we are done."
I had several real offers by then, and didn't need any more.
I figured out it's code for: build me the assignment, plus other functionality you can think of, polish it nicely, write unit tests and integration tests, and deploy it so I don't have to pull down your github repo.
I'm not against take home, I just don't want to spend my entire weekend just to get to the phone screen. These kinds of assignments are usually step 1 of the funnel and it was very frustrating get rejected without any feedback.
Now I just screen for any companies that require it because it's better for my quality of life.
There was this one time when I got the job despite refusing to complete their Hacker Rank test, they decided to look at my github instead.
I believe it's a valid strategy to reject bad tests that waste your time.
This is my biggest weakness. I haven't worked on anything where I made a substantial contribution that I'm proud of. I've been working as a programmer for nine years.
Three years in a consultancy implementing solutions based on a third-party framework. The framework was terrible, so the best we could do was to paper over its cracks. We made things much better, but it was still very poor compared to normal software.
Two and a half years at a small company, working on their legacy codebase. We did innumerable small cleanups, bodged in new features, and did one bigger architectural change. Even the big change was the sort of thing that would only take a week in a sane codebase.
Two and a half years in an agile consultancy. Many short projects, mostly building technically rather simple things, but focusing on teaching the clients how to be better at software development. The one technically complex thing we built was mostly only complex because some plonker settled on a microservice architecture using a new messaging framework before I took over. I think we did a good job, but I can't justify the central design decision of the project!
Those companies were all agile, with pairing, collective code ownership, and self-organising teams. Even where we did something good, it wasn't my work alone.
One year so far in a hedge fund. I've built several small tools and features, most of which haven't ended up being very useful. The two bigger things I've done have mostly been about wrapping sophisticated third-party libraries in an application which integrates them into our environment - I'm a plumber.
Everything I've done has been what seemed like the most useful and sensible thing to do for the client or company at the time. None of it helps in interviews.
Or you could do a side project that would fit the bill.
Maybe focus on the non-technical results of those "useful and sensible" things?
On the other hand, if you really just want to build more "pride-worthy" things, I think you really just need to prioritize that desire more. Making something you're proud of often means going beyond what's mandated by "useful and sensible". This might sound a bit inane, but I would seriously consider asking yourself, before you start your next project(s), "How can I make this project something I'm proud of?"
In my limited (n=1) experience with startups, I'd say they take a very different approach to recruiting and should be "courted" by the applicant in a slightly different way. Relevant experience becomes more important. IMO, startups particularly care about:
1. Can the applicant hit the ground running? Startups don't want to hire people that need training, because they want them to be productive ASAP. Startup teams have very little slack, so individual productivity is more important. For example, I started working at a large company and had 3 months training before I touched any code. Then I went to a startup and pushed a bugfix to production my first day. The expectation is quite different. My recommendation would be to work on some side projects that use common startup tech stacks (Ruby, Node, Python, etc.) so they know you're familiar with more than just Java or whatever, and emphasize how you're a quick learner that adapts easily to different situations.
2. Does the applicant offer a specialization we need? Startups are always looking to increase the quality and range of their technical skillset. If you have a relevant specialization that their engineering team is lacking, like DB admin, security, hiring, management, distributed systems, AWS, etc., the startup will be much more inclined to hire you. Recommendation here would be to try to dig into some topics and gain expertise in your current company that can carry over. Alternatively, something like getting an AWS certification, publishing blog posts about relevant topics, etc.
3. Is the applicant a culture fit? For example, usually startup employees should be internally motivated, autonomous, good communicators that enjoy programming and think of development as a vocation instead of a chore. You shouldn't have to be exactly the same as everyone else, just show that you're likeable, flexible, and can do good work without a manager.
(edited: Added some additional clarifying points).
Can't you take some pride in that? Any idiot can do green fields work, they'll likely be gone before any of their mistakes get a chance to become apparent, but taking an existing lump of spaghetti and moulding it without breaking anything is a whole different ball game.
I'm currently working at a company that I interviewed unsuccessfully at seven years prior to getting the job. If I'd written up some big tell-all about the experience and waited a year and a day to publish it, it might've come up in a Google search from this round and revealed me as untrustworthy.
>"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
Who knows why you weren't chosen, but the above quote probably has a clue as to a potential why. Coming away from a failure and concluding "WTF $OTHER_PEOPLE" might have something to do with it. Sorry for the disappointing outcome; your technical skills can take you far, so don't lose hope.
That's got nothing to do with it, trust me.
It's easier for companies to have a blanket policy of never telling than to educate everyone involved in the hiring process about the complex and ever-changing realities of employment law, discrimination law, protected classes, etc.
In most cases there's no answer beyond someone else seemed like a better fit for the position. How would it help to know you would have got the job if only this other person didn't apply?
great way to look at what bothers us all after a rejection - thanks
1. It gives them a kind of closure and treats them with respect.
2. It can help them improve for future applications.
Usually, the reason is not "Someone else is a better fit". We're not just trying to fill one position -- if we find good engineers, we'll hire them. Usually feedback is related to stuff that came up in either the coding project or the interview. It helps people in the same way that code review helps them: by giving them an opportunity to learn and improve.
This is an excellent basis for a lawsuit.
(edit: I wonder if we're talking about slightly different things here. The "notes" I'm referring to are primarily code commentary -- the same kind of material we cover in pair programming. As far as I know, we don't share notes about our internal decision-making process, which perhaps is what you're talking about.)
I wasn't there and I don't know why they rejected you, but that five-hour session was a five-hour soft skills test. That you don't recognize this increases my gut feeling that the GP may be right.
The whole thing was so bad that I don’t think I’d ever like to work there. Maybe I’d go for the crazy money for a few years, but not expecting to work with nice people.
If you hire based on, say, STEM expertise, all of your employees will have lots of it. If you then do a study on what explains performance differences among your employees, STEM expertise will look useless, whether it is or not, because your employees all have similar levels of it.
The only real lesson you can draw from that is "don't do studies that have no theoretical chance of revealing any information".
Following your link, I notice that the top two replies are both making the same point.
That said, a lot of candidates also failed at very basic things (basic coding, cs trivia that everyone should know, experience questions, etc).
If you are really sure in your performance, my guess would be you just got unlucky with one or more interviewers as there seems to be a lot of randomness in the system and they just err on the side of "no hire".
I've also seen people who otherwise did well technically not be hired because they acted like a jerk.
Not saying that any of these necessarily apply to your situation of course, but no one can really know just from an Internet comment.
People just want what they cannot have. Applies in all sorts of situations.
I wish it was always that easy.
But if you already have a job, that’s the same evidence isn’t it? So why does anyone need to do a technical qualification interview after their first job?
That's very good success rate, can anyone confirm similar results? Over here (central EU states) it's more like:
>50 --> ~30 (good match they want to talk and ask for salary requirements at this point) --> ~10 (they could pay if you are "REALLY good" i.e. child of Knuth with Torvalds) --> 0-1.
The market is flooded with dirt cheap Russians and Ukrainians, even Americans/Canadians for some reason desperate to put their foot in the doors. Asking for anything above 60k EUR gross annually pretty much guarantees 0 at the end of the pipeline. Big 4 are so capricious, demanding, and time consuming (while still paying local salaries + 20-30% max) that it's better to not bother with them over here.
And I don't think the market is flooded because in our company we have difficulties to find good engineers and we pay over 60k.
For example, if you would have said "the market is flooded with dirt cheap programmers", the next question would have been: are the competent, therefore really valuable from a value per dollar perspective, or not? Once you mention their nationality, the reasoning goes elsewhere and you don't make your point (you do not follow-up on why they're dirt cheap, how this connects to their quality of work and why it causes the 60k cap).
I work with a few Canadians as well, and they didn't have access to the same salary levels back in North America that Americans do, so salary is less of an issue for them coming to Germany.
I would be interested to hear other's opinion and experience, as I will join the workforce later this year.
Applied to 10
Interviewed at 5
Job offered from 4
50k annual (which is considered much for a starting salary fresh out of university)
I just recently switched jobs, and I only seriously talked to 4 companies, all about remote roles. In all cases the companies/recruiters reached out to me, and so I basically skipped the application process.
Two made offers, one came to a mutual conclusion with me that it wasn't a good fit, and one told me that they changed their mind about remote work and would want me to move within 6 months, so I called it off.
I start at Tanium tomorrow :)
16 applications:
4 - position filled/hiring on hold
3 - I cancelled the phone interview
4 - I cancelled the in person after going through a phone screen
2 - offers rejected
1 - took myself out of consideration after seeing their technology stack
1 - found that I was missinv a key requirement.
1 -offer accepted
This was in metro Atlanta.
Probably >100 applications
~40 friendly chats with recruiters, mostly them reaching out to me randomly, very few actually from the applications
~10 phone screens with hiring managers or non-recruiter employees (the real interviews)
3 in-person, on-site interviews
1 offer
Configuration:
USA, citizen, 20 years tech experience, Silicon Valley local
I was interviewed by a startup a few years ago (not naming names as they might be lurking HN) and they asked me exactly this kind of question: can you build scalable systems, what's your experience with tons of people hitting your API, and so on and so forth. I was thinking to myself "holy shit they must really be blowing up" only to find out 15 minutes later in the conversation that their API was being hit like 200 times a month.
It's the same when people have 10GB of data and think they need big data scientists.
On a personal note, I loathe having to do interviews (and I also dislike interviewing people), but if none of my projects take off, I'll have to head back into the maw of that soul-crushing corporate machine all over again.
So true, but in my experience, once you spread the words, other business owners will jump in like an infectious disease and ask for a ticket to use your system. Now your USB won't work anymore. So people "higher-up" want to bet on "fail big" than "fail short", very counter-intuitive, but that's exactly how some enterprise IT spend their budget.
Saw the same thing, but with Kubernetes. They spent so much making the platform infinitely scalable, that they ran out of budget to build the actual product that was supposed to sit on top of that infrastructure (╯°□°）╯︵ ┻━┻
Corporate software engineering is insanity.
If you want to make a lot of stable liquid money (400,000$+ for principal engineers at big companies and 7 figures for the top individual contributors), then you need to join a big company and deliver high value results consistently to get those offers/promotions (probably a little luck too).
In other words, go be Elon Musk or Steve Jobs.
If you’re not already Elon Musk or Steve Jobs, then that might be a little harder for you to do.
Also, this only applies to an elite subset of "big companies". Few, if any, individual contributors at Oracle or IBM are anywhere near that.
Making principal is even harder but I think it is pretty attainable if you put in extra work where the extra work is learning about your field and applying it to the business problems for your org.
I work at one of these companies and most people are 9-5'ers who work as cog's, don't spend extra time learning about their field, don't think big, and don't apply them to the job (aka, aren't leaders which is what principal engineers are).
Outside of that environment, I think that number is a little unrealistic.
Shipping MVP is really crucial for a startup. Don’t build a mega-internet scale setup. Yes you can start using AWS and takes advantage of the basics scaling features, but there you go - talk about how to leverage those services to make scaling less a hurtle in the long round. That’s what I want to hear as an interviewer.
I want to hear about trade-offs and ramp-up. Picking the grading application I worked on, as the candidate I would want to know a high-level view of the stack, and try to identify and address shortcomings with the interviewers together. System design round should feel like a collaboration, whiteboard “pair-sketching” (analogus to pair-programming”. If that was not your experience, sorry.
Anyway, point being when there is a take-off, I want to be sure my coworkers and I have good intuitions and ready-to-use knowledge to keep our product afloat. More importantly, we want to start thinking about scaling, availability, fault tolerance and all the big words now. We don’t need a manager walk by and ask “so what should we do today team?”
Everyone should be proactive. That should be the point of a system design round. Much of that round shoukd be spent on questioning and then answering back and forth. The interviewer SHOULD be talking too as much as the candidate; it should not feel like giving a talk or giving an oral read of your PhD thesis. If most of your interviewers onsite behave like an exam proctor rather than a peer, consider the culture a bit unfit for yourself (take offer now and do another hunt is up to you). This is IMO the best “culture fit” test both sides can use. Don’t judge on the elegancy of the solution (big plus for clever soltion), but reward points for how pleasant it is to be in a room working together.
Take the questions on scalability for instance. I personally don't have any experience with scaling on requests, my highest demand was an application with <5000 users for the entire client base. I want the experience so in my last job hunt I apply to a number of jobs that I know get a lot of traffic. I tell the recruiter the chance to get experience in that skill set is why I am applying. The recruiter tells me the desire to learn is all they want. I get to the interviews and have the same talk with the engineers and the same response. They then ask me system design questions and I answer as best as I can along with bringing up approaches I've heard of but don't have experience with. Interview ends and the recruiter tells me they are passing because I don't have the experience in scaling they want. I had this happen with multiple companies.
Not wanting an employee without that experience is perfectly fine, but why waste everyone's time when an interviewee tells you from the get go that they don't have one of your must haves? When resumes are passed over for implicit signals like which school you're from, unusual names, spelling errors, etc, why go through all of it? It's because most companies and most people interviewing have no idea what they want or what they are doing and are just copying approaches they've seen before.
It's the same problem that gets you interviews where they want you to reverse red black trees on a whiteboard but the actual job is just implementing CRUD api's, or building jobs that run an algorithm that is basic algebra once a day.
At this point a "grill you on everything" interview for any position that's not director level or someone getting paid double the market, because they actually need you to know everything, is just a red flag that the company has no idea what's going on and you'll have better luck making the interviewers like you as a person than actually learning all those skills
Recruiter here. I interviewed with a company ~9 months ago and they asked me "how do you choose whether to hire for experience or pedigree". I gave a bunch of reasons why you might trade off one for the other and the interviewer made a bit of a sour face. He then asked me "is there another way to phrase what you're saying?" I said "Well, the way you make those tradeoffs depends on..." and he cut me off and said "thats what i was looking for". When I asked what he meant, he said that the answer on the sheet was "It depends" and he wanted me to literally say those words.
I didn't continue the process as I can't imagine the type of culture that gets people to that point of disengagement.
People are animals and animals are lazy so the path of least effort gets chosen the majority of the time, and that means going off of predetermined scripts.
HR / legal might have a say when it comes to hiring like a C-level executive.
I am stunned by this!
I understand the frustrations with questions unrelated to the job you'll be performing, such as asking about balancing b-trees when you're applying to make frontend CRUD apps.
But trick questions bother me so much more. This one in particular is something you'll probably encounter if you do frontend development in a functional style for long enough, but it's still a trick question at heart.
['1', '2', '3'].map(parseInt); // While one could expect [1, 2, 3] // The actual result is [1, NaN, NaN]
parseInt is often used with one argument, but takes two. The first is an expression and the second is the radix. To the callback function, Array.prototype.map passes 3 arguments: the element, the index, the array. The third argument is ignored by parseInt, but not the second one, hence the possible confusion.
Neither of these are doing anything wrong on their own[1]. When you go to map something you want to be able to access the index sometimes. When you parse an int, you sometimes want to be able to specify a base. Maybe in a strongly typed language you might use an enum with valid bases instead of an int, but that doesn't make sense in a dynamically typed language[2]. Maybe you use different function names if you want to parse an int in decimal vs an arbitrary base, I can't argue with that, but overloaded functions/methods are the norm and not the exception in most languages I've used.
[1]: Except parseInt's default radix which is ambiguous and the cause of countless bugs. But this bug is because we ARE specifying it.
[2]: And no, being dynamically typed is not inherently bad design.
Actually, to be honest will NaN even launch an exception? Does 1 + NaN cause an exception or does it propagate more NaNs all over the code?
Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN. Where did this error occur in the 10000 lines? Sure, I can say all kinds of stuff to make finding this error sound simple but if exceptions were thrown instead of assigning NaNs to some variable life would be easier. The exception would tell me the exact line of the illegal operation while a NaN tells me nothing.
Javascript treats the "NaN" type as if it's a number... in the sense that when you do a math operation on something that is a NaN you get another NaN... The reality is... the very abbreviation "NaN" stands for is "Not a Number" so the addition of a number and something that is not a number should not even occur. Seriously? They should have called it "LoL" or "WtF" because these are more appropriate abbreviations.
JS uses double-precision floating point numbers, based on the IEEE 754 standard first published in 1985.
[1]: Though there is a case that using doubles for all numbers is poor design, that's a different topic altogether.
Not to mention a null. null + 1 = 1. This is even worse. Your 1000loc function returns a legit number but it's a little bit off... and you have to find it. Imagine never having to have to do that with a language like python... 1+None and 1/0 all return named exceptions with line numbers in python.
Because all modern processors and mainstream languages implement their floating point calculations as IEEE 754.
> when did i say I want to make arithmetic slower?
When you said you wanted to introduce exceptions whenever NaN is encountered.
Your processor has instructions that add/subtract/divide/multiply floating point numbers according to the IEEE 754 standard. What you propose is to then check in the implementation of JS after each instruction to see if the result is NaN, which is going to be a speed reduction of at least 2-3x, though I would expect it to actually be higher than that because branching can get expensive. (Making a note to go try it and benchmark)
Then, after doing this check, you want to have JS throw an exception. This only slows down the uncommon case, so that's not much of an issue, but in situations where NaNs are able to be treated as valid values, they then have to catch these exceptions and resume normal execution flow.
The result is that there is a happy path slowdown of arithmetic operations by at least 2-3x, to gain an arguable advantage in debugging time in the unhappy path.
Throwing away compatibility with other languages and working against the processor are not goals I'd shoot for, and wrapping basic arithmetic in try/catch blocks doesn't sound like a very good payout for doing so.
Almost every popular language launches an exception when you do a divide by zero.
>Your processor has instructions that add/subtract/divide/multiply floating point numbers according to the IEEE 754 standard. What you propose is to then check in the implementation of JS after each instruction to see if the result is NaN, which is going to be a speed reduction of at least 2-3x, though I would expect it to actually be higher than that because branching can get expensive. (Making a note to go try it and benchmark)
Try it, I'd like to see the results. I'm not too familiar with the processor implementation, but something tells me that if every system level language implements exceptions for division by zero then the cost must be minimal. Also how would it be a 3x slow down? At most it's just one instruction.
Interestingly in some languages integer division by zero throws an exception and floating point division by zero returns some kind of infinite or NaN value.
If this behavior was propagated down from processor design, I'd say the processors made a bad choice. Why is this behavior specific to floating point? Why is the behavior for integers different. Either way when I say poorly designed, I mean poorly designed in terms of usability, not speed. Clearly, javascript wasn't initially designed for speed.
>Throwing away compatibility with other languages and working against the processor are not goals I'd shoot for, and wrapping basic arithmetic in try/catch blocks doesn't sound like a very good payout for doing so.
Like I said, the purpose of a division by zero exception is not to be caught. It's to prevent a buggy program from continuing to run. The only place a division by zero operation can legally occur is if the zero arrives via IO. In that case it's better to sanitize the input or detect the zero rather than catch an exception.
1.) Divide by zero returns Inf, not NaN.
2.) I just tried C++, Java, C#, Go[1], and the champion of safety: Rust. All of them evaluate to Infinity when dividing a double by 0.0. No exceptions to be found.
> Try it, I'd like to see the results. I'm not too familiar with the processor implementation, but something tells me that if every system level language implements exceptions for division by zero then the cost must be minimal.
But they don't. Not every system level language even has exceptions and the ones that do return Inf as stated above.
> At most it's just one instruction.
Branches can be expensive if the branch predictor chooses the wrong path and forces a pipeline flush. Should be able to work with the predictor so that happy paths are true and that should make it less likely, but I'm not an expert there.
> The only place a division by zero operation can legally occur is if the zero arrives via IO. In that case it's better to sanitize the input or detect the zero rather than catch an exception.
In many applications this is true. Not all.
[1]: You do need to make sure Go treats both operands as doubles, easiest way to be sure is to declare x and y as float64 and then divide them afterward. But when actually dividing a float64 by another float64, it does evaluate to Inf as well.
Well, Rust doesn't have exceptions, so it wouldn't happen, but yeah. To your parent, these languages follow IEEE 754, as far as I know, which specifies this behavior.
Ok overall I'm wrong.
But either way poor design from a usability standpoint and from a consistency standpoint because ints don't do this.
TIL about Go:
Numeric constants represent exact values of arbitrary precision and do not overflow. Consequently, there are no constants denoting the IEEE-754 negative zero, infinity, and not-a-number values.
Would probably retain it better if I used Go as my primary language for a year or two.
Keep in mind this guy didn't even mention how javascript handles nulls. While nulls bypass typecheckers, typically a null + 1 throws an exception. Not so in javascript... null + 1 returns a 1 in javascript.
[1]: So far as I'm aware, though I'd love to read about it if I'm wrong.
I'm imagining that. It's my first day at a new job cleaning up a legacy codebase, but upon opening up a single 10kloc function written in JS, I realize that I made a terrible mistake and immediately hand in my resignation.
In the meantime, I set a breakpoint at the end of the function, inspect the inline value annotations for NaNs, and trace them back to the start.
Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour.
Also, I'd be really surprised if the function was made to return an int, because JS doesn't have integer datatypes.
> Sure, I can say all kinds of stuff to make finding this error sound simple but if exceptions were thrown instead of assigning NaNs to some variable life would be easier.
I said this in the parent post and sure enough the reply is exactly inline with what I said was going to happen. I don't hate javascript, but it has its horrible horrible warts.
>Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour.
An exception would take a second. An exception would give you the target line of every illegal operation; while a NaN propagates itself like a virus along every arithmetic operation.
Some people find it easy to run a 20 miles, sure but that still doesn't change the fact that cars are much better. Get the analogy? You are running 20 miles and telling me how you don't mind... I'm saying sure, but driving still has a purpose in life.
Breakpoints are off the table? Seriously? I didn't realizing using a debugger made me a JS fanboy.
Wrapping all of your basic arithmetic in try/catch blocks is completely unreasonable. If you need to check for NaN, check for NaN. Making arithmetic substantially slower in the general case to catch the uncommon cases is exactly the problem NaN was introduced to solve.
I'm not even saying to wrap your functions in try catches. If your program has a 1/0 operation then obviously you made a mistake somewhere. With javascript you have to hunt that mistake down, with a language like python you get the line number of where that mistake occurred. The exception is there for the entire program to fail so that you can correct your mistake. The language should not allow operations to occur that create these things called NaNs and thus automatically this removes the need to check for NaNs too. That's all I'm saying.
BTW unless you explicitly instantiated a NaN you should rarely ever be checking for NaN's in your code. NaNs represent illegal operations like 1/0, and thus any type of code producing a NaN should be killed. If you check for NaNs in your code that means you are guarding your code from your own bugs.
>I didn't realizing using a debugger made me a JS fanboy.
Yeah that was inappropriate. I apologize for calling you that, unfortunately you still saw it before I edited it out.
`Array.prototype.map` takes a function and calls that function for each element in the array, passing in the value, the index, and the array itself.
That means that your 0th element will be parsed as you would expect, your 1st element will be parsed as gibberish, your 2nd element will be parsed as base 2, your 6th element will be parsed as base 6, etc....
Now, should you treat the radix as optional? Absolutely not. I've got several commits on newly adopted codebases where I went through and explicitly used `10` as the radix anywhere `parseInt` was called. But is it technically optional? Absolutely.
For example:
>> Which C++ data structure would you use to store a sorted list of 5,000 integers, a linked list or a vector? The values will be randomly generated one at a time, and after inserting an integer the list must be in a sorted state.
> I would use a vector because of its compact and linear nature. It would-
>> Sorry, the correct answer is a linked list. With an array if you want to insert something in the middle it's going to require you to move all elements that come afterward. Linked lists on the other hand have a constant time cost for insertion and removal.
> But the cost of constant cache misses while traversing the linked list are going to significantly outweigh the cost of shifting the array by one space. And on top of that the 3-4x overhead is going to push nearby nodes out of the cacheline.
>> I'm not convinced.
> We could benchmark it together, or find an existing benchmark online.
>> We're on a strict schedule here, so let's just move on to the next question.
> No thanks, I've realized I wouldn't be a good fit for this position. Thank you for your time and best of luck.
How do you handle a situation like that, where you're asked a trick question but the interviewer doesn't know the trick? It's difficult to find a balance between assertiveness and argumentation.
Do you insist on giving the correct answer and backing it up with facts? Or do you tend toward conflict avoidance, taking the loss on one question and hoping to make it up on the rest?
When you're on a team, you can plan your approach based on the personalities and culture around you. But in an interview you usually have minutes of experience talking to your interviewer. Would they be impressed at your knowledge, confidence, and assertiveness? Or will they perceive your confidence as egotism, your assertiveness as an issue with authority, and your knowledge as incompetence?
The correct answer varies based on the interviewer's personality and your tactfulness, but realistically you need to either stand your ground or walk away. If you acquiesce, you're setting yourself up for a miserable work environment.
I’d give more points for that answer because it shows a deep understanding.
Perhaps ergonomics, but that's subjective and relative to the codebase in question, and I tend to prefer the ergonomics of a vector personally.
If you have an example of why a linked list would be a better choice in a given situation, I'd love to learn more.
Here's an example performance graph, but I encourage you to try it yourself if you're curious: https://www.codeproject.com/KB/cpp/340797/linux_insert1.png
I’ve had interviews like that. If the fundamental basis for the question is wrong, and the person asking the question doesn’t understand the material in front of them, then it doesn’t matter.
What’s annnoying to me is when companies keep contacting me about job openings they have, but where the interview process works like this.
There’s a reason why I don’t work at companies like that, and I no longer respond to invitations from companies like that.
I won’t name any names here, but I don’t think anyone here would be surprised.
> Mostly ES6...
As far as auto goes, I'm in the camp of using it unless the type makes the code clearer, but I get where you're coming from.
When it comes to iterators and such, that's where I think auto really shines. Those types only exist because they have to and I just don't care about having the noise there.
But it is a good question if there are other fall-backs because you get lots of info in the case where the candidate gets it right. Spotting the "789a" shows an eye-for-detail (important!). The candidates' explantation of the consequence tells something you about how well they know the environment, and how well they can logically think about cause and effect.
The thing that makes it a trick question is that map calls the given function with the value, the index, and the original array. And parseInt takes a value and a radix. Which means your 4th entry is parsed in base 4, your 8th is parsed in base 8, etc....
So the correct answer is [123, NaN, NaN...], and that makes it a trick question.
> Even one company where I seemed to be an almost 100% fit didn't get back to me.
What's wrong with these hiring managers? I mean, I thought software engineers were super-much in demand. Every founder interview I read includes a complaint about how hard it is to find good coders. These companies publish vacancies, and then don't even respond to well-fitting applicants (I'm just going to assume that the author is compentent). Is this typical? Among "startups between 20 and 100 employees"?
This article is about a German citizen looking for a job in Canada.
I found that medium/big companies replied almost without exception and the ones I haven't heard back from are almost all small startups so I assume the real reason is recruiters there are just fuckups.
As I found out during my job search, the new 2017 trend for tech hiring is companies giving both a take-home assignment and an algorithm test before the on-site. And it's never a weighted average where doing well on the take-home can account for a weaker algorithm performance; it's always pass/fail.
This gets very annoying very quickly when you keep passing take-home assignments (that has questions actually related to data science) easily but fail the subsequent Leetcode-esque algorithm questions that aren't related to data science at all.
This might be field specific, honestly. Just pass on the places that require the tests without a human involved in the process, or take some refresher courses. The process is rougher the further you are away from school.
Hackerrank and co are the field sobriety test of interviewing.
Why didn't anyone tell me that I will get treated so poorly just ten years out of school?
In that case, you should probably go work somewhere else where you can care about the problems being faced by the business.
All IMO, of course.
In reality, unless you are building truly building a system that needs to scale to a massive size, a company won't be looking for that information. Don't fret it.
Of course this is a matter of opinion, but others have said being an engineer/developer/programmer/whatever kinda sucks. I disagree. I think it's the coolest job in the world. I highly recommend not switching until you've at least tried it at a couple of places. There is always something new to learn and to try.
It absolutely is that bad. If you've not had a shitload of experiences like this, you've been very lucky or very sheltered by an unusual selection of target companies.
On the other hand, I totally agree that being a developer is a very cool job. It's totally worth it, but the hiring process sucks and only seems to be getting worse.
If you want to know what that actually means, I suggest befriending people who work as recruiters (or in other hiring roles) at major tech companies and getting the inside scoop from them. You shouldn't just believe everything you read on the internet, after all.
The author of the article has made cold move to other country and hunted for an ideal position (almost) without any network.
Unless desperated I would firstly find a gig in a new place via my existing contacts or cold remotely, definitely before moving over. That could be anything which meets my minimal requirements and then would start to build local connections and learn the market.
Interviewing with recommendation or even being poached by moving coworkers or managers is much better experience.
You should realy start researching market now before graduation. Some freelance or part-time work should expose you to the market and add starter experience to CV.
I did all the above in the past with success.
Life is too short to work for incompetent, clueless, stupid organizations.
It’s been crazy tough after 25 phone or in person interviews!
To some clients, I send the most competent people I can find and still they have to go through three calls and a 4-8 hour "coding task" and only then get maybe invited to an onsite. I have compiled a list of horror stories that I saw in my recruiting career (https://medium.com/@iwaninzurich/why-software-engineers-dont...). Since I wrote this, I collected many other stories, like a candidate being rejected because he took a call from a cafe and trivial stuff like that.
I think the internet made headhunting/recruiting more efficient but counterbalanced that by also generating more spam that companies have to deal with. Maybe companies get increasingly more spam nowadays and this is their way to deal with this. That is also why they pay recruiters like me.
I see that the mismatch between what companies say they want, what they actually want, what they actually need is becoming bigger and bigger and I honestly have no clue how to solve this.
In the end, how do they manage to hire anyone?
The Zürich (and Swiss) job market isn't that big, but that goes both ways, the available talent pool is also fairly small, and turnover is lower than in big tech hubs.
Sure you have access to workers from all the EEA, but while salaries are high for young singles/DINK, things change when you want to hire experienced developers (I remember you're from Germany, I know people who moved from Switzerland to Germany since it made more sense financially!)
The Zurich market pays better, why would it make sense financially it salaries are less in Germany?
Also depending on your field of expertise (embedded systems in this case), there are easily 1-2 orders of magnitude more opportunities in Germany.
It's true there are not many embedded jobs, but I know at least 1-2 companies (e.g., bbv.ch), contact me if you want more information (my e-mail is in my HN-profile).
As for embedded systems, that's not my field, but the one where my friend works. After being laid off in Switzerland, he spent a few months looking for a job (in the whole country), gave up and started to interview in the Munich area where he could pick between several offers, all upwards of 90k/year. Plenty enough to maintain his lifestyle.
This makes sense to me, the number of pages on your resume correlates with your programming skills.
So basically they asked you to solve a problem for them, without compensating you. Personally I would have either rejected the task or asked for compensation. But then again I'm a freelancer, so I know what my time is worth.
>Nothing. Happened.
How long did you waited for them to get back to you and did you follow up until they answered "we are not interested in you"?
Silence does NOT mean "No". I see software engineers doing this mistake (in a job hunt) over and over and over again.
I wrote them again a week later. Still got no response. Then I contacted the HR people on LinkedIn and got mostly rejections - but one interview, actually. So I totally agree, you have to follow-up. Didn't mention that in the article.
I am wondering about the impact that maximizing the overlap of interests between you and the company would have in the process. Not only at the technology level (important too), but at the business level. I imagine it would help you to make your application stronger.
The more I advance in my software engineering career, the more that variable increases in importance.
-drd
- simplify your resume until it can be scanned in 30 seconds
- apply at many places, it’s a numbers game
- build up a local network of people likely to refer you by going to meetups
> Why is it that someone who worked at various tech companies, has an active GitHub profile and a blog, is asked to go through programming puzzles? I digress.
> While they said I shouldn't spend more than a "couple of hours" on it, it took me pretty much one and a half days to finish.
Bingo. (Combined with the disappointingly obvious statement that there are somehow people with a decade of industry experience who can't actually code, necessitating some way of determining that for an individual candidate)
Also, how would programming projects reveal that you're a slow coder? I know some people who can run through (memorized) coding puzzles quick as a whip but who struggle to put together a working REST API with a few endpoints in under a few weeks.
There was one interview with a company I did where they explicitly said not to take more than a few hours but actually gave you a few days to complete it. So I legitimately cranked something out as fast as possible in under 2 hours and actually achieved the task at hand. But, since it was just 2 hours, I didn't bother making a makefile or splitting stuff into multiple files, or I used shortcut APIs.
In the end, every shortcut I used to get the job done in 2 hours became their justification for passing. So yeah, don't actually do the job in 2 hours.
I was handed a single file of about 5000 lines of code and told "please note down what you would improve, just everything from formatting consistency to architecture".
I got through around 1000 lines in the given time (can't recall how long that was) and had to tell them "I found too many things wrong with it, here is the gist".
I went on to work on internal architecture and code quality in that position.
So yeah, not all tests are made to be passed with flying colors, and not all tests are made to be flunked. Anything in between will still give you valuable output.
To handle interviews I spent a day creating a barebones api under a simpler framework that had example routes for some possible question types like Backend http requests, sql calls, and redis.
Then I abstracted the mundane data transformation functions like "text to json" or "json to text", or "json to response object" into decorators. Literally the views just fetched some data from sql and returned the raw data, while the decorators would handle the necessary transformations.
By doing this leg work first, and writing the api so that in timed interviews you don't have to think about anything other then fetching and returning data (of course the decorators aren't enough to handle all data processing cases) you can outperform other candidates by spending more time working on the problem rather then thinking about configuration or type conversion.
Also it would be good to use a pattern that scales and is a bit unconventional to help you stand out. I chose coroutines with httpaio (I'm a primarily python developer) which is really different from what most people use (flask).
I recommend creating your own barebones template for interviews but you can view what I did here: https://github.com/crimsonalucard/aiohttp_bootstrap/blob/mas...
AS you can see even bootstrapping an api is over a hundred lines of code. If they want you to pull that magic off from scratch in 2 hours, good luck, psh. It took me about 8 hours to write the bootstrap code (Albeit I was dealing with a completely new frameworks, libraries and patterns I've never used at work).
The good thing about having a barebones api setup and running it on your computer is that often these live coding interview questions happen on your computer.
Just some tips. Good luck everyone.