> 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.
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.
Oh may be they are not the hacker news reading type :). Some large enterprises still wants slideshows and case studies with a link to white paper downloads filling the home page with less reference to what exactly you are doing!
who knows yet the site has one purposes only to report interference and they do have a button on their homepage to do that. Thus, I empathized the main purpose with as little text as possible and a bright purple button.
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.
This is making me think that maybe I’ve been doing these wrong.
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.
What I've found is they're actually looking for the candidate that goes above and beyond. That "should only take 3 hours" might be true for the basic ask, but you'll never get called back. It's especially common for startups because they're looking for someone who is going to generally have longer hours and lower pay. It's smart for them because it puts most of the work on you, just a very bad experience for the prospective candidate.
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.
I have only had one such assignment (every other timed problem set I have received has had a hard deadline), but I was unceremoniously rejected after doing what you describe. To make it worse, it was "don't spend more than 8 hours". They basically gave me a weekend project.
I had one which was "this is trivial, and shouldn't take you more than an hour." Which after looking at their very unclean data set they wanted to perform analytics on (lots of missing/incorrect/... data), and the effectively random set of formats that I had to deal with (some mysql dumps, some CSV, some weird IBM mainframe DB txt dumps, etc.).
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.
Excellent response, if true. Companies treating candidates like garbage are the scourge of our industry. You should name and shame but I understand why you don't.
I've started to do the same. I don't know how sad it is; it signals to me that they have no idea how to select good engineers and don't care about interview feedback. In my experience, these are also the companies that ghost you if they go with another candidate.
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.
They test you if you can do the work, you test them if they can pay. A company should be more financially stable than you, so they should pay for the recruiting process.
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.
I think you have the right idea. My last challenge took at least 20 hours because i had to use their api. without any feedback in return it's not a smart trade off.
The most time I'm willing to dedicate to these sorts of assignments is 1 hour. If they don't think my time is valuable, then I probably wouldn't want to work for them.
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.
When the inevitable question "What are you most proud of?" comes up, it's your turn to impress.
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.
Whether or not you feel proud about them, I would suggest trying to look at some of your accomplishments from a different perspective to see how they can actually be impressive. Things like cleaning up terrible legacy codebases are valuable and reflect two positive traits, to me: Willingness to get your hands dirty, and the sense to distinguish between "good" and "bad" code.
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?"
I'm in a similar boat as OP, every thing you say is true and I've tried selling myself that way, but in the end when you're trying to break out of that industry and work for a startup or different kind of company not all of them can appreciate that type of work. I've gotten rejected many times with the feedback that I was great but other people interviewing for the same position has more relevant experience.
Good point. I imagine most smaller companies are specifically looking for people who can build things in a self-directed environment using the latest tech. Maybe it's only the larger, older orgs that care about legacy code wrangling.
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).
It's not about the actual project but about storytelling. First you need to write a compelling story, read some blogs about writing or even books on the subject.
Side projects won't help you unless you build something massively popular
> 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.
Maybe focus on the non-technical results of those "useful and sensible" things?
Yeah, if one of the projects stands out as having the most benefit to your users or clients then I would focus on talking about that as it would help the listener realize that you care about the _business_outcomes_ of your work.
> 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.
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 interviewed with Google. All the interviews went well, and in one session, one of the hiring managers was so surprised by my solution he had to look it up on Wikipedia. Next week the recruiter calls me--"We're not forwarding you to the hiring committee. I can't tell you why. Contact me ≥ 1 year from now if you want to try again." WTF Google?
>"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.
I interviewed at the Google Kirkland office a while back, and I doubt any of that applies in my case. It was the coldest interview experience ever in my life. All but one of my interviewers were either aggressive, dismissive, or seemed to have Asperger’s syndrome. I didn’t feel welcome. One of the interviewers seemed more interested in showing how smarter than me they were than actually interviewing me.
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.
I don't see what this has to do with Project Oxygen. They gave me only one soft-skills question in a five-hour session. It was straightforward and I had no indication they were unhappy with my answer. My WTF is referring to the fact that the outcome is at 180 degrees from the feedback I received at the time.
They're trying to say Google's more likely to reject you for a soft-skills deficit, but they're incorrectly drawing any conclusions from "I can't tell you why". It could have been anything from discrimination to a simple mishap of hiring for a position already filled and the recruiter/interviewer saving face.
Most companies won't tell you why. There is no upside for them, and significant downside if they reveal something that could open them up to a lawsuit.
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.
Yep. I've never worked for a company where we told people why they didn't make the cut. Heck, the person who delivered the bad news didn't even know - we selected the candidate we wanted (or none) and told HR to make the rest happen.
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?
Well, it depends. At my job, we do give feedback to all our candidates. Basically, we condense our notes about the candidate down to the most important points and send it to them. We've found that candidates appreciate getting this kind of feedback because:
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.
(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.)
This is why I don't believe almost all companies that profess a commitment to diversity in hiring. They're committed to diversity right up until the point where not being committed would open them up to a lawsuit. THAT'S when they chicken out.
I've been in a hiring capacity many times and as explained to me by HR/Legal: Never reveal the reason for passing on a candidate. They explained that in the US, it can provide rationale for lawsuits if the person comes up with some counterpoint, perhaps with evidence that you were in possession of the counterpoint. I am not a lawyer, but that is the reason given to me by multiple big companies.
I also interviewed with Apple in Cupertino and they gave me a clear reason why they passed on me. So either Apple is immune to the US legal system or all this talk about lawsuits is hogwash.
> They gave me only one soft-skills question in a five-hour session.
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.
Sounds like a textbook example of restriction of range.
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.
How is critical thinking and problem solving a “soft skill”? Also, the ability to play politics dominates all of this in determining success, though it is generally considered as a negative for an interview.
I interviewed a lot @google and read other people's feedback - a lot of those were super lazy write ups with questions like "guess what i'm thinking". Recruiting/hiring managers don't seem to be tracking any other metric other than "response time <2d" and interview "training" class was basically "don't ask these things or we might get sued".
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".
How do you know that the interviews went well? Oftentimes people's subjective evaluation of their own performance is inversely correlated with reality; see e.g. the Dunning-Kruger effect.
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.
Doesn't matter, you don't want to risk potentially burning bridges. The expectation of confidentiality is reasonable in interviewing, and I won't violate it.
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.
> I got a challenge from a company and due to my prioritization and commitments, I wasn't able to work on it before the deadline. I wrote them and explained the situation, telling them that I cannot interview with them any longer since I'm too busy with other companies.
> To my surprise, they offered to fly me in to their New York headquarters straight away to meet the team. I was baffled.
People just want what they cannot have. Applies in all sorts of situations.
Yeah, the less you want it the more they want you. During my last job hunt I got an offer, and while I was considering it another company contacted me. I told them I was deciding on another offer, and I wasn't interested unless they could beat that job offer in 48 hours.
That same day I had a phone interview, came into the office, met the team, and negotiated the offer.
Company A had already interviewed you and liked you enough to offer. If Company B can hire you instead they've possibly gotten a free ride on the "technical qualifications" part of the interview process. The fact that you have an offer means you've already passed a lot of qualification checking from someone.
The fact that you have an offer means you've already passed a lot of qualification checking from someone
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?
If one already has a job means one perhaps passed the technical interview but long time ago and meanwhile could become lazy incompetent bum;) Getting a fresh offer means one is back in shape, a competence somehow transferable it seems. Just my divagation.
...this feels like it might be a bit of a job interview shortcut or lifehack. Just always say you've been given an offer from other companies, and help reduce the amount of crap you have to put up with.
> I applied to 14 companies, talked to 8, interviewed at 5 and got an offer from 3.
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.
I'd recommend to be careful when mentioning nationalities together with diminishing words ("dirt cheap") - even if it's not discrimination, it can impact your judgement and its validity.
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).
Whether you like it or not this is the migration dynamics in this part of EU. For Russians/Ukrainians it's geographic proximity plus salaries higher than in home countries. Many Americans/Canadians idealize this part of EU (Germany in particular) as some kind of promise land, eventually have romantic partner over here. All of them are in volatile and vulnerable legal situation (e.g. visa depending on employment contract). Either way most of the times I end up visiting the company I talk with an American, Ukrainian, Russian, and a local national. There are quite some Romanians as well, but they emancipate quickly (Romania has been EU member since recently).
As an American that took a substantial pay cut (taxes add to the pain) to get into Germany, this sounds about right for my experience. I came over mostly as a cultural thing, and salary was less of a concern.
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'm a US-based (Ohio), experienced dev, in an in-demand field - so this might not be the same for everyone - but it sounds believable to me.
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.
Lol. I think they changed their mind sometime in the last couple of months. I'm about to join them soon. Was supposed to be remote as well, but I'm planning to relocate now.
I have a similar experience. I am still at university and not a native-German, but I am asking around, and for a non-IT German, 60K (gross) would be like super-rich money, and companies are not willing to give you that much. However, my experience is not based on the big cities, where I know 50-60K (gross) would be the starting rate for a Master's student.
I would be interested to hear other's opinion and experience, as I will join the workforce later this year.
I have friends contracting in Germany at 800 EUR/day (which comes to about 180k EUR per year). Seems like, as in many other European countries, the good money is in contracting.
> Know complexity and scalability: Every time I had to code something, I was asked about the time and space complexity as well as whether I can simply make it more efficient. Now and then, I was also asked what would happen if the input became gigantic so it wouldn't work on a single machine anymore. It's crucial to have answers here.
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.
This is “grill you on everything” kind of interview. Open discussion on system design is IMO a really cruical round. I am not saying the candidates have to have years of experience in scaling - I doubt most applicants have. FWIW, the application I built for my CS department when I was an undergraduate was getting at least 10-20 times of that amount at peak every week (probably hundreds per night) as assignments were due. We were fine on a single server running three vagrants - one for main backend, two for grading assignments in a sandbox.
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.
That would be wonderful is interviews were actually done with the idea of finding out if a prospective employee was proactive or not, but most interviews are just the interviewers going off a checklist of questions they think they need to ask because they are effectively in a cargo cult.
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
"most interviews are just the interviewers going off a checklist of questions they think they need to ask because they are effectively in a cargo cult."
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.
Unfortunately its the kind of culture most companies seem to get. The few that don't have that culture, like early Facebook or google, can skyrocket from getting actual talent, but even those companies start to devolve into the scripts once they get large enough unless there is a concerted effort to avoid it.
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.
It does not help that many of those deciders can have conflicting incentives. The line manager may want to take anyone willing to learn and has the basics of programming, but the HR manager may have cutting costs as their overriding concern so why hire anyone whose not perfect since that's not 100% "optimal"
That’d be odd though. HR usually have no weight on the decision making. If HR does, I wouldn’t want to work there. I wouldn’t expect the legal team influences me hiring a junior developer. It is rhe manager’s responsibility to budget.
HR / legal might have a say when it comes to hiring like a C-level executive.
That may be the case in some places, but every company I've worked at has had HR have some say in hiring. The worst place was one where it didn't start out that way until the head of HR played some political move and refused to process the paperwork for any hires unless they had gone through their SilkRoad software and been vetted by HR first. We immediately went from getting some decent candidates in interviews to suddenly interviewing people who didn't know what loops were but had listed 10+ years of experience as a software engineer on their resume
A bit late but I forgot to add the worst case I've ever seen. We had hired a new dev who was going to take over a senior position when we had multiple openings for over 6 months. The offer had been signed and returned when the head of HR rescinded the offer. When pressed for a reason why, his exact quote was, "We aren't the Yankees, were like the Oakland A's. Were just looking to get on base, not to be number 1"
After weeks of stamping out CRUD features to order, conducting an interview might be their only chance to hang out and talk about high performance computing for once.
Or maybe it takes almost an hour to service each of their 200 requests/month, and they're desperate to get their response into the sub 30 minute range :)
So true. At my old job, higher-ups insisted we use Spark on a data-set my iPhone could handle. Blows my mind to this day.
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.
> At my old job, higher-ups insisted we use Spark...
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 (╯°□°）╯︵ ┻━┻
What's really screwed up is that several people that made that god-awful decision have now moved on to different companies (with pay raises I'm sure). So not only did they make an objectively terrible decision, but they also left the mess to whomever it ended up falling in the lap of, and not only that, but they got rewarded for it, too!
Always jump on the cool stuff even if it makes no sense for the business. In most places as SW engineer you are not rewarded for creating business value or saving money. You are being rewarded for knowing technologies.
For lower positions/companies, I would probably agree.
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).
That's all well and good, but those are highly competitive positions. Even joining the companies where this is possible in the first place is competitive. It isn't something you can "just" 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.
Getting in is definitely competitive but study enough data structures and algorithms and you should be able to get into at least 1.
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).
True, but if you're not one of those principle engineers already then you likely have no ability influence what tech choices are being made and you should just learn the new tech so you can jump ship more easily in the future
Really? I propose tons of ideas to my team/org about technical decisions I think we should move towards and while a good portion of them get shot down, lots get positive feedback/management backing from my team. This combined with me owning the projects/proposals I made got me promoted very quickly.
What I've learned from the past few days on hackernews is that apparently I have worked at some shitty jobs. Even when I have owned a project and led it to massive success as far as the company was concerned, like under half the budget and half the timeline, its just led to someone higher up taking notice. Those higher ups then either come in and start directing things themselves because they think we cant possibly keep succeeding, or they hire someone from outside the company to come in and take over.
A decade is less than 1/4th of an employees career at the current retirement age of 66/67 and there are people that get this compensation in a decade (a rare few even less, granted it is not trivial).
Realistically most of us will never be in the position to make 400k or more. Once you are at that level you are part of the "in" crowd but most of us will always be replaceable cogs in the wheel.
Wanna make that kind of money? Go found a unicorn and get the silly money VCs to flood your company with cash, and then take your platinum parachute out.
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.
Same in my compnay. We have a dataset of 1 Terabyte that needs to be queried once a week. IT has talked management into installing a Hadoop cluster for this and we have to pay an analytics team. I told my boss that we can probably run this on a SQL database on a USB drive attached to his laptop without problems.
Suggest to your boss to do a test. If your off-the-shelf solution performs equally well, axe the cluster and analytics team. Maybe go to him with an estimated cost comparison.
We already have done tests for in-house testing but nobody wants to stick his neck out and tell IT to go away. They have convinced upper management that we are doing "big data" and upper management likes the sound of this. It's the good old problem that when you do something that's "cool" at the moment you get more credibility than using tried and true tech like SQL databases. I'll probably also jump on the Hadoop bandwagon because it's good for the resume and more exposure inside the company. Total waste of money and we lose a lot of flexibility but who gives a f..k these days. Gotta go with the flow.
> We already have done tests for in-house testing but nobody wants to stick his neck out and tell IT to go away.
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.
I would advice you to jump into Hadoop and also spark. It's a bloody mean world out there who wouldn't care what you have done or how you have done but just wanted to know if you can configure the most popular tool in the market.. you may explain them you didn't get a chance etc, but most of the time interviewers are like your current management.
> Explain what ["123", "456", "789a", ...].map(parseInt) returns
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.
I forgot to mention, the worst part about trick questions is that you never quite know what's meant to be a trick question and what's not, and handling that gap can be extremely tricky.
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 had a phone interview situation like this the other day. The interviewer asked me what I thought of the C++ 11 "auto" specifier. I told him I preferred explicit types for pragmatic reasons and as an aside mentioned that "auto" keyword used to be used for something else in C++. He told me that wasn't true.
(Hmmm, OK. Let it slide Chris. Not going to score any points by proving him wrong...)
I was interviewing for a software architect position and before my now manager interviewed, i interviewed with some junior developers. I started talking about what I thought about some of the latest features of EcmaScript. One of the developers said "we don't use EcmaScript we use JavaScript".
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.
“It depends on how often the data will change. A linked list will be good for [situation x], but a vector might give better performance in [situation y].”
I’d give more points for that answer because it shows a deep understanding.
The only “correct” answer here is “linked list”. Any other answer is officially “wrong”.
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.
This reminds me so much of high school and university physics tests - the hardest part was guessing the level the teacher was thinking at and answering accordingly (or covering all bases with conditionals if possible).
I feel this issue comes up in many more places than just interviews.
My bad, that's a transcription error. The original question was which would you use: a linked list or a vector? I've edited the post to be more clear on that.
It would be bad as the lone question. A candidate who whappens to not spot the "789a" will get it wrong, and you don't get any info about the quality of the candidate.
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.
If the correct answer was [123, 456, NaN...] then it would actually be a good question for the reasons you bring up.
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.
['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.
In terms of design I'm talking about an exception not the arity of the function. A hidden NaN in an array of numbers is like a javascript promise for an error in the future. This isn't IO so it's better to kill it now rather than killing it sometime in the future.
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.
> Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN.
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.
> I said this in the parent post and sure enough someone who is a fan of javascript had to reply with exactly what I said was going to happen.
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.
No dude. I'm not saying it's off the table. I'm saying it shouldn't be necessary for a 1/0 illegal operation.
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.
I don't know where NaNs were introduced, but I never attributed the introduction of NaNs to javascript. If JS is just propagating a bad design, it still fits the description of being poorly designed.
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.
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.
Null and NaN are different concepts with different trade-offs and different behavior when working with them. Nulls don't have special processor support[1] and are not part of a multilanguage, multiprocessor, international standard.
[1]: So far as I'm aware, though I'd love to read about it if I'm wrong.
what are you talking about? when did i say I want to make arithmetic slower? And how is that globally agreed upon as a standard? In math when you get a NaN, do mathematicians continue to use it as a variable or do they realize they made a mistake? Think about it. In all math and science It's actually globally agreed upon that a NaN is not a variable you can reuse in some other function.
> And how is that globally agreed upon as a standard?
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.
>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.
> Almost every popular language launches an exception when you do a divide by zero.
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.
> All of them evaluate to Infinity when dividing a double by 0.0. No exceptions to be found.
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.
Yeah, floats and ints are just fundamentally different, especially when you're at the level of caring about how hardware deals with things.
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.
It makes sense to have a function that is like the common functional “map” but passing the index as well, it's probably not a great design to have it be called “map” and have the basic, no-index behavior rely on the passed function taking only one arg, especially in a language where functions that usually take one arg but also have optional args are common.
`parseInt` takes two arguments, the string to parse and an optional radix. (or base)
`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....
I have never seen a browser that requires the radix, and MDN specifically calls out that you should pass both arguments or you will get unexpected results. They wouldn't need to do that if the radix was required.
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.
> 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"?
I interviewed recently and had very similar experience. Only applied for postings that were ideal fit based on their requirements - basically the exact same role at 20+ companies. Only heard back from ~half, then got offers from ~%70 of the ones I heard back from (so roles really were fitting).
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.
I'm currently working on a postmortem on my recent data scientist job hunt.
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.
Well yeah dude, our corporate social media mobile app requires the best of the best! We have a $4M Stage 3A valuation from our VC and were in YC round 6 last month! Our team of 6 MBAs and 1 programmer absolutely requires the most prestigious of programmers! You think I'm really going to hire someone that screwed up a simple if statement?! PFT!
Your startup bullshit is off. Stage 3A isn’t a thing. It’s seed, A, B, C &c. YC doesn’t designate cohorts by number but by year followed by W or S, or Winter or Summer. You’re not going to get into YC with a team of six MBAs and one programmer and if you got in with a team of two MBAs and a programmer you will not end up hiring more MBAs before more programmers.
Data science jobs are tricky when you're coming in from the cold. If you're in one domain, you might use certain approaches and if you're in another domain, well, you'll use different approaches. The thing that gets me about the tests is that, after a while, you might not remember the specifics of a particular approach.
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.
In all honesty, it's not that bad. Some places are like how he described, but there are far more that are not. You want to work at a Google or Microsoft, yeah you'll probably run into something like that, but most places you won't.
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.
Maybe Europe is different, but I've interviewed in two different countries and I never had this experience. There were at most short, easy technical tests and a few open-ended questions about my past work, but nothing like this.
Being a CS major is fine, but being an engineer does kind of suck. My sister went from junior engineer to product manager and is much happier. I'm currently on a sort of sabbatical and working on a few personal startup-ish projects, but when I get back in the workforce (probably a few months unless one of my projects really takes off), I'll try to do something similar.
To each his own I guess. I find being an engineer to be far less stress than I imagine product managers are under. As a engineer I can just "not care" about whatever random business case is being handled and focus on writing code and honing my skills. Having to care about $company_name's business problems sounds soul draining to say the least.
Having creative control is, to me, very important. I'd much rather solve a problem from start to finish than implement a solution I believe is completely flawed.
This guy had 3 offers with 14 applications so he did pretty well. Interviewing is always stressful and can be upsetting but I personally haven't found it too bad (I actually found applying to graduate schools much worse than applying for jobs in industry)
Well, if you are being treated well now during interviews then use that to your full advantage and try to make sure the company you hire on with after graduation is a place that you can continue to develop at in ten+ years. Getting hired in any position is comically random as it is a series of pass/fail tests in which any fail is terminal, and the final pass/fail test is often pre-decided (although unknown to most of the involved parties, candidate, recruiter, team, hiring manager, etc... )
If your skills are good and you do healthy networking from very beginning then you shouldn't be in such situation. Fine, very first job hunt may need some major effort.
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.
You're interviewing the company (and team) as much as they are interviewing you. If they put you through this kind of garbage, you were warned early. Take the warning and don't work there.
Life is too short to work for incompetent, clueless, stupid organizations.
You won't be treated poorly if you are considered desirable.
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.
My problem is fitting hour long code screens in between 9-5. I don’t want to take a day off work, but also can’t exactly do it at work... what are you supposed to do when you need to take one of these for every company you interview with?
I’m in the mid Atlantic area and after reporting my female colleague’s harassment and then later finding myself harassed and pushed out i am surprisingly having the damnest time finding my next job. I’ve been a Front End Designer/Dev for the past 7 years and always got jobs quickly. Now I’m wondering if it’s my age(42.. though look young for my age I am told) or these Govt IT jobs I’m going for my previous peers are talking negatively about me in circles?
It’s been crazy tough after 25 phone or in person interviews!
I am a tech recruiter and former programmer located in Zurich. Some companies treat applicants like shit nowadays. Especially the "startups" and younger ones. The best company I work with is 30 years on the market and they treat applicants like half-gods. Their interviews are all conversation-based, no homework, nothing, just two calls and then half-a-day onsite.
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.
> 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!)
I think, having kids in Switzerland is only expensive if they are 2-3 years old because "Kindergrippe" is not public like in Germany. Kindergarten and up is public and free.
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).
Big difference in parental leave also. It's true that the costs are reasonable once your kids go to school, and university is pretty affordable too.
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.
On the recruitment side of things I had a coworker judge a candidate on how many pages his resume was. If his resume was over one page then he didn't even want to look at it because it was formatted incorrectly.
This makes sense to me, the number of pages on your resume correlates with your programming skills.
In the comments of the article the author mentions that the process took him 4 to 5 weeks... don't know if the time frame will change your perspective, it did for me (thought it was much longer from the tone of the article).
I’m hating the job hunt. Everyone wants a web developer who’s been using React for 10 years and has a PhD in Machine Learning. The good interviews I’ve had inevitably lead to me getting passed over for someone with “a little more” design or development experience (I’m a front-end designer AND developer). Hella frustrating.
Another company asked me to create a web application based on a short specification. I liked that I was able to pick any language and framework I wanted to. Furthermore, the project was related to the company's business and was described very well.
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.
>Within a few days, I had applied to five companies online. I took a bit of time to craft a cover letter for each of them. Then I was waiting for all the inquiries to fill up my inbox."
>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.
On the other hand, I wouldn't want to work for a company where people's responsiveness is measured in weeks. It means they are either unorganized, overworked, disrespectful or a combination.
I know what you mean but the HR "performance" is often a weak proxy for measuring the engineering performance of an institution. The disconnect increases with the size of the institution.
there will be strong link between hiring experience and the kind/quality of people they hire (your potential future coworkers), so that's one reason not to talk to asshat recruiters.
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.
Informative read. I do like how they answered one of their own questions later on:
> 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)
Oh please. The "couple of hours" line is used for any range of "take-home" coding projects, from ones that actual do take a couple of hours, to ones that take a few days.
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.
Had a similar experience at an on-site coding interview.
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.
I haven't bootstrapped a full api in years. For my job we just keep keep adding to an existing monolithic api under a big framework (django). I've literally gotten two interviews where they wanted me to bootstrap api's to solve a specific problem on the spot.
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).
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.
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.